Schluss mit löchrig Sichere Wireless LANs mit IEEE 802.11i

Ordnungsmerkmale

erschienen in: <kes> 2004#5, Seite 36

Rubrik: Systeme und ihr Umfeld

Schlagwort: WLAN-Sicherheit

Zusammenfassung: Ein neuer Standard soll endlich für Sicherheit in drahtlosen Netzen sorgen. Welche Neuigkeiten bringt der offizielle WEP- und WPA-Nachfolger IEEE 802.11i und welche Probleme gibt es bei der Migration?

Autor: Von Markus Nispel, Frankfurt

Die Sicherheit von Wireless LANs (WLANs) ist in den letzten Jahre in Verruf geraten – primär durch Sicherheitslücken des Wired Equivalent Privacy (WEP), den einfachen Schutz per SSID und die mangelnde Verbreitung selbst dieser schwachen Sicherheitsfunktionen (Stichwort: War Driving). Wer höhere Sicherheitsansprüche hat, ging dazu über sein WLAN per se als unsicheres Netz anzusehen und darin per VPN zu arbeiten, auch wenn dies erhöhte Kosten (Client-Software, VPN-Konzentratoren, Mehraufwand bei der Administration) und dennoch keine optimale Sicherheit bedeutete, da Layer-2-Angriffe weiterhin möglich sind.

