KRACK - so funktioniert der Angriff auf WPA2
Das Prinzip des KRACK-Angriffs ist eigentlich ganz einfach. Es beruht auf einem allgemein bekannten Problem der Verschlüsselung, das die Designer von WPA2 eigentlich sogar umschifft hatten. Doch sie rechneten dabei nicht mit trickreichen Angreifern.
Um zu erklären, wie Angreifer, die über Funk lediglich verschlüsselte Daten mitlesen können, mit ihrer "Key Reinstallation AttaCK" (KRACK) schließlich doch Klartext in ihren Händen halten, muss man mit ein wenig Hintergrund zu Verschlüsselung und WPA2 anfangen. Doch keine Angst, es wird nicht hoch kompliziert. Das Folgende ist so weit wie möglich auf die notwendigen Basics reduziert. Wer die volle Wahrheit mit allen Details möchte, lese lieber das Paper der Forscher zu Key Reinstallation Attacks: Forcing Nonce Reuse in WPA2.
Die WPA2-Verschlüsselung beruht auf einer sehr einfachen logischen Operation auf Bit-Ebene namens XOR. Das ist ein striktes "entweder, oder". Es ergibt 1 (wahr) wenn genau eines der beiden Bits 1 ist (also bei 0x1 oder 1x0), sonst ergibt es 0 (0x0 und 1x1).
XOR ist eine in der Kryptographie sehr häufig genutzte Funktion. Mit ihr kann man sehr sichere Krypto-Systeme bauen. Insbesondere beruht das unknackbare One Time Pad darauf. Es verknüpft eine Bit-Folge von Daten mit einer Bit-Folge aus echten(!) Zufallszahlen via XOR. Solange diese als Schlüssel genutze Zufallszahlen-Sequenz nur einmal eingesetzt wird (und geheim bleibt), ist das Verfahren beweisbar sicher.
Das XOR-Problem
Aber XOR hat ein ganz zentrales, bekanntes Problem: Sobald man verschiedene Daten mit dem gleichen Schlüssel verschlüsselt, hat man verloren. (Wer das einfach glaubt und keine Lust auf die folgende Mathematik hat, überspringt den folgenden Absatz).
Eine der mathematischen Eigenschaften der XOR-Operation ist es, dass die Reihenfolge, in der man sie anwendet, völlig egal ist. Deshalb kann man aus den verschlüsselten A' und B' Daten ganz einfach Klartext errechnen, wenn zwei Dinge gegeben sind. Erstens: Die Daten wurden mit dem gleichen Schlüssel k verschlüsselt. Zweitens: der Angreifer kennt den Klartext B. Das können Sie mir entweder glauben oder Sie meditieren über folgende Zeilen:
A'x B' = (A x k) x ( B x k) = A x (kxk) x B = A x B
A x B x B = A
Verschlüsselte Pakete mit bekannten Daten lassen sich fast immer irgendwie finden oder erzwingen. Also hängt alles am Schlüssel. Sprich: Wenn man XOR-verschlüsselt, darf man nie – also NIE und NIMMER – den gleichen Schlüssel mehrfach verwenden.
Das wussten natürlich auch die Architekten von WPA2. Sie haben deshalb dafür gesorgt, dass die eingesetzten Schlüssel aus einer so genannten Nonce abgeleitet werden. Das steht für "Number used ONCE". In der Praxis besagt der Standard, dass WPA2-Clients die Nonce ständig hochzählen und somit sicherstellen, dass nie zweimal die gleiche Nonce zum Einsatz kommt. WPA2 hat die XOR-Klippe scheinbar umschifft.
Nicht so einmalige Nonces
(Bild: Mathy Vanhoef und Frank Piessens)
Diese Rechnung wurde jedoch ohne die trickreichen Forscher aus Belgien gemacht. Deren Angriff beruht darauf, dass die WLAN-Geräte ihre Nonces austauschen müssen, damit beide den gleichen Schlüssel verwenden. Dieser Austausch ist natürlich gesichert und lässt sich auch nicht knacken. Aber der Angreifer kann in den Nonce-Austausch im Funknetz eingreifen und dafür sorgen, dass Teile davon nicht beim Empfänger ankommen.
Konkret fangen die KRACKer beispielsweise eine letzte Empfangsbestätigung des WLAN-Clients ab, bevor sie den WLAN-Router erreicht. Der WLAN-Client bekommt davon nichts mit und verschlüsselt bereits munter Daten. Nach dem Verstreichen einer bestimmten Frist schickt der Router das scheinbar verloren gegangene Paket erneut – und diesmal lassen es die Angreifer durch. Der Client merkt, dass er voreilig war und macht einen Reset – und führt die namensgebende Key Reinstallation durch. In der Folge verschlüsselt der Client Daten mit der gleichen Nonce wie beim ersten Mal -- die Angreifer haben gewonnen.
Das beschreibt nur das Grundprinzip des Angriffs; in ihrem Paper stellen die belgischen Forscher eine ganze Reihe von Variationen davon vor, die dann auch unterschiedliche Szenarien wie den Einsatz von WPA2 in Heim- oder Firmennetzen abdecken (inlusive AES-CCMP, WPA-TKIP und GCMP). Letztlich kann man sowohl WLAN-Clients als auch Router angreifen. Nahezu alle Geräte mit WLAN sind in irgendeiner Form anfällig.
Eine Sonderstellung nimmt der Linux-WLAN-Treiber wpa_supplicant ein, der auch bei Android-Geräten zum Einsatz kommt. Dessen Entwickler haben die Anmerkung im Standard, dass es eine gute Idee wäre, den Schlüssel nach seiner Nutzung im Speicher mit Nullen zu überschreiben, so umgesetzt, dass durch die Key Reinstallation ein Schlüssel nur aus Nullen zum Einsatz kommt. Die daraus resultierende Verschlüsselung ist für die Katz; sie lässt sich trivial knacken.
Die Schuldfrage
Besonders spannend an diesem KRACK-Angriff ist die Tatsache, dass WPA2 eigentlich als sehr ausgereift galt. Es existierte sogar ein formeller Beweis der Sicherheit des Verfahrens. Die KRACK-Forscher erklären jedoch, dass ihr Angriff diesem Beweis auch nicht direkt widerspräche. KRACK läge schlicht außerhalb von dessen Grundannahmen. Sprich: WPA2 ist sicher, wenn Nonces nur einmal benutzt werden – und das ist ja scheinbar sicher gestellt. Dass jemand auf diesen cleveren Trick mit der Re-Transmission kommen und eine erneute Nutzung erzwingen könnte, war nicht Gegenstand der Analyse.
Sicherheitsforscher wie Matthew Green schieben zumindest einen Großteil der Verwantwortung für dieses gravierende Problem nicht auf die Hersteller sondern auf den WPA2-Standard selbst, der unter der Regie der IEEE entwickelt wurde. Die hat ihn – anders als etwa die IETF ihre RFCs zu TLS oder IPSec – nicht oder nur sehr schwer zugänglich gemacht und damit unabhängige Tests sehr erschwert.
Außerdem sei die Standardisierung selbst schlampig. Eine vollständige State Machine, die alle erlaubten Zustände und deren Übergänge exakt dokumentiert, sei heute eigentlich Stand der Technik. Da diese bei WPA2 fehlte, mussten sich die Entwickler an verschiedenen Pseudo-Code-Schnipseln entlang hangeln, was zu den angreifbaren Implementierungen führte. (ju)
