WPA3

WPA3-Personal: Der SAE-Handshake

WPA3-Personal ersetzt den anfälligsten Teil von WPA2: die Ableitung des Schlüssels direkt aus dem Passwort. An seine Stelle tritt SAE (Simultaneous Authentication of Equals), ein passwortauthentisierter Schlüsselaustausch auf Basis des Dragonfly-Verfahrens (RFC 7664).

Grundidee

Bei WPA2-PSK gilt vereinfacht PMK = PSK — der Schlüssel hängt unmittelbar am Passwort. Der mitgeschnittene 4-Wege-Handshake enthält eine MIC, die sich offline gegen eine Passwortliste nachrechnen lässt: einmal mitschneiden, beliebig oft raten. Ein schwaches Passwort fällt in Sekunden.

SAE dreht genau das um. Das Ziel in einem Satz:

Jeder einzelne Passwortversuch soll einen aktiven Kontakt mit dem AP kosten — es soll nichts geben, das man offline durchrechnen kann.

Zusätzlich bringt SAE Forward Secrecy (alte Mitschnitte bleiben auch bei später bekanntem Passwort geschützt) und beidseitige Authentisierung (auch der AP muss die Kenntnis des Passworts beweisen).

Begriffe

SAE

Simultaneous Authentication of Equals — der Handshake von WPA3-Personal. Beide Seiten sind gleichberechtigt und laufen gleichzeitig.

Dragonfly

Der zugrunde liegende Schlüsselaustausch (RFC 7664), auf dem SAE aufsetzt.

PAKE

Password-Authenticated Key Exchange — Protokollklasse, die aus einem schwachen Geheimnis (Passwort) einen starken Sitzungsschlüssel macht, ohne das Passwort offline angreifbar zu machen.

PWE

Password Element — das Passwort, abgebildet auf einen Punkt der elliptischen Kurve. Auf beiden Seiten gleich, weil das Passwort gleich ist.

Commit

Erste Nachricht: scalar + Element. Legt die eigenen Zufallswerte fest, ohne sie preiszugeben.

Confirm

Zweite Nachricht: ein HMAC über den bisherigen Austausch. Beweist, dass man dasselbe K — und damit dasselbe Passwort — hat.

K

Das gemeinsame Geheimnis aus dem Commit-Austausch. Auf beiden Seiten identisch, wird nie übertragen.

PMK

Pairwise Master Key — wird bei WPA3 aus K abgeleitet (nicht mehr = Passwort) und speist danach den normalen 4-Wege-Handshake für die Sitzungsschlüssel.

ECDLP

Elliptic Curve Discrete Logarithm Problem — die „Einbahnstraße“, die verhindert, aus dem öffentlichen scalar das geheime rand zurückzurechnen.

H2E

Hash-to-Element — modernes Verfahren zur PWE-Bildung, das die älteren „hunting and pecking“-Seitenkanäle (Dragonblood) schließt.

Der Handshake

Client (STA) und Access Point kennen beide nur das Passwort — kein Server, keine Zertifikate. Der Ablauf:

1. PWE bilden — beide leiten aus demselben Passwort denselben Punkt PWE auf der Kurve ab.
2. Commit austauschen — jede Seite würfelt zwei geheime Zufallszahlen rand und mask, bildet daraus scalar und Element und schickt beides. Ab hier ist es mitschneidbar.
3. K berechnen — jede Seite kombiniert das empfangene Commit mit dem eigenen rand. Beide landen beim selben Geheimnis K, das nie gesendet wird.
4. Confirm austauschen — aus K wird KCK abgeleitet, damit ein HMAC gebildet und gegenseitig geprüft. Passt er beidseitig, steht der PMK.
5. Danach läuft der gewohnte 4-Wege-Handshake und leitet aus dem PMK die Sitzungsschlüssel (PTK) ab.

„Simultaneous“ heißt: Es gibt kein Client-fragt/Server-antwortet. Beide Seiten erzeugen ihr Commit unabhängig und gleichzeitig — das Protokoll ist symmetrisch.

Berechnungen

Die Abbildung des Passworts auf einen Kurvenpunkt:

PWE = f(Passwort)

Das Commit — scalar versteckt rand in der Summe, Element versteckt mask auf der Kurve (r ist die Ordnung der Gruppe, ein öffentlicher Parameter):

scalar = (rand + mask) mod r

Element = −mask · PWE

Das gemeinsame Geheimnis — jede Seite rechnet mit dem Commit der Gegenseite und dem eigenen rand:

K = rand · (scalar_peer · PWE + Element_peer)

Setzt man scalar_peer · PWE + Element_peer = rand_peer · PWE ein (das mask hebt sich weg), ergibt sich auf beiden Seiten dasselbe:

K = rand_C · rand_A · PWE

Aus K werden schließlich KCK und PMK abgeleitet, und der Confirm beweist beidseitig die Kenntnis des Passworts:

confirm = HMAC(KCK, transcript)

Warum kein Offline-Angriff

Ein Angreifer schneidet den kompletten Handshake mit. In der Hand hat er dann nur die übertragenen Werte: scalar, Element und confirm beider Seiten.

Um ein geratenes Passwort zu prüfen, müsste er confirm nachrechnen — dafür braucht er K, und dafür wiederum das geheime rand der Gegenseite. Das steckt im scalar verborgen und ist durch das ECDLP nicht rückrechenbar. Es gibt also nichts, wogegen sich ein Rateversuch offline testen ließe.

Die einzige Möglichkeit, ein Passwort zu prüfen, ist ein frischer, aktiver SAE-Lauf gegen den echten AP: ein Versuch = ein Handshake. Der AP kann mitzählen, drosseln und sperren. Aus „Milliarden pro Sekunde offline“ wird „einer nach dem anderen, online, beobachtbar“.

	WPA2-PSK	WPA3-SAE
PMK	= PSK (direkt aus dem Passwort)	aus dem SAE-Austausch abgeleitet
Im Mitschnitt	eine gegen Wortliste testbare MIC	nur scalar/Element/confirm — nichts Testbares
Passwort raten	offline, beliebig schnell	nur online, ein Versuch pro Handshake
Forward Secrecy	nein	ja — frische Zufallswerte je Sitzung
Rogue-AP	Client authentisiert AP nicht wirklich	beidseitiger Beweis — ohne Passwort kein Erfolg

Drei Eigenschaften gewinnt WPA3 damit auf einmal: kein Offline-Wörterbuchangriff, Forward Secrecy pro Sitzung und beidseitige Authentisierung. Alle drei fallen direkt aus der PAKE-Konstruktion.

Angriffe (Ausblick)

SAE selbst ist mathematisch robust; angreifbar wird WPA3 an zwei anderen Stellen, die ein eigenes Kapitel bekommen:

Transition-Mode-Downgrade

Läuft ein Netz im WPA2/WPA3-Mischbetrieb, kann ein Angreifer einen Rogue-AP aufstellen, der nur WPA2 anbietet. Der Client fällt zurück — und dann greift der klassische WPA2-Offline-Angriff. Gegenmaßnahme: WPA3-only konfigurieren.

Dragonblood

Seitenkanäle (Timing/Cache) beim älteren „hunting and pecking“ der PWE-Bildung, über die sich Teilinformationen über das Passwort abgreifen ließen. Mit Hash-to-Element (H2E) geschlossen.

Links

• RFC 7664 — Dragonfly Key Exchange
• Wi-Fi Alliance — WPA3 Specification
• Vanhoef, Ronen: Dragonblood: Analyzing the Dragonfly Handshake of WPA3 and EAP-pwd (2019)