Eine Sache, die ich hier einfach nicht verstehe ist: Wir sprechen hier mal wieder über ein Problem, das seit ewigen Zeiten bekannt ist und für das es auch seit ewige Zeiten in der Praxis bewährte Lösungen gibt. Es ist nicht nötig ständig das Rad hier neu erfinden zu wollen! Zumindenst dann nicht, wenn dabei kein besseres, sondern eine verkrüppelte Variante existierender Räder ensteht.

Mit der Problematik wie man eine sichere Verbindung zwischen zwei Endpunkten aushandelt, so dass kein Dritter eine Chance hat in den Verbindungsaufbau einzugreifen oder nacher die Sicherung aufheben zu können, auch dann nicht wenn er sämtliche ausgetauschet Daten mitlesen, manipulieren oder deren Übertragung unterbinden kann, haben sich bereits die Urväter des IKE Protokolls ab 1996 beschäftigt. Seit 1998 ist IKE ein RFC Standard und die Verfahren, die man dort ausgetüftelt hat, die kommen bis heute zur Anwendung und gelten bis heute als sicher, da es noch niemanden gelungen ist, eines davon zu brechen.

IKE ist das Protokoll, mit denen zwei IPSec Gegenstellen einen sicheren Schlüssel für eine IPSec VPN Verbindung aushandeln. Wenn es also ein Protokoll gibt, auf dass sich alle Hacker und Kryptographen in den letzten 20+ Jahre gestürtzt haben, dann IKE. Die Verfahren in IKE halten also seit über 20 Jahren allen Angriffen stand, denn bis heute kommt IKE weltweit für VPN Verbindungen zum Einsatz.

Und nicht nur für das Problem "wie bekomme ich einen sicheren Session Schlüssel" (vergleichbar mit dem Long-Term Key) hat IKE eine sehr gute Lösung, es hat auch eine Lösung für das Problem "wie kann ich dann von diesen Session Schlüssel regelmäßig schnel, kostengünstig und sicher weitere Keys ableiten, so dass ich den Verschlüsselungskey regelmäßig (selbst während einer aktiven Session) wechseln kann."

Ich bin immer wieder entsetzt, wenn ich sehe, dass Bluetooth, WLAN oder TLS/SSL Probleme schon im Protokoll aufweisen, die es so mit den IKE Verfahren niemals gegeben hätte. Ganz dumm gefragt: Warum nutzen diese Protokolle überhaupt etwas eigenes? Warum nutzen die nicht einfach direkt IKE? IKE wurde zwar entworfen, um IPSec Tunnel auszuhandeln, aber das Protokoll ist so offen, das man damit theoretisch alles aushandeln kann. Primär dient IKE erst einmal nur dazu sicher Schlüssel auszuhandeln (und den brauchen alle diese Protokolle sowieso) und einen gesicherten Kanal (ähnlicher einer TLS Verbindung) zwischen zwei Endpunkten zu erzeugen. Erst danach wird dann über diesen gesicherten Kanal eine IPSec Session ausgehandelt.

Dabei werden einfach nur Attribute hin und her gesendet, das sind einfach nur numerische Werte gefolgt von beliebigen Daten in frei definierbaren Formaten. Wie diese zu interpretieren sind, bestimmt die DOI (Domain of Interpretation) und hier ist IPSec nur eine mögliche DOI. Aktuell sind hier gerade mal 3 DOIs spezifiziert, das Feld ist aber 32 Bit, d.h. man könnte bis zu 4 Mrd DOIs definieren. Hier könnte Bluetooth, WLAN oder TLS einfach eine DOI bekommen und damit dann beliebige Parameter über IKE aushandeln. Auch gibt es jede Menge IKE Implementierungen und Code unter freien Lizenzen, d.h. man müsste sich nicht einmal die Mühe machen hier jedes mal das IKE Protokoll neu zu implementieren, sondern man hätte einfach eine fertige Implementierung genommen und der nur die neue DOI beigebracht.

Eine weitere Schwachstelle:

ZDNet (21.05.2020): New 'Spectra' attack breaks the separation between Wi-Fi and Bluetooth
Technical details to be presented in August at the Black Hat 2020 security conference.

Black Hat USA 2020 (01-08.–06.08.2020): Spectra: Breaking Separation Between Wireless Chips
Jiska Classen | Dr.-Ing., Technische Universität Darmstadt, SEEMOO
Francesco Gringoli | Associate Professor, University of Brescia