IEEE 802.11i-2004 - IEEE 802.11i-2004

IEEE 802.11i-2004 , kurz 802.11i , ist eine Änderung des ursprünglichen IEEE 802.11 , das als Wi-Fi Protected Access II (WPA2) implementiert ist . Der Standardentwurf wurde am 24. Juni 2004 ratifiziert. Dieser Standard legt Sicherheitsmechanismen für drahtlose Netzwerke fest und ersetzt die kurze Authentifizierungs- und Datenschutzklausel des ursprünglichen Standards durch eine detaillierte Sicherheitsklausel . Bei dem Verfahren wird die Änderung deprecated gebrochen Wired Equivalent Privacy (WEP), während es später in den veröffentlichten aufgenommen wurde IEEE 802.11-2007 Standard.

Ersatz von WEP

802.11i ersetzt die vorherige Sicherheitsspezifikation Wired Equivalent Privacy (WEP), bei der Sicherheitslücken festgestellt wurden. Wi-Fi Protected Access (WPA) wurde zuvor von der Wi-Fi Alliance als Zwischenlösung für WEP-Unsicherheiten eingeführt. WPA implementierte eine Teilmenge eines Entwurfs von 802.11i. Die Wi-Fi Alliance bezeichnet ihre genehmigte, interoperable Implementierung des vollständigen 802.11i als WPA2 , auch RSN (Robust Security) genannt. 802.11i verwendet die AES- Blockverschlüsselung ( Advanced Encryption Standard ) , während WEP und WPA die RC4- Stream-Verschlüsselung verwenden .

Protokolloperation

IEEE 802.11i erweitert IEEE 802.11-1999 durch die Bereitstellung eines robusten Sicherheitsnetzwerks (RSN) mit zwei neuen Protokollen: dem Vier-Wege-Handshake und dem Gruppenschlüssel-Handshake. Diese verwenden die in IEEE 802.1X beschriebenen Authentifizierungsdienste und die Portzugriffskontrolle , um die entsprechenden kryptografischen Schlüssel einzurichten und zu ändern. Das RSN ist ein Sicherheitsnetzwerk, das nur die Erstellung robuster Sicherheitsnetzwerkzuordnungen (RSNAs) ermöglicht, bei denen es sich um eine Art von Zuordnung handelt, die von zwei Stationen (STAs) verwendet wird, wenn das Verfahren zum Herstellen der Authentifizierung oder Zuordnung zwischen ihnen die 4-Wege-Zuordnung umfasst Handschlag.

Der Standard bietet auch zwei RSNA-Protokolle zur Vertraulichkeit und Integrität von Daten, TKIP und CCMP , wobei die Implementierung von CCMP obligatorisch ist, da die Vertraulichkeits- und Integritätsmechanismen von TKIP nicht so robust sind wie die von CCMP. Der Hauptzweck der Implementierung von TKIP bestand darin, dass der Algorithmus innerhalb der Funktionen der meisten alten Geräte implementiert werden sollte, die nur WEP unterstützen.

Der anfängliche Authentifizierungsprozess wird entweder mit einem Pre-Shared Key (PSK) oder nach einem EAP- Austausch über 802.1X (bekannt als EAPOL , für das ein Authentifizierungsserver erforderlich ist) ausgeführt. Dieser Prozess stellt sicher, dass die Client Station (STA) beim Access Point (AP) authentifiziert wird. Nach der PSK- oder 802.1X-Authentifizierung wird ein gemeinsamer geheimer Schlüssel generiert, der als Pairwise Master Key (PMK) bezeichnet wird. Bei der PSK-Authentifizierung ist das PMK tatsächlich das PSK, das normalerweise aus dem WLAN-Kennwort abgeleitet wird, indem es eine Schlüsselableitungsfunktion durchläuft , die SHA-1 als kryptografische Hash-Funktion verwendet . Wenn ein 802.1X-EAP-Austausch durchgeführt wurde, wird das PMK aus den vom Authentifizierungsserver bereitgestellten EAP-Parametern abgeleitet.

Vier-Wege-Handschlag

Daumen in 802.11i

