Channel Security

Zum Abschluss der Beschreibung von IEEE 802.11i folgt heute die Verteilung bzw. Erzeugung des Pairwise Master Keys im Rahmen eines Authentifizierungsprotokolls. Der Pairwise Master Key wird nach erfolgreicher Authentifizierung zwischen Authentifizierungsserver und Client ausgehandelt und abschließend vom Authentifizierungsserver an den Access Point übertragen. EAP bzw. EAPOL (About Security #113) 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 2716 als "EAP TLS Authentication Protocol" beschrieben wird. Das Transport-Layer-Security- (TLS-)Protokoll (definiert in RFC 4346) wurde bereits in About Security #81/ #82 und #97 vorgestellt. Auf die Beschreibung der Grundlagen wird daher hier verzichtet.

In Schritt 4 in About Security #113 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 dann folgende Nachrichten ausgetauscht (Übersicht):

1. Der Client antwortet mit einem EAP-Response-Paket, in dem eine TLS-ClientHello-Nachricht gekapselt ist, und überträgt dabei die bereits in About Security #82 beschriebenen Informationen. Von besonderem Interesse ist dabei der 32 Byte lange Random-Wert, gebildet aus einem 4 Byte langen 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 in About Security #82 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 Secrets notwendigen Informationen im Form des Premaster Secrets, verschlüsselt mit dem öffentlichen Schlüssel des Servers.
     Das 48 Byte lange Premaster 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 Premaster 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 Ciphersuit 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.

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)

In der nächsten Folge geht es um die Sicherheit von WEP, WPA und IEEE 802.11i.

Carsten Eilers

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

• About Security #108: Mobile Security – Wi-Fi Protected Access (WPA)
• About Security #109: Mobile Security – IEEE 802.11i Schlüsselhierarchien
• About Security #110: Mobile Security – IEEE 802.11i Pairwise Master Key
• About Security #111: Mobile Security – IEEE 802.11i Gruppenschlüssel
• About Security #112: Mobile Security – IEEE 802.11i Verschlüsselung
• About Security #113: Mobile Security – IEEE 802.11i Authentifizierung
• About Security #114: Mobile Security – IEEE 802.11i Pairwise Master Key
• About Security #115: Mobile Security – Sicherheit von WEP, WPA und IEEE 802.11i
• About Security #116: Mobile Security – Sicherheit von WEP, WPA und IEEE 802.11i, Teil 2
• About Security #117: Mobile Security – WLAN-Hotspots