Montag, 1. M�rz 2010


Topthema

Mittwoch, 18. Juli 2007 | Topthema

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

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

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.

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

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:

About Security: Die komplette Serie
  • 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.

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