Wozu wird TLSv1.0 für BEAST-Angriff vorausgesetzt?

Hallo allerseits,

wie der Titel schon verrät versuche ich herauszufinden, welche Rolle die Protokollversion TLSv1.0 beim sogenannten BEAST-Angriff spielt.

Laut Quellen setzt der Angriff eine mit TLSv1.0 verwendete Blockchiffre im CBC-Modus voraus (die ausführlichste Referenz, die mir bekannt ist: ATTACKS ON SSL COMPREHENSIVE STUDY OFBEAST, CRIME, TIME, BREACH, LUCKY 13 & RC4 BIASES).

Grundlagen: Die zu verschlüsselnde Nachricht M wird in Blöcke M[SUB]0[/SUB], ... , M[SUB]n[/SUB] gleich großer Länge aufgeteilt. Für die Verschlüsselung des ersten Block wird ein Initialisierungsvektor IV
verwendet, um den korrespondierenden Ciphertext-Block C[SUB]0[/SUB]=E[SUB]k[/SUB](IV xor M[SUB]0[/SUB]) zu berechnen. Zur Verschlüsselung aller Folgeblöcke wird jeweils der vorangehende Ciphertext-Block C[SUB]i-1[/SUB] als
Initialisierungsvektor verwendet, also C[SUB]i[/SUB]=E[SUB]k[/SUB](C[SUB]i-1[/SUB] xor M[SUB]i[/SUB]). Diese Vorgehensweise (Cipher-Block-Chaining, CBC-Modus) wurde eingeführt, um chosen-plaintext-Angriffe abzuwehren (wenn ein und derselbe Klartext zweimal verschlüsselt wird, kommen verschiedene Ciphertext-Blöcke heraus). Beim BEAST-Angriff wird ein derart geschickt gewählter Klartext eingeschleust, der diesen Schutz ausgehebelt.
Dies funktioniert, wie folgt: sei P=M[SUB]i[/SUB] die von Alice an Bob übersendete Nachricht, welche der Angreifer Oscar herausfinden will.
Oscar ratet, dass P=G ist und bringt Alice dazu M[SUB]j[/SUB]=C[SUB]j-1[/SUB] xor C[SUB]i-1[/SUB] xor G zu verschüsseln und an Bob zu senden. Dies wird gemäß Rechenvorschrift, wie folgt verschüsselt
C[SUB]j[/SUB] = E[SUB]k[/SUB](C[SUB]j-1[/SUB] xor M[SUB]j[/SUB]) = E[SUB]k[/SUB](C[SUB]j-1[/SUB] xor C[SUB]j-1[/SUB] xor C[SUB]i-1[/SUB] xor G) = E[SUB]k[/SUB](C[SUB]i-1[/SUB] xor G).
Jetzt muss Oscar nur noch vergleichen, ob C[SUB]j[/SUB] = C[SUB]i[/SUB] ist, da aus der Injektivität der Verschlüsselungsfunktion E[SUB]k[/SUB] und E[SUB]k[/SUB](C[SUB]i-1 [/SUB]xor P) = E[SUB]k[/SUB](C[SUB]i-1[/SUB] xor G) dann P= G folgt.

Egal wo ich bisher nachgelesen habe, sind dies alle Details, die in den Beschreibungen auftauchen. Wie ihr gesehen habt, haben wir (wenn ich mich nicht täusche) aber lediglich jene Formeln verwendet, die sich aus dem CBC-Modus ergeben. Also weder TLSv1.0 spezifische Eigenschaften, noch haben wir Annahmen an die Verschlüsselungsfunktion E[SUB]k[/SUB] getroffen (außer der Injektivität, aber das sind alle Verschlüsselungsfunktionen).
Die analoge Frage ergibt sich übrigens auch bei Sweet32. Dieser Angriff setzt (unabhängig von der verwendeten Protokollversion) voraus, dass die Verbindung mit Triple-DES im
CBC-Modus verschlüsselt wird. In den Beschreibungen ist jedoch auch in diesem Fall nur der CBC-Modus relevant.

Danke an Alle, die sich bis hier durch meinen Beitrag gelesen haben. Ich freue mich auf die neuen Erkenntnisse!

Viele Grüße,
Benyza
 
