Warum wir kein WPA II PSK mehr nutzen

Moin,

WPA II PSK ist sehr stark verbreitetet. Viele reden davon, dass es nicht mehr State of the Art ist. Warum?

Dies sind alles Formulierungen die jeder von uns schon mehrfach gehört hat. Populäre Alternativen sind:

Es gibt noch eine weitere Option, die von einigen Herstellern angeboten wird: iPSK/PPSK, ein persönliche PSK für die selbe SSID. Damit kann ich kontrollieren, welche Passwörter wie häufig genutzt werden. Beim Verlassen des Unternehmens, muss ich nur ein PSK deaktivieren. Andere Geräte müssen also nicht angefasst werden. Weitere sicherheitsrelevante Probleme des PSK bleiben jedoch bestehen.

Was ist eigentlich ein PSK

Was ist eigentlich ein PSK, Pre-Shared Key? Es handelt sich hierbei im allgemeinen nicht um das Passwort, dass man sich leider häufig sehr gut merken kann. Dieses Passwort ist der Passphrase aus dem wir den PSK generieren, ein 64 Zeichen HEX Wert.

Dieser benötigte HEX Wert wird wie folgt erstellt:
Key = PBKDF2(passphrase, ssid, 4096, 256)

Definiert ist diese Formel im RFC2898.

Wie funktioniert die AES/CCMP Verschlüsselung

Wir haben jetzt unseren PSK errechnet, dieser wird noch nicht zur Verschlüsselung verwendet. Aus diesem errechnen wir den Schlüssel. Es gibt eine RSN Key Hierarchie:

– PMK (Pairwise Master Key)
–PTK (Pairwise Transient Key)
— KCK (Key Confirmation Key)
— KEK (Key Encryption Key)
— TK (Temporal Key)

PMK

Der PMK besteht aus den ersten 256 Bits des PSK bzw. MSK (802.1x).

PTK

Der PTK wird mit folgender Pseudo-Random Function generiert:
PRF(PMK,BSSID,MACaddrSTA,NAP,NSTA)

Der PTK wird auf KCK, KEK und TK aufgeteilt:

Mit dem TK werden also später unsere Daten verschlüsselt.

Das Problem

Jetzt kommen wir aber endlich zu dem technischen Problem des PSK. Wer aufmerksam mitgelesen hat, kennt die Funktionen PBKDF2 und PRF. Welche „dynamischen“ Daten verwenden wir hierfür?

In meinem eigenen WLAN sind mir alle Daten außer den beiden Nonce’s bekannt. In einem fremden WLAN fehlt mir noch der Passphrase, alle weiteren Daten sehe ich in Klarschrift in der Luft. Auch meine Nonce’s werden in Klarschrift über die Luft verteilt. Wie? Während des 4-Way Handshakes werden diese ausgetauscht. Schließlich handelt es sich um eine Nummer die auf dem AP und dem Client generiert wird. Diese muss zur anderen Seite übertragen werden, bevor wir Daten verschlüsseln können.

Schneide ich also als Mitarbeiter, dem der Passphrase bekannt ist, den 4-Way Handshake eines Clients mit, kann ich diese Session komplett entschlüsseln. Im Logistik Umfeld nutzten wir diese Möglichkeit gerne zum Troubleshooting. Im Office Umfeld, möchte ich es vielleicht nicht „jedem“ ermöglichen, die Daten mitzulesen. Selbst wenn meine Applikation über eine Verschlüsselung verfügt, z.B. HTTPS, kann ich trotzdem viele Informationen mitlesen. Und sei es nur, dass ich die DNS Anfragen monitore.

Die Lösung

Wie können wir diese Probleme nun lösen? Wie anfangs erwähnt gibt es Möglichkeiten wie z.B. PEAP-MSChapv2 oder PEAP-TLS. Hierbei handelt es sich um eine Enterprise Authentifizierung. Der Client authentifiziert sich gegenüber eines Radius Server mit seinen Benutzterdaten oder einem Zertifikat. Der PMK wird bei jeder Anmeldung erneut generiert. Dies verhindert das entschlüsseln der Daten. Selbst wenn ich eine komplette Session im WLAN inkl. 4 Way Handshake mitschneide, kann ich diese Daten nur unter Kennung der Benutzterdaten oder des privat Keys vom Zertifikat nicht entschlüsseln.

Die Daten bleiben weiterhin für eine Offline Attacke anfällig. Allerdings muss ich einen 63 stelligen ASCII Schlüssel knacken, der nur für eine Sitzung gültig ist. Zusätzlich kann ich in meiner WLAN Infrastruktur noch eine „Key Rotation“ konfigurieren. Durch diese kann ich z.B. eine Erneuerung des Schlüssels im Stunden-Takt erzwingen. Aus heutiger Sicht ist es daher sehr unwahrscheinlich, dass dieser Aufwand betrieben wird. Abhilfe wird hier WPA 3 in Zukunft bringen. Details hierzu folgen in einem weiteren Post.