Weil das offizielle neue Sicherheitsprotokoll des für WLAN-Standards zuständigen Institute of Electrical and Electronics Engineers (IEEE, http://standards.ieee.org/wireless/) auf sich warten ließ, hat die WiFi Alliance (www.wi-fi.org) im Sommer 2003 mit dem WiFi Protected Access (WPA) einen Interims-Nachfolger zu WEP veröffentlicht, der bisherige Sicherheitslücken schließen und doch mit der gleichen Hardware auskommen sollte – im Prinzip genügte hierfür ein Software-Update.

WPA war aber auch inhaltlich ein Vorgriff auf den im Juni verabschiedeten IEEE 802.11i (von der WiFi Alliance WPA2 genannt): In großen Teilen nutzen beide Standards identische Protokolle und Verfahren. 802.11i unterscheidet sich von WPA hauptsächlich durch einen geschützten Ad-Hoc-Modus (sicheres IBSS), Secure Fast Handoff und Pre-Authentication, sichere Abmeldung vom Netz (Secure De-Authentication and Disassociation) sowie erweiterte Verschlüsselungsprotokolle wie AES-CTR/CBC-MAC Protocol (CCMP).

Obwohl 802.11i "abwärtskompatibel" zu WPA ist und die meisten Funktionen per Firmware-Update nachrüstbar sind, wird das neue Verschlüsselungsprotokoll AES-CCMP nicht auf alter beziehungsweise nicht ausreichend leistungsfähiger WLAN-Hardware laufen. Die Wi-Fi Alliance hat Anfang September 2004 die ersten acht Zertifikate für WPA2-/802.11i-fähige Hardware veröffentlicht. Es dürfte nicht lange dauern bis weitere entsprechende Produkte und Firmware-Updates angeboten werden. Neuere WLAN Karten sind teilweise schon auf AES-CCMP vorbereitet und sollten problemlos per Software-Upgrade den neuen Standard umsetzen können.

  WEP WPA 802.11i / WPA2
Verschlüsselung RC4 RC4 AES
Schlüssellänge 40 Bit 128 Bit (Verschlüsselung)
64 Bit (Authentifizierung)
128 Bit
Initialization Vector (IV) 24 Bit 48 Bit 48 Bit
Datenintegrität CRC-32 Michael CCM
Header-Integrität keine Michael CCM
Replay-Schutz nicht vorhanden IV-Sequence IV-Sequence
Key Management nicht vorhanden EAPol-basiert EAPol-basiert

WEP, SPA und 802.11i im Vergleich

Sicherheitsarchitektur

802.11i enthält eine völlig neue Architektur, die maximale Sicherheit für WLANs gewährleisten soll. Die IEEE Task Group i (TGi) hat diese neue Sicherheitsarchitektur Robust Security Network (RSN) getauft. Neben der Verwendung einer sicheren Technik soll sie zudem einfach handhabbar sein. Aufgrund der Vorgabe, eine Weiterverwendung existierender Hardware zu ermöglichen, enthält 802.11i zwei verschiedene Basisprotokolle für die Verschlüsselung und Integritätssicherung: Einerseits das auf dem Advanced Encryption Standard (AES) basierende CCMP und zum anderen das Temporal Key Integrity Protocol (TKIP), das bereits mit WPA eingeführt wurde.

Zum Key-Management nutzen 802.11i und WPA das Extensible Authentication Protocol (EAP, vgl. <kes> 2002#5, S. 61). Allerdings eignen sich hierzu nicht alle EAP-Varianten: Empfehlen kann man nur EAP-TLS (Transport Layer Security), PEAP (Protected EAP) und EAP-TTLS (Tunneled TLS). Wie eine EAP-over-LAN-Authentifizierung (EAPoL) via 802.1x (Port based Network Access Control) im Prinzip abläuft zeigt Abbildung 1. EAP-TLS führt dabei eine Authentifizierung sowohl des Clients als auch des Servers (genauer gesagt: des Authentication/Radius-Servers) durch. Die EAP-üblichen Bezeichnungen sind dabei etwas "gewöhnungsbedürftig": Das Client-System heißt Supplicant – die Netzwerkkomponente, welche die Authentifizierung weiterleitet, ist der Authenticator – der Authentication Server ist schließlich dasjenige System, das die Authentifizierung durchführt.

[Illustration]
Abbildung 1: Schematischer Ablauf einer EAP-Authentifizierung

Nach dem EAPoL-Start stellt der Authenticator, in diesem Fall ein WLAN Access Point, einen Identity Request an den Supplicant; dieser antwortet mit seiner UserID. Der Authenticator leitet dies innerhalb eines Radius Access Requests an den Authentication-Server weiter. Danach erfolgt die eigentliche TLS-Authentifizierung: Der Server sendet sein Zertifikat an den Client und fordert von diesem ebenfalls ein Zertifikat. Nach der Prüfung des Server-Zertifikats übermittelt der Client sein eigenes Zertifikat an den Server, der wiederum eine Überprüfung durchführt. Zudem erfolgt die Aushandlung der sessionspezifischen Parameter. Nachfolgend wird der so genannte Pairwise Master Key (PMK, 256 Bit) auf beiden Seiten der EAPoL-Authentifizierung erzeugt und auf der Netzseite vom Authentifizierungsserver an den Access Point übermittelt. Der Groupwise Master Key (GMK, 128 Bit) wird direkt im Access Point erzeugt – genauso wie der Groupwise Transient Key (GTK, 256 bzw. 128 Bit), der dann über eine bestehende sichere Verbindung an die Supplicants verteilt wird.

Im Gegensatz zur WEP-Sicherheitsarchitektur kommen in der RSN-Sicherheitsarchitektur wie bei WPA somit viele verschiedene Schlüssel zum Einsatz, die alle Teil einer mehrstufigen Hierarchie sind. Einige dienen dem Zugriffsschutz auf eine Ressource (temporäre Keys), andere belegen zweifelsfrei die Identität ihres Inhabers (Master Keys). In der Hierarchie an zweiter Stelle steht der so genannte Pairwise Transient Key (PTK), der aus dem PMK erzeugt wird, mithilfe eines Pseudozufallsgenerators und gemeinsam von Supplicant und Authenticator: Während eines 4-Wege-Handshakes zwischen den Stationen erzeugen beide Pseudozufallszahlen und tauschen diese aus. Daraufhin berechnen beide Seiten einen identischen PTK. Dieser Schlüssel ist für die Verwendung von TKIP 512 Bit lang, für CCMP 384 Bit.

Der PTK wird zur Erzeugung der temporären Schlüssel anschließend in vier (TKIP) beziehungsweise drei (CCMP) 128-Bit-Teile aufgesplittet, die der Verschlüsselung und Integritätssicherung der EAPoL-Key-Messages (insgesamt zwei Teile) und damit der Absicherung der Schlüsselübertragung selbst dienen. Der jeweilige Rest des PTK wird für das eingesetzte Verschlüsselungsprotokoll zur Absicherung der Datenübertragung sowie für das Integritätsprotokoll verwendet: Bei TKIP benötigt man unterschiedliche Schlüssel für RC4 und das Message-Integrity-Code-(MIC)-Protokoll Michael, bei CCMP genügt ein Schlüssel (somit nur drei Teile des kürzeren PTK).

Über den GMK und den nachfolgenden GTK werden alle weiteren, temporären Schlüssel für TKIP oder CCMP zur Sicherung der Multicast-Kommunikation abgeleitet (Schlüssellänge jeweils 128 Bit).

Die sicherste Variante von 802.11i zur Verschlüsselung der Daten sowie zur Integritätsicherung ist CCMP: eine Kombination des CCM-Mode (Counter Mode Encryption) für die Verschlüsselung mit CBC-MAC (Cipher Block Chaining), das die Aufgabe der Berechnung eines MIC übernimmt (Integritätssicherung). Zu Beginn der Anwendung des CCM-Modes erfolgt die MIC-Berechnung. Im zweiten Schritt werden die Nachricht und der 64 Bit lange MIC mithilfe des Counter-Modes und AES verschlüsselt (vgl. Abb. 2).

[Illustration]
Abbildung 2: Schematischer Ablauf bei der kombinierten Verschlüsselung und Integritätssicherung CCMP

Migration zu 802.11i

Obwohl sehr starker Wert auf Kompatibilität gelegt wurde, erweist sich die Migration zu 802.11i in der Praxis als nicht so einfach – zumindest, wenn man auf CCMP setzen möchte. Zunächst einmal muss man identifizieren, welche Clients überhaupt 802.1x unterstützen. Das ist bei den gängigen Betriebssystemen sehr einfach, wird aber umso komplizierter, je mehr Exoten im WLAN unterwegs sind; PDAs, Scanner, Voice-over-IP-Telefone und sonstige Controller-Systeme haben hier massive Defizite. Ähnlich sieht es bei der Analyse der Verschlüsselungsfähigkeit der Client-Adapter aus: Nur die neueren Karten, die (grob geschätzt) 2004 erworben wurden, können AES-CCMP hardwareseitig unterstützen. Hier steht also gegebenenfalls ein entsprechendes Upgrade ins Haus.

Ein Mischbetrieb ist ebenfalls schwierig: WPA- und 802.11i-Clients assoziieren sich nicht mehr mit Access Points, auf denen auch unverschlüsselter Verkehr oder nur WEP zulässig ist. Nach welcher Methode sollte dann auch Multicast-Verkehr verschlüsselt sein: WEP, TKIP oder AES-CCMP? Daher wird man im Zweifel nicht an einer zweistufigen Lösung vorbeikommen: Eine "Funkzelle", in der man nur AES-CCMP nutzt, und eine, die einen schwächeren Schutz bietet. Die Funkzellen sollten dann natürlich auf der Netzseite auch entsprechend behandelt werden, was die Möglichkeiten der angeschlossenen Benutzer angeht.

Es gibt prinzipiell zwei Möglichkeiten, eine solche Struktur zu schaffen: einerseits die Nutzung von Dual-Band Access Points und zum anderen die Funktion SSID/VLAN-Mapping. Bei Dual-Band Access Points geht man davon aus, das beim Hardware-Upgrade der Client-Karten auf 802.11-a/b/g-Karten gesetzt wird, die AES-CCMP unterstützen und auch im 5-Ghz-Bereich arbeiten können. Die entsprechenden Access Points unterstützen dann gleichzeitig sowohl den 5-Ghz-Bereich mit 802.11a/h als auch den 2,4-Ghz-Bereich mit 802.11b/g. Die bestehenden Systeme mit dem niedrigeren Sicherheitslevel betreibt man dann im niederfrequenteren Band, oft wird man dort eine MAC-Authentifizierung mit WEP-128-Bit-Verschlüsselung finden. Der 5-Ghz-Bereich arbeitet hingegen mit mit AES-CCMP und 802.1x-Authentifizierung. Außerdem sollte man beide Segmente auf der Access-Point-Seite auf unterschiedliche VLANs verteilen, die wiederum unterschiedlichen Access-Lists beziehungsweise Firewall-Regeln unterliegen.

Die andere Möglichkeit ist die Nutzung von SSID/VLAN-Mapping-Funktionen. Hier führt die Verbreitung mehrerer SSIDs zu einem logischen Splitting der Funkzelle. Mit jeder SSID ist dann eine andere Kombination von Sicherheitsfunktionen assoziiert (Authentifizierung und Verschlüsselung), beispielsweise könnte die SSID "basic" WEP und MAC-Authensierung unterstützen, die SSID "advanced" nur AES-CCMP und 802.1x erlauben. Der Access Point leitet dann die Benutzer der einzelnen SSIDs in verschiedene VLANs.

Fazit

Sicherheit in drahtlosen Netzen ist wie die Sicherheit generell ein mehrstufiges Konzept – der Standard IEEE 802.11i bietet prinzipiell einen sehr guten Schutz, was das Medium WLAN selbst angeht. Es gibt jedoch einiges zu beachten, wenn man in Richtung 802.11i migrieren möchte. Zur Sicherheit gehört aber – wie immer – neben der reinen Technik und einem umfassenden Konzept auch das korrekte Verhalten der Nutzer und Administratoren: Ohne genügendes Sicherheitsbewusstsein dieser Gruppen wird aus der besten Sicherheitstechnik schnell wieder ein löchriger Käse, weil beispielsweise Viren und Würmer über Notebooks eingeschleppt oder dringend nötige Sicherheitsupdates verschleppt werden.

Empfehlenswert ist zudem die Einrichtung einer Intrusion-Detection/Prevention-Lösung, die direkt Access Switch beziehungsweise WLAN Access Point ansetzt und in der Lage ist, auch komplexe Angriffe auf Applikationsebene (wie z.B. über Microsoft RPC Remote Procedure Call) zu erkennen und voll- oder halbautomatisch, dauerhaft oder zeitlich begrenzt genau dort auf Attacken zu reagieren, wo sie ansetzen.

Dipl.-Ing. Markus Nispel ist Director of Technology bei Enterasys Networks Germany GmbH.