Zuletzt bearbeitet:
Moin.

Hier wird tatsächlich nur die Definition des CBC verwendet. Wenn man sich das mal anguckt:

Gesucht: P = M_i

Genutzt wird der "Klartext": M_j = C_{j-1} XOR C_{i-1} XOR G mit der Annahme (!) G=P (Ansatz für Bruteforce)

Dann hast du natürlich die Kette korrekt: C_j = E_k( C_{i-1} XOR G ) == E_k(C_{i-1} XOR P), falls G=P. Aber nur im selben Kommunikationsblock, da an keiner Stelle der Nonce, IV erneuert wird.

Dieses Verhalten, versetzt einen Angreifer in die Position einen Klartext fester Blocklänge zu erraten. Geschickt angewandt, können dadurch Passwörter geleakt werden. Man muss eben die entsprechende Pakete (C_i) mitgeschnitten haben.

Für die Blockchiffre ist das vollkommen egal.
Die Implementation hingegen könnte einen entsprechenden Schutz vorsehen. Nun gilt es in die TLSv1.0 zu schauen und herauszufinden, wie
a) Oscar Alice dazu bringen kann, dieses Text zu verschlüsseln
b) der CBC in anderen Versionen implementiert ist und vergleichen.
 
[Disclaimer: Keine Ahnung warum es diesmal keine Zeilenumbrüche gibt. Hoffe es ist dennoch lesbar...] Hallo Shalec, vielen Dank für deine ausführliche Antwort und Sorry, dass ich so spät antworte. Zu deinen zwei Punkten, die noch rauszufinden seien: a) Bei solchen Angriffen, wo das Opfer dazu gebracht werden soll, einen vom Angreifer gewünschten Klartext zu verschlüsseln, wird meist der Weg gewählt / beschrieben, dass der Angreifer eine Webseite erstellt, wo ein iFrame implementiert ist, dass den Browser des Opfers dazu bringt den Link zu öffnen. Wenn die Adresse, die sich hinter dem Link verbrirgt, GET-Parameter entgegennimmt, können die vom Angreifer gewünschten Parameter leicht der Adresse angehängt werden. Da mich eher der kryptographische Teil interessiert, ist diese Beschreibung des Vorgehens auch völlig ausreichend für mich. Zu b) Da hast du wohl recht, es geht kein Weg dran vorbei, genauer hinzuschauen und herauszufinden, was denn die jeweiligen TLS-Versionen/-Implementierungen auszeichnet. Vielleicht reicht ja schon ein Blick in die entsprechenden RFCs. Sollte ich diesbzgl. neue Erkenntnisse erlangen, werde ich diese natürlich nochmal an dieser Stelle teilen. Hast du mal irgendwelche praktischen Erfahrungen mit diesem oder ähnlichen Seitenkanalangriffen sammeln können? Oder kennst du Tools, mit denen man einen PoC starten könnte? Danke nochmal für deinen Beitrag. Hallo, Ghandi: So ist das, wenn man von außen drauf schaut. Ich kann dich nur ermutigen / motivieren: Steig ein und komm mit auf die Abenteuerfahrt! ;) Gruß, Benyza
 
Zuletzt bearbeitet:
PoC im Sinne von "Proof of Concept"? Mir sind keine Tools bekannt, außer eben die mathematischen Hilfsmittel, wie Stift und Papier :D

hier sind html-injections möglich

Zu a) ich denke, dass die wenigsten Seiten sicherheitsrelevante Parameter über GET verschicken, eher POST. Aber auch das nimmt stark ab. Seit jquery und Ajax (hoffen die sind richtig geschrieben) wird immer mehr in den Browser ausgelagert, sodass diese Daten den Browser bereits verschlüsselt verlassen. Quasi als Schutz vor den Schwachstellen des TLSv1.x Protokolls. Ich sehe also wenige Punkte, wo dieser Angriff ausgenutzt werden könnte.
 
Ob POST oder GET ist egal, solange beides an eine gesicherte URL gehen. Beim einen Stehen die Parameter im URL, beim anderen im http request-body.Und bei Anfragen via Ajax (ob nativ oder via jQuery) werden ebenso normale GET/POSTs gemacht.
 
Zurück
Oben