Skip to content

WLAN-Sicherheit 13 - Authentifizierung in WPA2, Teil 2

Wi-Fi Protected Access 2 (WPA2) implementiert die grundlegenden Funktionen des aktuellen Sicherheitsstandards IEEE 802.11i für drahtlose Netze nach dem IEEE 802.11 Standard (WLAN). Der allgemeine Aufbau, Schlüsselmanagement und Schlüsselhierarchie wurden bereits vorgestellt, ebenso der Pairwise Master Key PMK und Pairwise Transient Key und die Gruppenschlüssel. Auch der für die Verschlüsselung und Authentisierung verwendete "Counter-Mode/CBC-MAC" sowie die Authentifizierung wurden bereits beschrieben.

In dieser Folge geht es zum Abschluss der Beschreibung von WPA2 um die

Erzeugung und Verteilung des Pairwise Master Key (PMK)

im Rahmen eines Authentifizierungsprotokolls.

Der PMK wird nach erfolgreicher Authentifizierung zwischen Authentifizierungsserver und Client ausgehandelt und abschließend vom Authentifizierungsserver an den Access Point übertragen. EAP bzw. EAPOL dient dabei lediglich dem Transport der Nachrichten, die Aushandlung des Schlüssels erfolgt über das darin gekapselte Authentifizierungsprotokoll.

Als Beispiel soll die EAP-TLS-Methode dienen, die in RFC 5216 als "EAP-TLS Authentication Protocol" beschrieben wird. Das Transport Layer Security (TLS) Protokoll (definiert in RFC 5246) wurde bereits im Rahmen der Folgen zur Kryptographie beschrieben, auf die Beschreibung der Grundlagen werde ich daher hier verzichten.

In Schritt 4. der Authentifizierung sendet der Authentifizierungsserver ein EAP-TLS/Start-Paket an den Client und startet damit den Austausch der EAP-TLS-Nachrichten. Beim Einsatz von Zertifikaten auf Client- und Serverseite und der Verwendung von RSA für die Verschlüsselung werden danach die folgenden Nachrichten ausgetauscht:

  1. Der Client antwortet mit einem EAP-Response-Paket, in dem eine TLS-ClientHello-Nachricht gekapselt ist, und überträgt dabei die bereits bei der Beschreibung von TLS beschriebenen Informationen. Von besonderem Interesse ist dabei hier der 32-Byte-lange Random-Wert, gebildet aus einem 4-Byte-langem Unix-Zeitstempel und 28 Byte Zufallszahlen.
  2. Der Server antwortet mit einem EAP-Request-Paket, in das mindestens eine TLS-ServerHello-Nachricht und eventuell weitere TLS-Nachrichten gekapselt sind. Ein möglicher Aufbau ist folgender:
    • ServerHello
      Der Server antwortet dem Client und sendet dabei die bereits bei der Beschreibung von TLS beschriebenen Informationen. Hier interessiert wieder der Random-Wert, der analog zum Client gebildet wird und von dessen Wert verschieden ist.
    • Server Certificate
      Der Server sendet dem Client sein Zertifikat mit seinem öffentlichen Schlüssel.
    • Certificate Request
      Der Server fordert das Zertifikat des Clients an.
    • Server Hello Done
      zeigt das Ende des ServerHello-Blocks an.
  3. Der Client prüft nun die empfangenen Nachrichten und das übertragene Zertifikat. Im Erfolgsfall antwortet er mit einem EAP-Response-Paket, in dem eine oder mehrere TLS-Nachrichten gekapselt sind. Ein möglicher Aufbau ist folgender:
    • Client Certificate
      Der Client sendet sein Zertifikat an den Server.
    • Client Key Exchange
      ist die hier interessanteste Nachricht: Sie enthält die für die Berechnung des Master-Secret notwendigen Informationen im Form des Pre-Master-Secret, verschlüsselt mit dem öffentlichen Schlüssel des Servers.
      Das 48-Byte-lange Pre-Master-Secret wird aus der 2-Byte-langen Protokollversion und einer 46-Byte-langen Zufallszahl gebildet.
      Sowohl Client als auch Server können danach mithilfe einer Zufallszahlenfunktion aus dem Pre-Master-Secret und den Random-Feldern der ClientHello- und ServerHello-Nachrichten das gemeinsame Master-Secret berechnen:
      f(Pre-Master-Secret, "Master-Secret", Random)
      Random ist dabei (ClientHello.Random ¦¦ ServerHello.Random)
      Aus dem Master-Secret werden dann die Schlüssel für den Schutz der TLS-Verbindung abgeleitet.
    • Certificate Verify
      Es wird eine Prüfsumme über die ausgetauschten Authentifizierungsdaten berechnet und mit dem privaten Schlüssel des Clients signiert. Der Server prüft das Ergebnis mit den öffentlichen Schlüssel aus dem Zertifikat des Clients.
    • Change Chipher Spec
      Die im ServerHello festgelegte Ciphersuite wird mit den ausgehandelten Parametern aktiviert.
    • Finished
      beendet den Handshake und ist die erste Nachricht, die mit dem aus dem Master-Secret berechneten Schlüssel verschlüsselt wird.
  4. Bei erfolgreicher Authentifizierung des Clients antwortet der Server mit einem EAP-Request-Paket, das mindestens eine TLS-'Change Chipher Spec'- und eine TLS-Finished-Nachricht enthält. Die Finished-Nachricht enthält die Authentifizierungsdaten des Servers.
  5. Bei erfolgreicher Authentifizierung des Servers antwortet der Client mit einer leeren EAP-Response, die der Server mit einem EAP-Success beantwortet.

