Montag, 1. M�rz 2010


Topthema

Donnerstag, 5. Juli 2007 | Topthema

About Security #112: Mobile Security — IEEE-802.11i-Verschlüsselung

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

Bei der Verschl�sselung durch CCMP (Counter Mode/CBC-MAC, vollst�ndig "Counter Mode with Cipher Block Chaining Message Authentication Code Protocol") werden nicht wie bei TKIP die eigentlichen Nachrichten (MAC Service Data Units, MSDU) verschl�sselt und integrit�tsgesch�tzt, sondern die so genannten "MAC Protocol Data Unit"- (MPDU-)Pakete. Dazu muss die Nachricht ggf. vor der Verschl�sselung fragmentiert werden. CCMP erh�lt dann die fertigen MPDUs und den aktuellen tempor�ren Schl�ssel zur Verschl�sselung und Integrit�tssicherung.

CCMP kommt mit einem Schl�ssel aus, da f�r Verschl�sselung und MIC-Berechnung einmalige Nonce-Werte f�r die Initialisierung verwendet werden. Die Nonce-Werte werden aus der MAC-Adresse des Senders und einer Sequenznummer (der Packet Number, PN) konstruiert. Durch das Einbeziehen der MAC-Adresse des Senders sind die Nonces innerhalb einer Session einmalig: Selbst wenn zwei Teilnehmer zuf�llig die gleiche PN verwenden, ergibt sich durch die eindeutige MAC-Adresse ein unterschiedlicher Nonce-Wert.

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

Die Verschl�sselung und MIC-Berechnung l�uft dann in 3 Schritten ab:

  1. Zwischen MAC-Header und Daten wird der so genannte CCMP-Header eingef�gt, in dem PN und Schl�ssel-ID gespeichert werden.
  2. Aus Teilen des MAC-Headers und den Daten wird ein Message Integrity Code (MIC) berechnet.
  3. Daten und MIC werden gemeinsam verschl�sselt.
Berechnung des MIC

Der MIC wird au�er �ber den Datenteil auch �ber die unver�nderlichen Teile des Headers berechnet, die dazu als "Additional Authentication Data"-Feld (AAD) vor die Daten kopiert werden. Sowohl Daten als auch AAD werden vor der MIC-Berechnung mit Nullbytes aufgef�llt, bis sie ein Vielfaches von 128Bit lang sind. Diese Nullbytes gehen nur in die MIC-Berechnung ein und werden nicht mit �bertragen. Um zu verhindern, dass zuf�llig mehrmals �ber die gleichen Daten ein MIC berechnet wird, wird aus dem Nonce-Wert, einem Feld mit verschiedenen Flags und einem Feld mit der L�nge des Nachrichtentextes ein erster 128-Bit-Block gebildet und vor der MIC-Berechnung vor AAD und Daten geh�ngt. Der Empf�nger bildet diesen ersten Block ebenso und kann danach seinerseits den MIC berechnen.

Wie bereits in About Security #111 erw�hnt, werden die zu sch�tzenden Daten f�r die Berechnung des CBC-MAC in Bl�cke aufgeteilt, die in diesem Fall 128 Bit lang sind. Der erste Block wird mit AES verschl�sselt und danach mit dem zweiten Block mit XOR verkn�pft. Das Ergebnis wird wieder mit AES verschl�sselt, mit dem n�chsten Block mit XOR verkn�pft, das Ergebnis mit AES verschl�sselt usw. Der letzte verschl�sselte 128-Bit-Block wird als MAC verwendet. Der Message Authentication Code MAC wird im Rahmen des IEEE 802.11 Standards "Message Integrity Code" (MIC) genannt, um eine Verwechselung mit der Hardwareadresse Media Access Control (MAC) zu verhindern. Au�erdem werden die niederwertigen 64 Bit verworfen und nur der Rest als MIC verwendet.

Verschl�sselung mit CCM

Beim Counter Mode wird ein Z�hler verschl�sselt und mit der Nachricht XOR-verkn�pft (siehe About Security #111). Seine Sicherheit h�ngt entscheidend von der Konstruktion des Z�hlers ab. In IEEE 802.11i besteht er aus 3 Feldern:

About Security: Die komplette Serie
  • einem Flag-Feld,
  • dem Nonce, der selbst wieder aus einem Byte f�r die Priorit�t, der MAC-Adresse des Senders und der Packet Number besteht und
  • dem 2 Byte langen Z�hlerfeld.

Der Nonce-Wert sorgt daf�r, dass der Z�hler f�r verschiedene Sender und verschieden Pakete eines Senders immer unterschiedlich ist. Die 16 Bit des Z�hler-Felds werden mit 1 initialisiert. Die zu verschl�sselnden Daten werden in 128 Bit lange Bl�cke aufgeteilt, der letzte Block muss nicht auf 128 Bit aufgef�llt werden. Danach werden die Bl�cke per XOR mit dem AES-verschl�sselten Z�hler verkn�pft, der nach jedem verschl�sselten Block um 1 inkrementiert wird.

Authentifizierung

Nachdem bisher der Schutz der �ber WLAN �bertragenen Daten beschrieben wurde, geht es im Folgenden um die Authentifizierung. Diese erfolgt anders als bei WEP von der Verschl�sselung und Integrit�tssicherung getrennt. Man kann dabei drei Beteiligte unterscheiden: Das WLAN, die Zugangskontrolle und die Authentifizierung. W�hrend im WLAN die eigentliche Kommunikation samt Verschl�sselung und Integrit�tssicherung abgewickelt wird, ist die Zugangskontrolle daf�r zust�ndig, dass nur authentifizierte Pakete das WLAN erreichen. Dazu befragt sie die Authentifizierung, die �ber den Zugang entscheidet. Damit nicht f�r jedes Paket eines bereits authentifizierten Kommunikationsteilnehmers erneut nachgefragt werden muss, wird die portbasierte Zugangskontrolle gem�� dem Standard IEEE 802.1x verwendet. F�r den Austausch der ben�tigten Nachrichten wird das in RFC 3748 standardisierte Extensible Authentication Protokoll EAP eingesetzt. Zwischen Client und Authentifizierer/Access Point werden die EAP-Nachrichten in EAPOL-Nachrichten gekapselt. EAPOL (EAP over LAN) wird ebenfalls in IEEE 802.1x spezifiziert.

In der n�chsten Folge wird die Beschreibung der Authentifizierung fortgesetzt. Zuerst geht es dann um die portbasierte Zugangskontrolle.

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