Der Vier-Wege-Handshake ist so konzipiert, dass der Zugriffspunkt (oder Authentifikator) und der drahtlose Client (oder Supplicant) unabhängig voneinander beweisen können, dass sie das PSK / PMK kennen, ohne jemals den Schlüssel preiszugeben. Anstatt den Schlüssel offenzulegen, verschlüsseln der Access Point (AP) und der Client Nachrichten miteinander - die nur mit dem bereits freigegebenen PMK entschlüsselt werden können - und wenn die Entschlüsselung der Nachrichten erfolgreich war, beweist dies die Kenntnis des PMK. Der Vier-Wege-Handshake ist entscheidend für den Schutz des PMK vor böswilligen Zugriffspunkten - beispielsweise der SSID eines Angreifers, die sich als echter Zugriffspunkt ausgibt -, damit der Client dem Zugriffspunkt niemals sein PMK mitteilen muss.

Das PMK ist für die gesamte Sitzung ausgelegt und sollte so wenig wie möglich belichtet werden. Daher müssen Schlüssel zum Verschlüsseln des Datenverkehrs abgeleitet werden. Ein Vier-Wege-Handshake wird verwendet, um einen anderen Schlüssel zu erstellen, der als Pairwise Transient Key (PTK) bezeichnet wird. Das PTK wird durch Verketten der folgenden Attribute generiert : PMK, AP Nonce (ANonce), STA Nonce (SNonce), AP MAC-Adresse und STA MAC-Adresse. Das Produkt wird dann einer Pseudozufallsfunktion unterzogen . Der Handshake liefert auch den GTK (Group Temporal Key), der zum Entschlüsseln von Multicast- und Broadcast-Verkehr verwendet wird.

Die tatsächlichen Nachrichten, die während des Handshakes ausgetauscht werden, sind in der Abbildung dargestellt und werden unten erläutert (alle Nachrichten werden als EAPOL- Schlüsselrahmen gesendet ):

  1. Der AP sendet einen Nonce-Wert (ANonce) zusammen mit einem Key Replay Counter an die STA. Diese Zahl wird verwendet, um mit jedem gesendeten Nachrichtenpaar übereinzustimmen und wiedergegebene Nachrichten zu verwerfen. Die STA verfügt nun über alle Attribute zum Erstellen des PTK.
  2. Die STA sendet ihren eigenen Nonce-Wert (SNonce) zusammen mit einem Message Integrity Code (MIC ) an den AP , einschließlich der Authentifizierung, bei der es sich tatsächlich um einen Message Authentication and Integrity Code (MAIC) handelt, und des Key Replay Counter, der identisch ist als Nachricht 1, damit AP mit der richtigen Nachricht 1 übereinstimmt.
  3. Der AP überprüft Nachricht 2, indem er das MIC-, RSN-, ANonce- und Key Replay-Zählerfeld überprüft und, falls gültig, die GTK mit einem anderen MIC erstellt und sendet.
  4. Die STA überprüft Nachricht 3, indem sie das MIC- und das Key Replay Counter-Feld überprüft und, falls gültig, eine Bestätigung an den AP sendet.

Der Pairwise Transient Key (64 Byte) ist in fünf separate Schlüssel unterteilt:

  1. 16 Byte EAPOL-Key Confirmation Key (KCK) - Wird zum Berechnen des MIC für die WPA EAPOL Key-Nachricht verwendet
  2. 16 Byte EAPOL-Key Encryption Key (KEK) - AP verwendet diesen Schlüssel, um zusätzliche Daten zu verschlüsseln, die (im Feld 'Key Data') an den Client gesendet werden (z. B. RSN IE oder GTK).
  3. 16 Byte Temporal Key (TK) - Zum Ver- und Entschlüsseln von Unicast-Datenpaketen
  4. 8 Byte Michael MIC Authenticator Tx Key - Wird zum Berechnen von MIC für vom AP übertragene Unicast-Datenpakete verwendet
  5. 8 Byte Michael MIC Authenticator Rx Key - Wird zum Berechnen von MIC für von der Station übertragene Unicast-Datenpakete verwendet

Der zeitliche Gruppenschlüssel (32 Byte) ist in drei separate Schlüssel unterteilt:

  1. 16 Byte Group Temporal Encryption Key - zum Ver- und Entschlüsseln von Multicast- und Broadcast-Datenpaketen
  2. 8 Byte Michael MIC Authenticator Tx Key - wird zum Berechnen von MIC für Multicast- und Broadcast-Pakete verwendet, die vom AP übertragen werden
  3. 8 Byte Michael MIC Authenticator Rx Key - derzeit nicht verwendet, da Stationen keinen Multicast-Verkehr senden

Die Michael MIC Authenticator Tx / Rx-Schlüssel sowohl im PTK als auch im GTK werden nur verwendet, wenn das Netzwerk TKIP zum Verschlüsseln der Daten verwendet.

