Montag, 1. M�rz 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