Vorlesung Sicherheit

Größe: px

Ab Seite anzeigen:

Download "Vorlesung Sicherheit"

Helga Dresdner
vor 10 Jahren
Abrufe

1 Vorlesung Sicherheit Dennis Hofheinz IKS, KIT / 26

2 Überblick 1 Schlüsselaustauschprotokolle Transport Layer Security (TLS) Weitere Schlüsselaustauschtypen Zusammenfassung 2 Identifikationsprotokolle Motivation Sicherheitsmodell 2 / 26

3 Überblick 1 Schlüsselaustauschprotokolle Transport Layer Security (TLS) Weitere Schlüsselaustauschtypen Zusammenfassung 2 Identifikationsprotokolle Motivation Sicherheitsmodell 3 / 26

4 Beispielangriff auf RSA-Padding (Korrektur) Beobachtung: von SSL zum Key Transport genutzte RSA-Variante berechnet C = Enc(pk, pad(m)) = (pad(m)) e mod N mit schlechtem (d.h. naivem) Padding (PKCS#1.5) Angriff auf schlechtes Padding seit 1998 bekannt Idee: verändere C homomorph, beobachte, ob verändertes C noch als gültig akzeptiert wird Allein aus Gültigkeit lässt sich Information über M ableiten Benötigt viele (mehrere Tausend) Versuche 4 / 26

5) Angriff auf schlechtes Padding seit 1998 bekannt Idee: verändere C homomorph, beobachte, ob verändertes C

5 Beispielangriff auf RSA-Padding (konkreter) Konkreteres PKCS#1.5-Padding (vereinfacht): C = pad(k) e = (0x0002 rnd 0x00 K) e mod N K wird kurz sein (und immer mit vielen Nullbits anfangen) Ziel: finde viele gültige Faktoren α i, so dass Dec(α e i C mod N) = α i (0x0002 rnd 0x00 K) mod N } {{ } =:M i gültig ist (so dass M i mit 0x0002 beginnen muss) 5 / 26