Das Ganze im Überblick:

Client

 
Server
0. <-- EAP-TLS/Start --
1. -- ClientHello -->
  • Prüfen/Bilden der SessionID
  • Wahl des geeigneten Schlüsselalgorithmus
  • Wahl des Komprimierungsalgorithmus
2a. <-- ServerHello --
2b. <-- Server Certificate--
2c. <-- Certificate Request --
2d. <-- ServerHelloDone --
  • Prüfen des Server-Zertifikats
  • Erzeugen des Pre-Master-Secrets
3a. -- Client Certificate -->
3b. -- Client Key Exchange -->
3c. -- Certificate Verify -->
3d. -- Change Chipher Spec -->
3e. -- Finished -->
Master-Secret berechnen (*) Master-Secret berechnen (*)
4a. <-- Change Chipher Spec --
4b. <-- Finished --
5. -- EAP-Response() -->
6. <-- EAP-Success --

(*) Master-Secret = f(Pre-Master-Secret, "Master-Secret", ClientHello.Random, ServerHello.Random)

EAP-Schlüssel und Pairwise Master Key

Mit der gleichen Zufallszahlenfunktion, mit der auch das TLS-Master-Secret berechnet wurde, werden auch die für EAP benötigten Schlüssel berechnet:

  • Aus dem TLS-Master-Secret und den Random-Feldern der ClientHello- und ServerHello-Nachrichten wird ein 128-Byte-langer Schlüsselblock berechnet, der in die jeweils 32-Byte-langen Client- und Server-Verschlüsselungs- und -Authentifizierungsschlüssel aufgeteilt wird:
    f(Master-Secret, "Client EAP encryption", Random)
    Aus diesem Schlüsselblock wird auch der so genannte AAA-Schlüssel gebildet (AAA = Authentifizierung, Autorisierung, Accounting), aus dem dann der Pairwise Master Key abgeleitet wird.
  • Aus den Random-Feldern der ClientHello- und ServerHello-Nachrichten wird ein 64-Byte-langer Schlüsselblock berechnet, aus dem die jeweils 32-Byte-langen Initialisierungsvektoren für EAP gebildet werden:
    f("", "Client EAP encryption", Random)

Ab der nächsten Folge geht es um die Sicherheit von WiFi allgemein und WPA2 bzw. IEEE 802.11i im Besonderen.

Carsten Eilers

Trackbacks

Keine Trackbacks

Kommentare

Ansicht der Kommentare: Linear | Verschachtelt

Noch keine Kommentare

Kommentar schreiben

Die angegebene E-Mail-Adresse wird nicht dargestellt, sondern nur für eventuelle Benachrichtigungen verwendet.
Standard-Text Smilies wie :-) und ;-) werden zu Bildern konvertiert.
BBCode-Formatierung erlaubt
Formular-Optionen

Kommentare werden erst nach redaktioneller Prüfung freigeschaltet!