Sweet32 beendet eine Ära
- Details
- Veröffentlicht: Sonntag, 28. August 2016 23:08
Bislang galten Kollisionsangriffe auf Block Cipher ohne Kenntnis des verwendeten Keys als theoretisch möglich, aber für reale Angriffe unattraktiv, weil für deren Erfolg Plaintext teilweise vorausgeahnt werden muss und Gigabytes mitgeschnittener Daten nur wenige Bits Ertrag verheißen. Was jedoch, wenn Teile des Plaintexts vom Angreifer selbst leicht vorgegeben und über den Browser des Opfers die benötigten Datenmengen unauffällig versendet werden können und am Ende die Authentifizierung einer HTTPS oder VPN Session herausspringt? Karhikeyan Bhargavan und Gaëtan Leurent, Forscher des französischen Inria Instituts, demonstrieren in ihrem letzte Woche veröffentlichten Paper nun erstmals die Durchführbarkeit eines Angriffs (den sie auf den Namen Sweet32 getauft haben) auf ältere, aber durchaus noch gebräuchliche 64-Bit Block Cipher wie 3DES und Blowfish (AES dagegen arbeitet mit einer Blockgröße von 128 Bit) mit lohnenswerten Ergebnissen. In weniger als zwei Tagen gelang es ihnen, den Session Cookie einer HTTPS Session und die BasicAuth Credentials einer OpenVPN-Verbindung zu rekonstruieren.
Block Cipher
Im Gegensatz zu Stream Ciphern, bei denen die Verschlüsselung Bit- oder Byte-weise erfolgt, verschlüsseln Block Cipher ihrem Namen entsprechend ganze Blöcke von Plaintext in Blöcke von Ciphertext. Bei Verwendung desselben Keys überführt ein Block Cipher dabei denselben Block Plaintext immer in denselben Block Ciphertext. Um trotzdem eine zufällige, nicht dem Plaintext-Muster entsprechende, Verteilung von Ciphertext-Blöcken zu erreichen, arbeiten Block Cipher in sogenannten Betriebsarten, TLS z. B. zumeist im Cipher Block Chaining (CBC) Mode, wie bei Wikipedia dargestellt:
Im CBC Mode wird der zu verschlüsselnde Plaintext P zunächst mit einem im vorhergehenden Schritt erzeugten Block (entweder dem zufälligen Initialization Vector IV oder dem vorherigen Ciphertext C(i-1)) XOR verknüpft und erst dann mit dem Key K verschlüsselt. Dadurch erhält man für gleiche Plaintext-Blöcke unterschiedliche Ciphertext-Blöcke, so dass vom Ciphertext nicht auf den ursprünglichen Plaintext zurückgeschlossen werden kann.
Soweit so gut. Die Sicherheit von Block Ciphern hängt jedoch trotz dieser Verschleierung nicht nur von der Key-Länge ab, sondern genauso und unabhängig davon, von der Blockgröße. Die Datenmenge, die mit demselben Key sicher verschlüsselt werden kann, ist durch die Blockgröße limitiert. Sieht ein Angreifer zu viel mit demselben Key verschlüsselten Ciphertext, steigt die Gefahr von Kollisionen, d. h. ein Sniffer sieht denselben Ciphertext irgendwann ein zweites Mal. Da der Verschlüsselungsalgorithmus deterministisch ist, heißt das, dass die XOR-Verknüpfung aus (P ⊕ C(i-1)) gleich der des früheren Auftretens (P' ⊕ C'(i'-1)) ist. Kann der Angreifer damit etwas anfangen? Ja, und zwar dann, wenn ihm einer der Plaintext-Blöcke bekannt ist. In dem Fall geht der fehlende Plaintext-Block direkt aus dem bekannten und den mitgeschnittenen Ciphertext-Blöcken hervor.
Kollisionen und das Geburtstagsparadoxon
Sichere Cipher sind dadurch gekennzeichnet, dass sie keine bessere Angriffsmöglichkeit bieten als Brute Force. Für den Key von 3DES gilt dies als zutreffend, da wir den Ciphertext nur mit dem tatsächlichen Key entschlüsseln können. Im Falle der oben beschriebenen Kollisionen suchen wir jedoch nicht nach einem bestimmten Block von Ciphertext, sondern nur nach zwei identischen. Hier findet das Geburtstagsparadoxon Anwendung, dass genau mit diesem Unterschied spielt. Es besagt, dass es, für die meisten Menschen im ersten Moment paradoxerweise, lediglich 23 sich zufällig in einem Raum oder auf dem Fussballplatz zusammengefundener Personen bedarf, um mit einer mehr als 50%igen Change zwei in dieser kleinen Gruppe vorzufinden, die am gleichen Tag Geburtstag haben.
Übertragen auf unsere Block Cipher bedeutet dies, dass aufgrund des Geburtstagsparadoxons bei einem Block Cipher der Länge n Bit mit hoher Wahrscheinlichkeit Kollisionen nicht erst nach 2n Blöcken auftreten, sondern bereits nach ungefähr 2n/2. Für ältere Block Cipher, die wie 3DES und Blowfish mit einer Blockgröße von 64 Bit operieren, liegt diese Birthday Bound also bei ca. 232 Blöcken. Das entspräche 32 GB mitzuschneidendem Datenverkehr. Diese Zahl erhöht sich in unserem Szenario deutlich, weil für den Angreifer nur solche Kollisionen zum Ziel führen, die sowohl einen von ihm vorgegebenen Plaintext als auch ein Geheimnis (z. B. einen Teil des HTTPS Session Cookies) enthalten. Auf der anderen Seite können Bhargavan und Leurent allerdings davon ausgehen, dass ihnen der Plaintext bis auf den Cookie bekannt ist.
Der Angriff...
Wir nehmen an, dass unser Opfer sich auf einer mittels 3DES gesicherten HTTPS-Seite eingeloggt hat. Der Angreifer lockt es auf eine von ihm kontrollierte Webseite, in die er einen Schnipsel Code integriert hat, der den bei obigem Login gesetzten Session Cookie (z. B. mittels eingebettetem Image Request) immer wieder an die HTTPS-Seite sendet und dadurch die benötigten Kollisionen erzeugt. Der HTTPS Traffic zwischen Client und Server wird vom Angreifer mitgeschnitten.
Bei ihren Demo-Angriffen benötigten Bhargavan und Leurent tatsächlich 30,5 Stunden / 610 GB Traffic, um einen 16 Byte langen HTTPS (3DES) Session Cookie zu rekonstruieren und 18,6 Stunden / 705 GB Traffic für den 16 Byte Authentisierungstoken einer OpenVPN (Blowfish) Session.
Sweet32 in der Praxis
Allgemein sind die beschriebenen Probleme von Block Ciphern mit geringer Blockgröße seit langem bekannt. Mit Sweet32 zeigen Bhargavan und Leurent das erste Mal, wie diese Schwächen in einem wenn auch nicht sehr praktikablen, — Wer nicht gerade Madonna oder Barack Obama ist, braucht sicher nicht zu befürchten, dass seine Social Media Credentials auf diese Weise gestohlen werden. — so doch realistischen Szenario ausgenutzt werden können.
Nicht umsonst arbeitet der heute üblicherweise verwendete AES mit einer Blockgröße von 128 Bit und es gibt keinen technischen Grund, für VPN- oder HTTPS-Verbindungen 3DES AES vorzuziehen. Die klare Empfehlung lautet, 64-Bit Block Cipher abzuschalten. 3DES indes wird, hauptsächlich zur Kompatibilität mit dem von Microsoft seit 2014 nicht mehr unterstützten Windows XP und dessen IE6, von den meisten Webservern zusätzlich angeboten, was die Möglichkeit von Downgrade-Angriffen, auch auf aktuelle Systeme, zumindest offenhält.
Überhaupt möglich wird der Angriff durch VPN- und Webserver, die die sicheren Verbindungen für die enorme Menge benötigter Daten lange genug offenhalten und Clients, die sich dem fügen. Moderne Webserver limitieren standardmäßig die Anzahl der Requests innerhalb einer HTTPS/1.1 Keep Alive Session, Apache bspw. auf 100, die für den Angriff nicht ausreichen. Der von Microsoft nicht mehr unterstützte IIS 6.0 auf Windows 2003 Server erlaubt dauerhafte HTTPS Sessions und bietet ungepatcht keine höherwertigeren Cipher als RC4 und 3DES. Unter den Top 10.000 Webseiten fanden Bhargavan und Leurent einen Anteil von 0,6%, die mit modernen Clients 3DES aushandeln und zudem mindestens 800.000 Anfragen innerhalb einer Session zulassen, darunter eine Login-Seite von Ebay.
Dort, wo 64-Bit Block Cipher nicht abgeschaltet werden können, sind die Betreiber von Servern und Clients aufgerufen,
- sie nur als Fallback zu solchen mit einer Blockgröße von wenigstens 128 Bit einzusetzen und
- die Datenmenge, die mit ein und demselben Key verschlüsselt wird, weit unterhalb der Birthday Bound zu halten
Mit Hilfe dieser zumeist leicht konfigurierbaren Maßnahmen können veraltete Server und Clients, deren letzte Nutzer sich erfahrungsgemäß erst dann von ihnen trennen, wenn sie erkennen, dass chinesische Bügeleisen die Kontrolle über ihre Systeme erlangt haben, weiterhin sicher kommunizieren.
Referenzen:
1. https://sweet32.info/SWEET32_CCS16.pdf
3. https://de.wikipedia.org/wiki/Cipher_Block_Chaining_Mode
4. Bruce Schneier. Angewandte Kryptographie. Addison-Wesley, 1996
Bild: https://de.wikipedia.org/wiki/Cipher_Block_Chaining_Mode