immer mit vielen Nullbits anfangen) Ziel: finde viele gültige Faktoren α i, so dass Dec(α

6 Beispielangriff auf RSA-Padding (konkreter) Ziel: finde viele gültige Faktoren α i, so dass Dec(α e i C mod N) = α i (0x0002 rnd 0x00 K) mod N } {{ } =:M i gültig ist (so dass M i mit 0x0002 beginnen muss) Gültigkeit wird mit Injizieren von αi e C mod N überprüft In alten SSL-Versionen sagt Server RSA-Padding falsch oder Key K zu groß, sagt also, ob Padding gültig Viele gültige M i grobes Intervall, in dem K liegt Liefert 1-Bit-Guckloch in K 6 / 26

Injizieren von αi e C mod N überprüft In alten SSL-Versionen sagt Server RSA-Padding falsch oder Key K zu groß,

7 Beispielangriff auf RSA-Padding (konkreter) Bedeutendes theoretisches Resultat: jedes Klartextbit von RSA ist hardcore Theorem (Håstad und Näslund) Sei N, e, d wie bei RSA, und M Z N und i {1,..., log 2 (N) } beliebig. Sei O ein Orakel, das bei Eingabe C das i-te Bit von M = C d mod N ausgibt. Dann existiert ein (von N, e, d unabhängiger) Polynomialzeit-Algorithmus, der bei Eingabe N, e, i und C := (M ) e mod N, und mit O-Zugriff M berechnet. Bricht (mit Anpassungen) PKCS#1.5 (auch in TLS) Gewählte Gegenmaßnahme: patche SSL/TLS (wähle K zufällig, wenn Padding ungültig), obwohl RSA-OAEP bekannt 7 / 26

Dann existiert ein (von N, e, d unabhängiger) Polynomialzeit-Algorithmus, der bei Eingabe N, e, i und C := (M ) e mod N, und mit O-Zugriff M berechnet.

8 Beispielangriff: CRIME (Prinzip) Annahme: Kompression in TLS eingeschaltet Übertragen wird komprimiertes comp(m) statt M TLS nutzt DEFLATE-Kompression (LZ77/Huffman-Variante) Prinzip: comp(fliegen fliegen) = Fliegen f(-8,6) Strategie: verändere vorangehenden Klartextteil, um zu sehen, ob folgender (unbekannter) Klartextteil komprimiert Beispiel: bringe Client dazu, zunächst 1234 zu senden, anschließend seine vierstellige numerische PIN ABCD Client verschlüsselt C := Enc(K, comp(1234abcd)) Länge C hängt direkt ab von Länge comp(1234abcd) Insbesondere: Chiffrat am kürzesten, wenn ABCD = / 26

(unbekannter) Klartextteil komprimiert Beispiel: bringe Client dazu, zunächst 1234 zu senden, anschließend seine vierstellige numerische PIN ABCD

9 Beispielangriff: CRIME (konkreter) Konkreter: Angreifer möchte Cookie von Client stehlen Client hat laufende Session mit Server (z.b. Client hat geheimes HTTP-Cookie ABCD, das Browser automatisch an alle Nachrichten an Server anhängt Angreifer schleust JavaScript-Code bei Client ein JavaScript-Code lässt Client WXYZABCD an Server senden Angreifer belauscht C := Enc(K, comp(wxyzabcd)), erfährt so Länge comp(wxyzabcd), und wie nahe WXYZ an ABCD ist Viele Wiederholungen/WXYZ Angreifer erfährt Cookie Wichtig: Böser JavaScript-Code kennt nur WXYZ, nicht ABCD, kann aber Client dazu bringen, WXYZABCD an Server zu senden 9 / 26

JavaScript-Code lässt Client WXYZABCD an Server senden Angreifer belauscht C := Enc(K, comp(wxyzabcd)), erfährt so Länge comp(wxyzabcd), und wie nahe WXYZ an

10 Zusammenfassung TLS TLS historisch gewachsen, Quasi-Standard, hochrelevant Viele Versionen, Einstellungsmöglichkeiten, Angriffe, Fixes Frage: warum unterstützen viele Browser nur 1999-Standard? Antwort: Angriffe aufwändig, Kompatibilität Frage: warum verwendet man nicht bessere Algorithmen? (z.b. RSA-OAEP statt schlecht gepaddetem RSA mit Hotfix) Antwort: einfacher zu fixen als zu ersetzen 10 / 26

11 Zusammenfassung TLS (Quelle: wikipedia.org) 11 / 26

12 Überblick 1 Schlüsselaustauschprotokolle Transport Layer Security (TLS) Weitere Schlüsselaustauschtypen Zusammenfassung 2 Identifikationsprotokolle Motivation Sicherheitsmodell 12 / 26

13 IPsec Internet Protocol Security (IPsec): eigentlich gar kein KE Ähnlich wie TLS, nur ohne Handshake (also ohne Schlüsselaustausch), und auf niedrigerer Protokollebene Sieht auch z.b. IP-Adressen und Portnummern Unterstützt AES, 3DES, HMAC, SHA-1, MD5,... Schlüsselaustausch muss getrennt vorgenommen werden IPsec bei weitem nicht so populär wie TLS IPsec theoretisch nicht gut untersucht Aber: einige Angriffe auf spezielle Modi (CBC) existieren 13 / 26

ne Sieht auch z.b. IP-Adressen und Portnummern Unterstützt AES, 3DES, HMAC, SHA-1, MD5,.

14 Password-Authenticated Key Exchange (PAKE) Ziel: gemeinsamen geheimen Schlüssel K aushandeln Alice pass Bob pass Kommunikationskanal unsicher, aber pass geheim Problem: vollständige Suche über alle pass möglich Angreifer kann immer pass raten Aber: wir wollen, dass es nicht besser geht (Nicht-)Beispiel: Alice nutzt SKE (Enc, Dec) wählt K und... Alice pass Enc(pass,K) Bob pass Frage: warum nicht optimal? 14 / 26

möglich Angreifer kann immer pass raten Aber: wir wollen, dass es nicht besser geht (Nicht-)Beispiel:

15 Password-Authenticated Key Exchange (PAKE) Beispiele: Encrypted KE (übertrage Enc(pass, pk), dann Check) Simple Password Exponential KE (DH mit g = H(pass) 2 ) Beweisbarer PAKE (Goldreich-Lindell): nutzt Zero-Knowledge Grundidee: einfacher KE mit anschließender Überprüfung Anwendung z.b. bei EAP (WPA-Authentifikationsvariante) PAKE-Sicherheit formal modellierbar und beweisbar (unter zahlen-/komplexitätstheoretischen Annahmen) 15 / 26

Zero-Knowledge Grundidee: einfacher KE mit anschließender Übe

16 Überblick 1 Schlüsselaustauschprotokolle Transport Layer Security (TLS) Weitere Schlüsselaustauschtypen Zusammenfassung 2 Identifikationsprotokolle Motivation Sicherheitsmodell 16 / 26

17 Zusammenfassung Schlüsselaustausch Ziel: gemeinsamen geheimen Schlüssel K aushandeln Alice Bob Mit Schlüsselzentrum: Kerberos Asymmetrisch: Key Transport, Diffie-Hellman (mit PKI authentifiziert) TLS: Standard, nur aktuelle Version verwenden Formale Sicherheitsuntersuchung möglich, aber komplex 17 / 26

Transport, Diffie-Hellman (mit PKI authentifiziert) TLS: Standard, nur

18 Aktuelle Forschung Angriffe auf TLS Sicherheitsbeweis für TLS(-Varianten) Weitere KE-Varianten: Non-interactive KE (NIKE) ID-basierter (NI)KE Realistisches Sicherheitsmodell (für modulare Analyse) 18 / 26

19 Überblick 1 Schlüsselaustauschprotokolle Transport Layer Security (TLS) Weitere Schlüsselaustauschtypen Zusammenfassung 2 Identifikationsprotokolle Motivation Sicherheitsmodell 19 / 26

20 Überblick 1 Schlüsselaustauschprotokolle Transport Layer Security (TLS) Weitere Schlüsselaustauschtypen Zusammenfassung 2 Identifikationsprotokolle Motivation Sicherheitsmodell 20 / 26

21 Motivation Ziel: asymmetrische Authentifikation (von Parteien) Alice ska Bob pk A öffentlich Alice möchte sich bei Bob authentifizieren Bob möchte sicher sein, dass er mit Alice redet Genauer: Bob möchte sicher sein, dass er mit der Partei redet, die sk A besitzt Noch genauer: Bob möchte sicher sein, dass er mit einer Partei redet, die einen passenden secret key zu pk A kennt Ab jetzt heißt Bob V ( Verifier ) und Alice P ( Prover ) 21 / 26

22 Einfachste Lösung Einfachste Lösung: P ska sk A V (Annahme: sk A kann als passend zu pk A erkannt werden) V kann sich sicher sein, dass Gesprächspartner sk A kennt Aber: dieses Protokoll scheint nicht sehr nützlich zu sein Bei mehrmaliger Verwendung schwindet Garantie Problem: sk A bleibt bei Protokoll nicht geheim 22 / 26

23 Nächster Versuch Neue Anforderung: nach Protokoll lernt V sk A nicht 2... ist V sicher, dass Gegenüber sk A kennt Nächster Versuch: nutze Signaturschema P ska σ:=sig(sk A, ich bin s, P ) V (V überprüft mit Ver(pk A, ich bin s, P, σ)) Analyse: (informell) 1 Würde V sk A lernen, wäre Signaturschema unsicher 2 Allerdings unklar, in welchem Sinne P sk A kennt Problem: σ kann von Angreifer verwendet werden! 23 / 26

24 Noch ein Versuch Beobachtung: nicht-interaktive Protokolle problematisch: P ska X V X kann von Angreifer verwendet werden! Ausnahme: Empfängeridentität bekannt und gesichert Aber selbst dann Replay möglich Ein interaktiver Versuch (mit Signaturschema): R 1 P V 2 P σ:=sig(sk A,R) V (R Zufallszahl, V überprüft mit Ver(pk A, R, σ)) Passiert implizit bei TLS, mehr hierzu später 24 / 26

25 Überblick 1 Schlüsselaustauschprotokolle Transport Layer Security (TLS) Weitere Schlüsselaustauschtypen Zusammenfassung 2 Identifikationsprotokolle Motivation Sicherheitsmodell 25 / 26

26 Sicherheitsmodell Frage: was wollen wir eigentlich wirklich? 26 / 26

Ähnliche Dokumente

Vorlesung Sicherheit

Vorlesung Sicherheit Jörn Müller-Quade ITI, KIT basierend auf den Folien von Dennis Hofheinz, Sommersemester 2014 28.05.2015 1 / 33 Überblick 1 Schlüsselaustauschprotokolle Symmetrische Verfahren Asymmetrische