Es hat sich gezeigt, dass dieser Vier-Wege-Handschlag für KRACK anfällig ist .

Gruppenschlüssel-Handshake

Der im Netzwerk verwendete Group Temporal Key (GTK) muss möglicherweise aktualisiert werden, da ein voreingestellter Timer abgelaufen ist. Wenn ein Gerät das Netzwerk verlässt, muss auch die GTK aktualisiert werden. Dies soll verhindern, dass das Gerät weitere Multicast- oder Broadcast-Nachrichten vom AP empfängt.

Um die Aktualisierung durchzuführen, definiert 802.11i einen Gruppenschlüssel-Handshake , der aus einem bidirektionalen Handshake besteht:

  1. Der AP sendet die neue GTK an jede STA im Netzwerk. Die GTK wird mit der dieser STA zugewiesenen KEK verschlüsselt und schützt die Daten mithilfe eines MIC vor Manipulationen .
  2. Die STA bestätigt die neue GTK und antwortet dem AP.

CCMP-Übersicht

CCMP basiert auf dem Zähler mit CBC-MAC (CCM) -Modus des AES-Verschlüsselungsalgorithmus. CCM kombiniert CTR für Vertraulichkeit und CBC-MAC für Authentifizierung und Integrität. CCM schützt die Integrität sowohl des MPDU-Datenfelds als auch ausgewählter Teile des IEEE 802.11 MPDU-Headers.

Schlüsselhierarchie

RSNA definiert zwei Schlüsselhierarchien:

  1. Paarweise Schlüsselhierarchie zum Schutz des Unicast-Verkehrs
  2. GTK, eine Hierarchie, die aus einem einzigen Schlüssel besteht, um Multicast- und Broadcast-Verkehr zu schützen

Die Beschreibung der Schlüsselhierarchien verwendet die folgenden zwei Funktionen:

  • L (Str, F, L) - Extrahieren Sie von Str ausgehend von links die Bits F bis F + L - 1.
  • PRF-n - Pseudozufallsfunktion, die n Ausgabebits erzeugt. Es gibt die Versionen 128, 192, 256, 384 und 512, von denen jede diese Anzahl von Bits ausgibt.

Die paarweise Schlüsselhierarchie verwendet PRF-384 oder PRF-512, um sitzungsspezifische Schlüssel von einem PMK abzuleiten, wodurch ein PTK generiert wird, das in einen KCK und einen KEK sowie alle vom MAC zum Schutz der Unicast-Kommunikation verwendeten temporären Schlüssel aufgeteilt wird.

Die GTK muss eine Zufallszahl sein, die auch unter Verwendung von PRF-n, normalerweise PRF-128 oder PRF-256, generiert wird. In diesem Modell verwendet die Gruppenschlüsselhierarchie eine GMK (Group Master Key) und generiert eine GTK.

MAC-Rahmenformate

Rahmensteuerungsfeld

Rahmensteuerungsfeld
Unterfeld Protokollversion Art Subtyp Zu DS Von DS Weitere Fragmente Wiederholen Energieverwaltung Weitere Daten Geschützter Rahmen Aufträge
Bits 2 Bits 2 Bits 4 Bits 1 Bit 1 Bit 1 Bit 1 Bit 1 Bit 1 Bit 1 Bit 1 Bit

Geschütztes Rahmenfeld

"Das Feld" Geschützter Rahmen "ist 1 Bit lang. Das Feld" Geschützter Rahmen "wird auf 1 gesetzt, wenn das Feld" Rahmenkörper "Informationen enthält, die von einem kryptografischen Kapselungsalgorithmus verarbeitet wurden. Das Feld" Geschützter Rahmen "wird nur innerhalb von Datenrahmen des Typs auf 1 gesetzt Daten und innerhalb von Verwaltungsrahmen vom Typ Verwaltung, Subtyp Authentifizierung. Das Feld Geschützter Rahmen wird in allen anderen Rahmen auf 0 gesetzt. Wenn das Feld Bit geschützter Rahmen in einem Datenrahmen auf 1 gesetzt wird, wird das Feld Rahmenkörper unter Verwendung der kryptografischen Kapselung geschützt Algorithmus und erweitert wie in Abschnitt 8 definiert. Nur WEP ist als kryptografischer Kapselungsalgorithmus für Verwaltungsrahmen des Subtyps Authentifizierung zulässig. "

Siehe auch

Verweise

Allgemeines

Externe Links

  • Sicherheitslücke im WPA2-Protokoll, Loch196 [1] , [2]