Die Lücke läßt sich offenbar sehr wohl "umschiffen", indem man anstelle einer erneuten Verwendung derselben Nonce zur Verschlüsselung eines zweiten Pakets mit anderem Inhalt (daraus ergibt sich der mathematische Zusammenhang, daß man den verwendeten Wert für die Verschlüsselung rekonstruieren kann) im Falle des "Fehlers" beim Schlüsselaustausch tatsächlich "von vorne" beginnt (also auf die "reinstallation", die dem "R" im Namen KRACK den Anfangsbuchstaben spendiert, verzichtet) und damit diese "gefährliche" Wiederholung vermeidet.
Das verringert zwar die Robustheit des Schlüsselaustauschs etwas, denn es entfällt an dieser einen konkreten Stelle (bzw. an zweien, wenn man den GTK-Wechsel auch noch einbezieht in die Rechnung - einfach mal das
Paper der Belgier lesen) die Möglichkeit der Fehlerkorrektur.
Damit wird auch nicht gleich das komplette Protokoll "umdefiniert", es wird halt ein größerer "Rückschlag" beim Schlüsselaustausch in Kauf genommen, der diesen Prozess ggf. verlängern kann (oder gar zu einem kompletten Neubeginn zwingt) und in einigen Szenarien vielleicht auch zu längeren Unterbrechungen der Verbindung führen wird, als es unbedingt erforderlich wäre.
Aber das ist eben auch vorgesehen ... es kann ja genauso gut auch sein, daß der Client nach der dritten KE-Nachricht den Empfangsbereich "dauerhaft" verlassen hat und ihn auch die Wiederholungen der Nachricht nicht mehr erreichen, bis er irgendwann später mal wieder in Reichweite ist. Dann wird ja (wenn da wiederholte Aussendungen der dritten Message unbeantwortet blieben) auch nicht einfach an dieser Stelle "fortgesetzt", wenn die STA irgendwann mal wieder auftaucht, sondern genauso von vorne begonnen.
@meierchen006:
Wenn der Stick nicht tatsächlich eine Art "Mini-Router" ist (wie z.B. einige UMTS- oder LTE-Sticks, die als "virtuelle Netzwerkkarte" daherkommen), dann ist der "Client" ja nicht der USB-Stick, sondern das (Betriebs-)System, welches ihn benutzt. Wenn Du einen Rechner mit diesem Stick nur einschaltest und darauf das System nicht startest, meldet sich der Stick sehr wahrscheinlich auch nicht am AP an, oder? Wenn doch, dann wäre er "autonom" und tatsächlich betroffen ... aber eher untypisch für einen WLAN-Adapter.
Man muß auch immer noch zwischen dem Problem im "wpa_supplicant" ab 2.4 und dem generellen Reinstallation-Angriff unterscheiden. Dadurch, daß der "wpa_supplicant" besonders vorsichtig sein wollte und den Schlüssel nach dessen erster "Installation" durch binäre Nullen überschreibt (damit ihn niemand aus dem Speicher auslesen kann), wurde bei der "Neuinstallation" desselben Keys gar nicht mehr der ausgetauschte/vereinbarte Schlüssel verwendet, sondern dieser "null key". Wegen des verwendeten Verfahrens zum Verknüpfen von Daten und Schlüssel (exklusives oder - XOR) ergibt aber die Verwendung eines solchen "null keys" auch immer den Ausgangswert, also den "Klartext".
