Dipl.-Inform. Carsten Eilers

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