Samstag, 31. Juli 2010


Topthema

Donnerstag, 21. Juni 2007 | Topthema

About Security #110: Mobile Security — IEEE 802.11i Pairwise Master Key

(Link zum Artikel: http://www.entwickler.de/php/kolumnen/036396)

Die Beschreibung von IEEE 802.11i wird mit der Installation des Pairwise Master Key (PMK) fortgesetzt. Für dessen Verteilung gibt es, wie bereits in About Security #109 erwähnt, zwei Möglichkeiten: Entweder in Form eines vorher verteilten Preshared Keys (PSK) oder temporär im Rahmen eines Zugriffskontrollprotokolls. Die Verwendung eines PSK ist nur ratsam, wenn kein Authentifizierungsserver zu Verfügung steht. Statt eines beliebigen (am besten zufälligen) 256-Bit-Schlüssels werden dabei meist 32-Byte-Worte verwendet. Schlimmstenfalls werden sogar tatsächliche Wörter der Umgangssprache verwendet und damit ein Wörterbuchangriff ermöglicht. IEEE 802.11i beschreibt im Anhang eine Möglichkeit, um mithilfe der Password Based Key Derivation Function 2 – PBKDF2, definiert im Public Key Cryptography Standard #5 (PKCS #5) – aus der als PSK verteilen Passphrase, der SSID und der SSID-Länge einen 256 Bit langen PMK zu berechnen.

N E U ! Security aktuell
Täglich aktuelle Security-Infos!

Temporärer Schlüssel

Besser als die Verwendung von PSKs ist die Nutzung eines temporären Schlüssels, auch als serverbasierter Schlüssel bezeichnet, der während der Authentifizierung erzeugt wird. An der Authentifizierung sind im Rahmen von IEEE 802.11i drei Parteien beteiligt: Der Client, der Authentifizierer (der in diesem Fall eher eine Zugangskontrollfunktion besitzt, i.d.R. ein Access Point) und ein Authentifizierungsserver, der die eigentliche Authentifizierung des Clients übernimmt. Der Authentifizierungs-Request des Clients wird vom Authentifizierer an den Authentifizierungsserver weitergereicht. Client und Authentifizierungsserver wickeln dann die eigentliche Authentifizierung untereinander ab. Entsprechend der Antwort des Authentifizierungsservers lässt dann der Authentifizierer den Zugang zu oder verbietet ihn. Auf dem Authentifizierungsserver können verschiedene so genannte Upper-Layer-Authentifizierungsprotokolle eingesetzt werden, von denen einige im Zuge der Authentifizierung über das Extensible Authentication Protocol (EAP, RFC 3748) einen zufälligen PMK erzeugen können. Der dabei erzeugte PMK muss abschließend noch vom Authentifizierungsserver an den Authentifizierer übertragen werden.

Client Authentifizierer Authentifizierungs-
server

<-- 802.1x EAP Request --
 
-- 802.1x EAP Request -->
 
-- Access Request (EAP Request) -->
 
<----- EAP Authentication Protocol Exchange ----->
 
<-- OK / EAP Success / Schlüssel --
 
<-- 802.1x EAP Success --
Der Pairwise Transient Key

Nachdem auf beiden Kommunikationsteilnehmern der PMK gespeichert wurde, kann daraus der Pairwise Transient Key (PTK) und können daraus schließlich die temporären Schlüssel für die eigentliche Kommunikation gebildet werden. Der PTK wird in einem 4-Wege-Handshake ausgehandelt. Sowohl Client als auch Authentifizierer (in der Regel ein Access Point) erzeugen zuerst Zufallsdaten (Nonces). Die des Clients wird als SNonce (S für Supplicant), die des Authentifizierers als ANonce bezeichnet.

About Security: Die komplette Serie
  • Schritt 1:
    Der Authentifizierer sendet seinen Nonce-Wert an den Client. Der berechnet aus dem PMK, seiner und der MAC-Adresse des Authentifizierers sowie den beiden Nonces den PTK, aus dem die benötigten temporären Schlüssel abgeleitet werden.
  • Schritt 2:
    Der Client sendet seinen Nonce und dessen EAPOL-MIC-Wert an den Authentifizierer. Der Authentifizierer berechnet nun analog zum Client ebenfalls den PTK. Dieser wurde daher niemals übertragen. Aus dem PTK werden dann die temporären Schlüssel abgeleitet und damit der übertragene EAPOL-MIC-Wert geprüft.
  • Schritt 3:
    Der Authentifizierer überträgt den für die Verschlüsselung von Multicast-Paketen verwendeten GTK. Die Übertragung erfolgt durch den EAPOL-Schlüssel geschützt, außerdem wird der EAPOL-MIC-Wert des GTK übertragen.
  • Schritt 4:
    Der Client antwortet mit dem empfangenen, durch den EAPOL-Schlüssel verschlüsselten EAPOL-MIC. Stimmt der mit dem übertragenen Wert überein, wurde der GTK nicht manipuliert und die verschlüsselte Kommunikation kann beginnen.
Client Authentifizierer

Kennt PMK
Erzeugt SNonce
Kennt PMK
Erzeugt ANonce
<----------- ANonce ------------
Berechnet PTK
-- SNonce, EAPOL-MIC(SNonce) -->
Berechnet PTK
Stellt GTK bereit
Verwendet PTK
<- EAPOL(GTK, EAPOL-MIC(GTK)) --
Verwendet PTK und GTP
---- EAPOL(EAPOL-MIC(GTK)) ---->
 
Sichere Kommunikation möglich

Wird kein GTK benötigt, vereinfacht dies Schritt 3 und 4 des Handshakes:

  • Schritt 3 ohne Group Temporary Key (GTK):
    Der Authentifizierer teilt dem Client mit, dass der ausgehandelte PTK aktiviert werden kann. Diese Nachricht wird mit ihrem EAPOL-MIC-Wert geschützt.
  • Schritt 4 ohne Group Temporary Key (GTK):
    Der Client bestätigt dem Authentifizierer, dass der ausgehandelte PTK aktiviert werden kann. Diese Nachricht wird ebenfalls mit ihrem EAPOL-MIC-Wert geschützt.
    Anschließend aktivieren beide den PTK.

In der nächsten Folge wird die Beschreibung von 802.11i mit der Beschreibung der Gruppenschlüssel fortgesetzt.

Wenn Sie Fragen oder Themenvorschläge haben, können Sie diese gerne an die angegebene E-Mail-Adresse senden oder im Security-Forum einbringen!

Carsten Eilers

About Security – Übersicht zum aktuellen Thema "Mobile Security – WPA, WPA2 und IEEE 802.11i"

Kommentare

Folgende Links könnten Sie auch interessieren