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
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: