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?

  • Keine Kontrolle über den Schlüssel, wurde der Schlüssel einmal weitergegeben, habe ich keine Möglichkeit diesen mehr einzufangen.
  • Auslesen des Schlüssels, unter Windows und MacOS kann ich WPA II Schlüssel einfach auslesen und auf anderen Geräten verwenden.
  • iOS/macOS WLAN Passwort teilen, mit iOS11 wurde eine Funktion zum Teilen des WLAN PSK eingeführt. In der ersten Version noch mit jedem, in einer späteren Version nur noch mit Kontakten.
  • Mitnahme des Passwortes, verlässt ein Mitarbeiter das Unternehmen sollte ich die Passwörter ändern. Gehört hier auch das WLAN Passwort dazu, muss ich jeden Client anfassen.

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

  • PEAP-MSChapv2 -> Verwendung von Benutzernamen und Passwort zur Authentifizierung, z.B. mit einer Anbindung an das LDAP
  • PEAP-TLS -> Verwendung von Zertifikaten, Benutzter oder Client basiert

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)

  • Passphrase, ist das im allgemein bekannte WLAN Passwort, ein 8-63 Zeichen langer ASCII Schlüssel
  • SSID, ist der Name des WLANs, max. 32 Zeichen. Es dient bei der PSK Berechnung als sogenanntes „Salt“.
  • 4096, ist der Iteration Count, die Anzahl an durchläufen
  • 256, ist die Länge in Octets unseres Schlüssels.

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)

    • PMK, wird aus unserem Passphrase generiert
    • BSSID, die WLAN MAC Adresse des Access Points, der SSID
    • MACaddrST, die MAC Adresse unseres Clients
    • NAP, Nonce des Access Points
    • NSTA, Nonce des Clients

Der PTK wird auf KCK, KEK und TK aufgeteilt:

  • KCK, wird zur Überprüfung des 4-Way Handshakes und Group Key Handshake verwendet
  • KEK, wird zur Verschlüsselung des GKT und IGKT während des 4-Way Handshakes und Group Key Handshake verwendet
  • TK, unser Schlüssel für die Verschlüsselung der Daten

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?

  • Passphrase
  • SSID
  • BSSID
  • MAC Adresse, Client
  • AP Nonce
  • Station Nonce

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.

Schreibe einen Kommentar

Diese Website verwendet Akismet, um Spam zu reduzieren. Erfahre mehr darüber, wie deine Kommentardaten verarbeitet werden.