IEEE 802.11i Sicherheit in drahtlosen lokalen Netzen

Transcription

IEEE 802.11i
Sicherheit in drahtlosen lokalen Netzen
Fachgebiet Kryptographie und Computeralgebra – TU Darmstadt
Prof. Dr. Johannes Buchmann
Diplomarbeit von Axel Hagedorn
Betreut von Ulrike Meyer
November 2003
Zusammenfassung
Diese Diplomarbeit gibt einen umfassenden Einblick in Verbesserungen der Sicherheitsarchitektur von IEEE 802.11-WLANs. Diese liegen derzeit als Draft vor und
sollen in Kürze als 802.11i-Standard verabschiedet werden. Neben der Vorstellung des
darin definierten Robust Security Networks, das neue Lösungen für Verschlüsselung,
Integritätssicherung und Authentifizierung in WLANs bietet, werden auch die Probleme des bisherigen, auf Wired Equivalent Privacy basierenden Standards erörtert
und bereits existierende Weiterentwicklungen wie Wi-Fi Protected Access betrachtet.
Ehrenwörtliche Erklärung
Ich versichere, daß ich die vorliegende Diplomarbeit ohne Hilfe Dritter und nur mit den
angegebenen Quellen und Hilfsmitteln angefertigt habe. Alle Stellen, die aus den Quellen
entnommen wurden, sind als solche kenntlich gemacht. Diese Arbeit hat in gleicher oder
ähnlicher Form noch keiner Prüfungsbehörde vorgelegen.
Darmstadt, den 30. November 2003
I
Vorwort
Die vorliegende Arbeit dient der Vorbereitung eines Projektes zur Unterstützung des Interworkings von mobilen Geräten in UMTS-Netzen und WLANs. Das Projekt strebt die Verknüpfung von lokal hoher Bandbreite des Wireless-LANs mit der hohen Verfügbarkeit des
Universal Mobile Telecommunications Systems an. Den höchsten Grad an Interoperabilität
bieten automatische Handover-Prozeduren, die den transparenten Wechsel zwischen den
auf unterschiedlichen Technologien basierenden Netzen ermöglichen. Um Zugangskontrollmechanismen und Schlüsselmanagement auch während der Handover-Prozeduren einsetzen
zu können, müssen die Sicherheitsarchitekturen beider Netze interoperabel sein. Mit dem
IEEE 802.11i-Standard liegt nun auf der Seite des WLANs eine vielversprechende Basis
vor.
Der Schwerpunkt der Arbeit liegt deshalb auf der Analyse der neuen Verfahren im
802.11i-Standard für die Erreichung der wichtigsten Sicherheitsziele: Vertraulichkeit, Integrität und Authentizität. Dem erst durch diesen Standard eingeführten Schlüsselmanagement kommt im Hinblick auf die Verwaltung von Schlüsseln für die zu verbindenden Netztechnologien eine besondere Bedeutung zu.
Wichtigste Quelle für die Zusammenstellung der Informationen über die neue Sicherheit
für WLANs basierend auf dem IEEE 802.11-Standard ist der 802.11i-Standard selbst, der
mir Dank der freundlichen Unterstützung von David Johnston von der Intel Corporation
(selbst Mitarbeiter am 802.11i-Standard und jetzt Vorsitzender der IEEE 802 Handoff Executive Committee Study Group) als Draft in der Version 7.0 vom Oktober 2003 vorlag. Daneben konnte ich vor allem auf das im Juli 2003 erschienene Buch Real 802.11 Security von
Jon Edney und William A. Arbaugh (beides Experten im Bereich der WLAN-Sicherheit)
zurückgreifen, das auf einer früheren Draft-Version des Standards basiert. Dieser war allerdings auch schon weiter überarbeitet als die derzeit noch immer als einzige zu erwerbende
Version 3.0 vom November 2002.
Besonderer Dank gilt Ulrike Meyer für eine hervorragende Betreuung bei der Erstellung
dieser Arbeit, Professor Buchmann dafür, daß er sich trotz aller Verpflichtungen für jeden
seiner Studenten individuell engagiert, und meiner Frau Gerlind, die es mir durch ihre
intensive Unterstützung möglich gemacht hat, während der ersten Lebensmonate unseres
Sohnes Henry diese Arbeit anzufertigen.
II
Inhaltsverzeichnis
Abkürzungsverzeichnis
IX
Abbildungsverzeichnis
X
1 Einleitung
1
2 Grundlagen
2.1 Wireless-LAN . . . . . . . . . . . .
2.1.1 IEEE-Standards . . . . . . .
IEEE 802.11 . . . . . . . . .
IEEE 802.11a . . . . . . . .
IEEE 802.11b . . . . . . . .
IEEE 802.11d . . . . . . . .
IEEE 802.11g . . . . . . . .
IEEE 802.11h . . . . . . . .
IEEE 802.11i . . . . . . . .
IEEE 802.1x . . . . . . . . .
2.1.2 Architektur . . . . . . . . .
Ad-hoc-Modus . . . . . . .
Infrastrukturmodus . . . . .
2.2 Sicherheit . . . . . . . . . . . . . .
2.2.1 Schutzziele . . . . . . . . . .
Vertraulichkeit . . . . . . .
Integrität . . . . . . . . . .
Authentizität . . . . . . . .
Anonymität . . . . . . . . .
Verfügbarkeit . . . . . . . .
2.2.2 WLAN-Sicherheit . . . . . .
MAC-Adresse . . . . . . . .
SSID . . . . . . . . . . . . .
WEP-Sicherheitsarchitektur
Administration . . . . . . .
2.3 WEP-Sicherheitsarchitektur . . . .
2.3.1 Funktionsweise . . . . . . .
Verschlüsselung . . . . . . .
Entschlüsselung . . . . . . .
Integrität . . . . . . . . . .
Authentifizierung . . . . . .
2.3.2 Schwachstellen . . . . . . .
Administration . . . . . . .
Schlüssellänge . . . . . . . .
Initialisierungsvektor . . . .
Prüfsumme . . . . . . . . .
Chiffrealgorithmus . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
III
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
3
3
4
4
4
5
5
5
5
6
6
7
7
7
7
8
8
8
8
8
8
9
9
9
10
10
11
11
11
12
13
13
14
15
15
16
16
16
INHALTSVERZEICHNIS
Schlüsselmanagement . .
Authentifizierung . . . .
Schlüsselunabhängigkeit
Angriffswerkzeuge . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
17
17
17
17
3 Zwischenlösungen
3.1 VPN mit IPsec . . . . . . .
3.2 SSL und SSH . . . . . . . .
3.3 WPA-Sicherheitsarchitektur
3.3.1 Schlüsselmanagement
3.3.2 Verschlüsselung . . .
3.3.3 Integrität . . . . . .
3.3.4 Authentifizierung . .
3.4 Weitere Alternativen . . . .
3.4.1 WEPplus . . . . . .
3.4.2 FPK . . . . . . . . .
3.4.3 WEP2 . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
19
20
22
23
23
24
24
24
24
25
25
25
4 Neue Sicherheit
4.1 RSN-Sicherheitsarchitektur .
4.2 Schlüsselmanagement . . . .
4.2.1 Schlüsselarten . . . .
4.2.2 Schlüsselhierarchien .
PRNGs . . . . . . .
PRF . . . . . . . . .
4.2.3 Paarweise Schlüssel .
Pairwise Master Key
Temporäre Schlüssel
4.2.4 Gruppenschlüssel . .
Group Master Key .
Temporäre Schlüssel
4.2.5 Schlüsselwechsel . . .
4.2.6 Mischbetrieb . . . .
4.3 Verschlüsselung . . . . . . .
4.3.1 TKIP . . . . . . . .
Verschlüsselung . . .
Schlüsselmix / IV . .
MAC-Frame-Format
Entschlüsselung . . .
4.3.2 CCMP . . . . . . . .
Verschlüsselung . . .
AES . . . . . . . . .
MAC-Frame-Format
Entschlüsselung . . .
4.4 Integrität . . . . . . . . . .
4.4.1 TKIP MIC . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
27
27
29
30
30
31
31
32
34
36
38
40
40
41
41
42
42
43
45
50
52
54
55
57
62
62
64
64
IV
INHALTSVERZEICHNIS
4.5
Michael . . . . . . . . . . . .
Gegenmaßnahmen . . . . . .
4.4.2 CCMP MIC . . . . . . . . . .
CBC-MAC . . . . . . . . . .
Authentifizierung . . . . . . . . . . .
4.5.1 802.1x . . . . . . . . . . . . .
4.5.2 EAP . . . . . . . . . . . . . .
EAPOL . . . . . . . . . . . .
4.5.3 RADIUS . . . . . . . . . . . .
4.5.4 Upper-Layer-Authentifizierung
TLS . . . . . . . . . . . . . .
Kerberos . . . . . . . . . . . .
LEAP . . . . . . . . . . . . .
PEAP . . . . . . . . . . . . .
EAP-SIM . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
64
67
69
69
71
72
74
75
76
79
79
80
80
80
80
5 Ausblick
82
Literatur
84
V
Abkürzungsverzeichnis
AAD . . . . . . . . . . . .
AAI . . . . . . . . . . . . .
ACK . . . . . . . . . . . . .
AES . . . . . . . . . . . . .
AH . . . . . . . . . . . . . .
AP . . . . . . . . . . . . . .
ARIB . . . . . . . . . . . .
AS . . . . . . . . . . . . . . .
BRAN . . . . . . . . . . .
BSS . . . . . . . . . . . . .
BSSID . . . . . . . . . . .
C ................
CBC . . . . . . . . . . . . .
CBC-MAC . . . . . . .
CCK . . . . . . . . . . . . .
CCM . . . . . . . . . . . .
CCMP . . . . . . . . . . .
CHAP . . . . . . . . . . .
CRC . . . . . . . . . . . . .
CTR . . . . . . . . . . . . .
DA . . . . . . . . . . . . . .
DES . . . . . . . . . . . . .
DLL . . . . . . . . . . . . .
DoS . . . . . . . . . . . . .
DSSS . . . . . . . . . . . .
EAP . . . . . . . . . . . . .
EAPOL . . . . . . . . . .
ECB . . . . . . . . . . . . .
EIV . . . . . . . . . . . . . .
ESP . . . . . . . . . . . . .
ESS . . . . . . . . . . . . . .
ETSI . . . . . . . . . . . .
FCS . . . . . . . . . . . . .
FHSS . . . . . . . . . . . .
FIPS . . . . . . . . . . . .
FMS . . . . . . . . . . . . .
FPK . . . . . . . . . . . . .
FTP . . . . . . . . . . . . .
GMK . . . . . . . . . . . .
GSM . . . . . . . . . . . .
GTK . . . . . . . . . . . .
HIPERLAN . . . . .
HiSWANa . . . . . . .
HMAC . . . . . . . . . . .
Additional Authentication Data
Authentication Algorithm Identification
ACKnowledge
Advanced Encryption Standard
Authentication Header
Access Point
Association of Radio Industries and Businesses
Authentication Server
Broadband Radio Access Networks
Basic Service Set
Basic Service Set ID
Cyphertext
Cipher Block Chaining
Cipher Block Chaining – Message Authentication Code
Complementary Code Keying
CTR/CBC MAC
CTR/CBC-MAC Protocol
Challenge Handshake Authentication Protocol
Cyclic Redundancy Check
CounTeR
Destination Address
Data Encryption Standard
Data Link Layer
Denial of Service
Direct Sequence Spread Spectrum
Extensible Authentication Protocol
EAP Over LAN
Electronic CodeBook
Extended IV
Encapsulating Security Payload
Extended Service Set
European Telecommunication Standardisation Institution
Frame Check Sequence
Frequency Hopping Spread Spectrum
Federal Information Processing Standard
Fluhrer-Mantin-Shamir
Fast Packet Keying
File Transfer Protocol
Group Master Key
Global System for Mobile Communications
Group Transient Key
HIgh PErformance Radio Local Area Network
High-Speed Wireless Access Network Type a
Hashed Message Authentication Code
VI
ABKÜRZUNGSVERZEICHNIS
HP . . . . . . . . . . . . . .
HR/DSSS . . . . . . . .
HTTP . . . . . . . . . . .
HTTPS . . . . . . . . . .
IANA . . . . . . . . . . . .
IBSS . . . . . . . . . . . . .
ICV . . . . . . . . . . . . .
ID . . . . . . . . . . . . . . .
IEEE . . . . . . . . . . . .
IETF . . . . . . . . . . . .
IKE . . . . . . . . . . . . .
IMAP4 . . . . . . . . . .
IP . . . . . . . . . . . . . . .
IPsec . . . . . . . . . . . .
IPX . . . . . . . . . . . . . .
IR . . . . . . . . . . . . . . .
ISO . . . . . . . . . . . . . .
ISP . . . . . . . . . . . . . .
IV . . . . . . . . . . . . . . .
K ................
KID . . . . . . . . . . . . .
L2F . . . . . . . . . . . . . .
L2TP . . . . . . . . . . . .
LAN . . . . . . . . . . . . .
LDAP . . . . . . . . . . .
LEAP . . . . . . . . . . .
LLC . . . . . . . . . . . . .
M ................
MAC . . . . . . . . . . . .
MAC . . . . . . . . . . . .
MIC . . . . . . . . . . . . .
MMAC . . . . . . . . . .
MPDU . . . . . . . . . . .
MPPE . . . . . . . . . . .
MSDU . . . . . . . . . . .
NAK . . . . . . . . . . . .
NAS . . . . . . . . . . . . .
NIST . . . . . . . . . . . .
OCB . . . . . . . . . . . . .
OFDM . . . . . . . . . . .
OSI . . . . . . . . . . . . . .
PAP . . . . . . . . . . . . .
PBCC . . . . . . . . . . .
PBKDF . . . . . . . . .
PEAP . . . . . . . . . . .
HomePage
High-Rate Direct Sequence Spread Spectrum
HyperText Transfer Protocol
HTTP Secure
Internet Assigned Numbers Authority
Independent Basic Service Set
Integrity Check Value
IDentification
Institute of Electrical and Electronics Engineers
Internet Engineering Task Force
Internet Key Exchange
Internet Message Access Protocol 4
Internet Protocol
IP security
Internet Packet EXchange
InfraRed
International Organization for Standardization
Internet Service Provider
Initialization Vector
Key
Key-ID
Layer 2 Forwarding
Layer 2 Tunneling Protocol
Local Area Network
Lightweight Directory Access Protocol
Light EAP
Logical Link Control
Message
(Message Authentication Code) → MIC
Medium Access Control
Message Integrity Code
Multimedia Mobile Access Communication System
MAC Protocol Data Unit
Microsoft Point-to-Point Encryption
MAC Service Data Unit
Negative Acknowledge
Network Access Server
National Institute of Standards and Technology
Offset CodeBook
Orthogonal Frequency Division Multiplexing
Open Systems Interconnection
Password Authentication Protocol
Packet Binary Convolution Coding
Password Based Key Derivation Function
Protected EAP
VII
PHY . . . . . . . . . . . . .
PKCS . . . . . . . . . . .
PKI . . . . . . . . . . . . .
PMK . . . . . . . . . . . .
PN . . . . . . . . . . . . . .
POP3 . . . . . . . . . . . .
PPK . . . . . . . . . . . . .
PPP . . . . . . . . . . . . .
PPTP . . . . . . . . . . .
PRF . . . . . . . . . . . . .
PRG . . . . . . . . . . . . .
PRNG . . . . . . . . . . .
PSK . . . . . . . . . . . . .
PTK . . . . . . . . . . . . .
RADIUS . . . . . . . . .
RFC . . . . . . . . . . . . .
RSN . . . . . . . . . . . . .
S-Box . . . . . . . . . . . .
SA . . . . . . . . . . . . . . .
SFTP . . . . . . . . . . . .
SHA . . . . . . . . . . . . .
SIM . . . . . . . . . . . . .
SN . . . . . . . . . . . . . . .
SSH . . . . . . . . . . . . .
SSID . . . . . . . . . . . . .
SSL . . . . . . . . . . . . . .
SSN . . . . . . . . . . . . .
TA . . . . . . . . . . . . . .
TCP . . . . . . . . . . . . .
TGi . . . . . . . . . . . . . .
TK . . . . . . . . . . . . . .
TKIP . . . . . . . . . . . .
TLS . . . . . . . . . . . . .
TSC . . . . . . . . . . . . .
TSL . . . . . . . . . . . . .
TSL-U . . . . . . . . . . .
TSU . . . . . . . . . . . . .
TSU-U . . . . . . . . . . .
TTAK . . . . . . . . . . .
TTLS . . . . . . . . . . . .
ULA . . . . . . . . . . . . .
UMTS . . . . . . . . . . .
VPN . . . . . . . . . . . . .
VPNC . . . . . . . . . . .
WAN . . . . . . . . . . . .
PHYsical Layer
Public-Key Cryptography Standard
Public Key Infrastruktur
Pairwise Master Key
Packet Number
Post Office Protocol 3
Per-Packet Key
Point-to-Point Protocol
Point-to-Point Tunneling Protocol
Pseudo-Random Function
PRoGramm
Pseudo-Random Number Generator
PreShared Key
Pairwise Transient Key
Remote Authentication Dial In User Service
Request For Comments
Robust Security Network
Substitution-Box
Source Address
Secure FTP
Secure Hash Algorithm
Subscriber Identity Module
SequenzNummer
Secure SHell
Service Set IDentifier
Secure Socket Layer
Safe Secure Network
Transmitter Address
Transmission Control Protocol
Task Group i
Temporal Key
Temporal Key Integrity Protocol
Transport Layer Security
TKIP Sequence Counter
TKIP S-Box Lower
TSL-Upper
TKIP S-Box Upper
TSU-Upper
TKIP mixed Transmit Address and Key
Tunneled TLS
Upper-Layer Authentication
Universal Mobile Telecommunications Systems
Virtual Private Network
Virtual Private Network Consortium
Wide Area Network
VIII
WECA . . . . . . . . . .
WEP . . . . . . . . . . . .
Wi-Fi . . . . . . . . . . . .
WLAN . . . . . . . . . .
WPA . . . . . . . . . . . .
WPA2 . . . . . . . . . . .
WRAP . . . . . . . . . .
Wireless Ethernet Compatibility Alliance
Wired Equivalent Privacy
Wireless-Fidelity
Wireless LAN
Wi-Fi Protected Access
WPA v2
Wireless Robust Authenticated Protocol
IX
Abbildungsverzeichnis
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
IEEE 802.11-Standards im ISO-OSI-Modell . . . . . . .
WEP-Verschlüsselung . . . . . . . . . . . . . . . . . . . .
WEP-Integritätswahrung . . . . . . . . . . . . . . . . . .
WEP-Fehlerkorrektur . . . . . . . . . . . . . . . . . . . .
WEP-Authentifizierung . . . . . . . . . . . . . . . . . . .
Pseudozufallsfunktion (PRF) . . . . . . . . . . . . . . . .
TKIP Pairwise Key – Schlüsselhierarchie . . . . . . . . .
CCMP Pairwise Key – Schlüsselhierarchie . . . . . . . .
TKIP Group Key – Schlüsselhierarchie . . . . . . . . . .
CCMP Group Key – Schlüsselhierarchie . . . . . . . . .
TKIP-Verschlüsselung . . . . . . . . . . . . . . . . . . .
TKIP Schlüssel-Mix Phase 1 . . . . . . . . . . . . . . . .
TKIP Schlüssel-Mix Phase 2 . . . . . . . . . . . . . . . .
TKIP TSU-U S-Box . . . . . . . . . . . . . . . . . . . .
TKIP TSL-U S-Box . . . . . . . . . . . . . . . . . . . . .
TKIP MAC-Frame (MPDU) . . . . . . . . . . . . . . . .
TKIP-Entschlüsselung . . . . . . . . . . . . . . . . . . .
CCMP-Nonce . . . . . . . . . . . . . . . . . . . . . . . .
CCMP-Header . . . . . . . . . . . . . . . . . . . . . . .
CCMP-Verschlüsselung . . . . . . . . . . . . . . . . . . .
ECB-Mode . . . . . . . . . . . . . . . . . . . . . . . . .
CTR-Mode . . . . . . . . . . . . . . . . . . . . . . . . .
Konstruktion des Zählers für den CCMP-Counter-Mode .
CCMP MAC-Frame (MPDU) . . . . . . . . . . . . . . .
CCMP-Entschlüsselung . . . . . . . . . . . . . . . . . . .
Berechnung des TKIP MIC (Michael) . . . . . . . . . . .
Michael-Algorithmus . . . . . . . . . . . . . . . . . . . .
Michael-Blockchiffre . . . . . . . . . . . . . . . . . . . .
CBC-MAC . . . . . . . . . . . . . . . . . . . . . . . . . .
Berechnung des CCMP MIC (CBC-MAC) . . . . . . . .
Erster Block zur Berechnung des CCMP MIC . . . . . .
802.1x-Rollen . . . . . . . . . . . . . . . . . . . . . . . .
Authentifizierungsverlauf (EAP/EAPOL/RADIUS) . . .
X
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
6
12
13
13
14
32
33
34
39
39
44
46
48
49
50
51
53
56
56
57
58
59
61
62
63
65
66
67
69
70
71
72
78
1
Einleitung
Bereits seit mehreren Jahren existiert zum herkömmlichen, kabelbasierten LAN (Local Area
Network) eine drahtlose Alternative: WLAN (Wireless Local Area Network, bzw. WirelessLAN). Führte diese Technologie noch vor dem Jahrtausendwechsel eher ein Nischendasein,
so hat sie sich mittlerweile etabliert und wird mehr und mehr zu einem Konkurrenten des
kabelbasierten LANs. Damit sind WLANs nicht mehr nur die Domäne von Universitäten
und besonders interessierten Nutzergruppen, sondern finden auch in Firmen, die die Vorteile drahtloser Kommunikation, insbesondere die Kostenersparnis bei der Einrichtung neuer
Netze, in ihren Netzwerken nutzen wollen, immer mehr Anhänger. Drahtlose Netze besitzen
nach Meinung mancher Anbieter von WLAN-Technik sogar das Potential, herkömmliche
Netze in der Geschäftswelt langfristig abzulösen; vgl. Red-M (HP). Bereits jetzt finden
Geschäftsreisende an Flughäfen gut ausgebaute Möglichkeiten zur drahtlosen Kommunikation (via Internet) mit ihrem Firmennetzwerk vor. Aber auch der Privatanwender wird
langfristig in der WLAN-Technik eine Alternative für seinen Internetzugang geboten bekommen und damit eine Fülle von neuen Nutzungsmöglichkeiten. Schon jetzt gibt es hierzu
beispielsweise in Athens, Georgia (USA) ein von der ansässigen Universität und Studenten
eingerichtetes stadtübergreifendes WLAN, die sogenannte WAGz (Wireless Athens Georgia Zone), die es nicht nur Studenten ermöglicht, von fast jedem Ort in der Innenstadt per
Funk Zugriff auf das Internet zu erlangen; vgl. New Media Institute, University of Georgia
(HP).
Ob dieser Entwicklung eher mit Hoffnung oder mit Sorge zu begegnen ist, hängt davon
ab, inwieweit die Technologie in der Lage ist bzw. sein wird, sicherheitskritischen Anwendungen auch die nötige Sicherheit bieten zu können. Der aktuelle Erfolg des WLANs darf
nicht darüber hinwegtäuschen, daß auf der Basis aktueller Standards keine wirkliche Sicherheit in WLANs geboten wird: Die Sicherheitsarchitektur des dem WLAN zugrundeliegenden
802.11-Standards des IEEE (Institute of Electrical and Electronics Engineers) (vgl. IEEE
(1999a)) wurde mittlerweile zu einer reinen Fassade degradiert, da elementare Bestandteile
– speziell die WEP (Wired Equivalent Privacy)-Sicherheitsarchitektur – gravierende Lücken
enthalten; vgl. Edney und Arbaugh (2003, S. 89 – 101).
Auf diese Problematik kann unterschiedlich reagiert werden: Zum einen gibt es Firmen, in denen die Verwendung von WLAN aufgrund dieser Sicherheitsmängel schlicht untersagt wird. Zum anderen gibt es aber auch mehrere Bestrebungen, dem WLAN durch
zusätzliche Technologien die nötige Sicherheit zu verschaffen: Von der Wireless-Fidelity
(Wi-Fi) Alliance, einem Zusammenschluß von Herstellern aus dem Bereich der Funknetze
(vgl. Wi-Fi Alliance (HP)), wurde mangels Verfügbarkeit eines verbesserten Standards der
IEEE (HP) deshalb in der Zwischenzeit aus Teilen des Drafts des 802.11i-Standards die
Wi-Fi Protected Access (WPA)-Architektur zur Marktreife entwickelt, die derzeit eine Interimslösung bis zur Verabschiedung des 802.11i-Standards darstellt. Darüber hinaus gibt
es mittlerweile Lösungen, die die WLAN-Technologie mit Virtual Private Networks (VPN)
verknüpfen und damit eine sichere Verschlüsselung der Nutzdaten gewährleisten und eine
vom WLAN unabhängige Authentifizierung einführen; vgl. BSI (2002, S. 11).
Um einen Wildwuchs bei proprietären Lösungen zur Kompensation der Sicherheitsprobleme des ursprünglichen Standards zu verhindern, ist die IEEE mittlerweile unter
Zeitdruck, einen erweiterten Standard zu verabschieden, der eine Basis für die WLANInfrastruktur der kommenden Generation schafft und damit eine möglichst weitreichende
1
1. EINLEITUNG
Interoperabilität sichert. Damit der Umstieg zu einer neuen Technologie möglichst reibungslos durchzuführen ist, enthalten die Bestrebungen der IEEE neben den neuen Sicherheitsmechanismen auch die der bereits erwähnten WPA-Sicherheitsarchitektur zugrundeliegenden
Verfahren, die eine Abwärtskompatibilität zu bestehenden Systemen ermöglichen. Langfristig wird ein Austausch der WLAN-Hardware durch eine neue Generation von Geräten
angestrebt, die dann die neuen Protokolle der durch den IEEE 802.11i-Standard beschriebenen Robust Security Network (RSN)-Sicherheitsarchitektur umsetzen.
Die vorliegende Arbeit untersucht die Entwicklung von drahtlosen lokalen Netzwerken
im Hinblick auf ihre Sicherheit bis zu ihrem aktuellen technologischen Stand und beschreibt
darauf aufbauend die im aktuellen Draft des IEEE 802.11i-Standards vorgeschlagenen Erweiterungen; vgl. IEEE (2003b). In Kapitel 2 werden zunächst die grundlegenden Eigenschaften von WLANs beschrieben und die Sicherheitsprobleme des ursprünglichen Standards 802.11 (vgl. IEEE (1997)) dargestellt. Kapitel 3 befaßt sich mit den Maßnahmen,
die bisher ergriffen wurden, um den Sicherheitsproblemen zu begegnen und mit den Verfahren, die aktuell neben der noch immer eingesetzten WEP-Sicherheitsarchitektur genutzt
werden. Der 802.11i-Standard, basierend auf dem Draft in der Version 7.0 vom Oktober
2003, ist Thema des vierten Kapitels. Dort werden die in der RSN-Sicherheitsarchitektur
gebündelten Maßnahmen zur Verbesserung der Sicherheit in WLANs eingehend vorgestellt
und untersucht, wie diese die Sicherheitsziele Vertraulichkeit, Integrität und Authentizität erreichen und damit fähig sind, bestehende Sicherheitslücken zu schließen. Ein erst im
802.11i-Standard eingeführtes Schlüsselmanagement fügt sich dabei den drei Hauptzielen
an.
Da der Standard noch nicht verabschiedet ist, können diese Informationen derzeit nur
unter Vorbehalt wiedergegeben werden, zumal auch weiterhin noch Änderungen in den
Draft einfließen können. Grundsätzliche Änderungen an den Vorgaben des Standards sind
aber nicht mehr zu erwarten.
Einen Ausblick auf die kommende Entwicklung und die Chancen des IEEE 802.11iStandards gibt abschließend das Kapitel 5.
2
2
Grundlagen
Die derzeit vorrangig eingesetzte Wireless-LAN-Technologie basiert noch immer grundlegend auf dem IEEE-Standard 802.11 aus dem Jahre 1997 (vgl. IEEE (1997)), der trotz
einiger Erweiterungen völlig unzureichende Sicherheitsmechanismen aufweist. Die folgenden Abschnitte geben darum – neben einem kurzen Überblick über die Entwicklung
und den prinzipiellen Aufbau von WLANs – Auskunft über die zugrundeliegenden Standards und deren Sicherheitsaspekte. Insbesondere wird hierbei die Funktion der WEPSicherheitsarchitektur als zentraler Bestandteil des ersten WLAN-Standards betrachtet und
deren Schwachstellen analysiert.
2.1
Wireless-LAN
Wireless-LAN stellt eine vergleichsweise junge drahtlose Variante lokaler Netze dar. Funkverbindungen zwischen Computern existieren zwar schon seit Beginn der 90er Jahre, jedoch
handelte es sich dabei anfangs um parallel entwickelte, proprietäre Produkte. Mangels einer gemeinsamen technischen Grundvereinbarung war dieser Technik über längere Zeit
kein großer Erfolg beschieden. Erst als 1997 vom IEEE mit 802.11 ein grundlegender Standard für WLANs im 2,4-GHz-Band verabschiedet wurde (vgl. IEEE (1997)), besserte sich
die Situation und drahtlose Netze wurden wesentlich populärer. Produkte, die auf dieser
Spezifikation des amerikanischen Standardisierungsinstituts bzw. der Erweiterung 802.11b
basieren (vgl. IEEE (1999c) und IEEE (2001a)), bilden heute den mit Abstand größten Anteil des weltweiten WLAN-Marktes. (Eine Beschreibung der einzelnen WLAN-Standards
des IEEE folgt in Kapitel 2.1.1.)
Dabei ist das IEEE nicht das einzige Institut, das an einer Vereinheitlichung der mobilen Datenübertragung arbeitet. So wurden beispielweise von der European Telecommunication Standardisation Institution (ETSI) in ihrem BRAN (Broadband Radio Access
Networks)-Projekt die Funk-LAN-Standards HIPERLAN (High Performance Radio Local
Area Network) Typ 1 (2,4 GHz) und Typ 2 (5 GHz) entwickelt. (Nähere Informationen
zu HIPERLAN/1 und HIPERLAN/2 finden sich bei ETSI (HP) unter ETSI BRAN Project (1998) und ETSI BRAN Project (2000).) Und auch die japanische Multimedia Mobile
Access Communication System (MMAC)-Promotions Council Group publiziert Spezifikationen für neue mobile Systeme wie z.B. das von der Association of Radio Industries and
Businesses (ARIB) standardisierte HiSWANa (High-Speed Wireless Access Network Type
a), welches kompatibel zu HIPERLAN/2 ist; vgl. MMAC (HP). Informationen zu den
genannten und noch weiteren alternativen Netzstandards und den jeweiligen Organisationen finden sich unter anderem in Intersil (2003). Ihre Bedeutung für den internationalen
WLAN-Markt dürfte jedoch als relativ gering angesehen werden.
In Europa und Japan greifen zwar jeweils andere Bestimmungen im Bezug auf verwendbare Frequenzen und Sendeleistungen als in Amerika, wodurch die lokal entwickelten
Standards eigentlich Wettbewerbsvorteile haben sollten, doch in den beiden genannten Fällen wurden bzw. werden vom IEEE im Rahmen der 802.11-Serie bereits Erweiterungen des
Standards entwickelt, die den jeweiligen lokalen Bestimmungen der Regionen Rechnung
tragen sollen. Damit werden sowohl den europäischen als auch den japanischen Bestrebungen langfristig nur geringe Marktchancen zugeschrieben. Angesichts dieser Marktüberlegenheit der auf den IEEE-Standards basierenden Produkte sind die Sicherheitsprobleme dieser
3
2.1 WIRELESS-LAN
Standards um so schwerwiegender. Sie bedürfen deshalb einer dringenden Überarbeitung,
die endlich mit dem 802.11i-Standard auch von Seiten des IEEE vorangetrieben wird.
2.1.1
IEEE-Standards
Die IEEE 802-Standards enthalten Spezifikationen für verschiedene LAN-Technologien, wovon der 802.11-Zweig Wireless-LAN beschreibt. Dieser besteht korrespondierend zum ISOOSI (Open Systems Interconnection)-Referenzmodell (vgl. Tanenbaum (1996, S. 28 – 35)
und ISO (HP)) aus Definitionen der Schicht 1 und teilweise der Schicht 2. Während in
der physischen Schicht (Schicht 1, Physical Layer (PHY)) die mechanischen, elektrischen,
funktionalen und prozeduralen Eigenschaften festgelegt werden, die es ermöglichen, physische Verbindungen im WLAN aufzubauen, aufrechtzuerhalten und abzubauen, umfaßt
die Verbindungs- bzw. Sicherungsschicht (Schicht 2, Data Link Layer (DLL)), die Medienzugangskontrolle (Medium Access Control (MAC)), die den Zugang zum WLAN-Medium
koordiniert, und die Flußkontrolle (Logical Link Control (LLC)), die für die Erkennung
und Behebung von Übertragungsfehlern zuständig ist. Letztere ist jedoch nicht mehr Teil
vom 802.11-Standard sondern wird durch den 802.2-Standard allgemein für alle darunter
liegenden Schichten definiert; vgl. IEEE (1998).
Im folgenden werden die für das weitere Vorgehen relevanten Standards der 802.11Serie kurz beschrieben. Eine vollständige Auflistung ist z.B. bei Keene (2003) zu finden.
Abbildung 1 zeigt anschließend die Einordnung der IEEE 802.11-Familie von Standards in
das ISO-OSI-Modell.
IEEE 802.11 Dies ist der erste und grundlegende Standard für Wireless-LAN und wurde 1997 von der IEEE verabschiedet. 1999 wurde er noch einmal überarbeitet; vgl. IEEE
(1999a). Diese Überarbeitung hat die erste Version IEEE (1997) vollständig abgelöst und
ist einzig aktuell gültiger Text. Er spezifiziert drei verschiedene drahtlose Techniken auf der
physischen Schicht (PHY): Zum einen zwei funkbasierende für den Betrieb im Frequenzspektrum von 2,4 – 2,5 GHz: Frequency Hopping Spread Spectrum (FHSS) und Direct
Sequence Spread Spectrum (DSSS), zum anderen eine auf Infrarot (IR) basierende. Mit
ihnen sind Datenübertragungsraten von 1 oder 2 Mbps möglich.
Der 802.11-Standard legt die beiden Betriebsmodi Ad-hoc- und Infrastrukturmodus
für WLAN-Geräte fest, die in Abschnitt 2.1.2 genauer beschrieben werden. Darüber
hinaus wird die MAC-Schicht für den Zugang zu drahtlosen Netzen grundlegend definiert und eine Sicherheitsarchitektur entworfen, die unter anderem mittels der WEPSicherheitsarchitektur für die sichere Authentifizierung und Datensicherheit im WLAN
sorgen soll. Die einzelnen Sicherheitsmechanismen und deren Schwachstellen werden in den
Abschnitten 2.2.2 und 2.3 näher erläutert.
IEEE 802.11a Der 1999 fertiggestellte Standard beschreibt die physische Schicht für den
5-GHz-Frequenzbereich. Er spezifiziert das Orthogonal Frequency Division Multiplexing
(OFDM) für Übertragungsgeschwindigkeiten bis zu 54 Mbps; vgl. IEEE (1999b). Der Standard ist allerdings nur auf die gesetzlichen Bestimmungen der USA abgestimmt und wurde
deshalb erst im November 2002 in Deutschland – und das auch nur mit verminderter Sendeleistung – zugelassen, was den Aktionsradius auf unzureichende 10 bis 15 Meter beschränkt;
vgl. Ahlers (2002).
4
2.1 WIRELESS-LAN
IEEE 802.11b Die Übertragungsgeschwindigkeit für das 2,4-GHz-Frequenzband wird
mit diesem Standard auf 11 Mbps erhöht. Der 802.11b-Standard spezifiziert dafür das
High-Rate Direct Sequence Spread Spectrum (HR/DSSS) unter Verwendung des Complementary Code Keying (CCK) als neue und einzige Technik auf der physischen Schicht. Es
wird dabei nur die Abwärtskompatibilität zum DSSS gewahrt. IR und FHSS werden nicht
mehr unterstützt; vgl. IEEE (1999c). Der 1999 verabschiedete Standard (inklusive der 2001
veröffentlichten Korrektur IEEE (2001a)) bildet derzeit die Grundlage der meisten erhältlichen WLAN-Produkte. Der Erfolg der auf dem 802.11b-Standard basierenden Produkte
wurde dabei nicht unwesentlich von der ebenfalls 1999 gegründeten Wi-Fi Alliance (damals
noch Wireless Ethernet Compatibility Alliance (WECA)) gestützt, die Produkte auf ihre
Kompatibilität zum 802.11b-Standard untersucht und das Wi-Fi-Logo verleiht.
IEEE 802.11d Mit diesem Standard wird die MAC-Schicht des 802.11-Standards um
Regulierungen ergänzt, die es ermöglichen sollen, WLAN-Geräte weltweit einzusetzen, das
heißt entsprechend der in den jeweiligen Ländern geltenden Gesetze und Einschränkungen
– z.B. im Bezug auf die erlaubte Sendestärke. Er beschreibt Mechanismen, die es Geräten erlauben, Änderungen an den Sendeparametern vorzunehmen, und beinhaltet darüber
hinaus sogar die Möglichkeit eines Roamings zwischen verschiedenen Regulierungsgebieten;
vgl. IEEE (2001b).
IEEE 802.11g Durch diesen Standard, der erst im Juni dieses Jahres verabschiedet wurde, wird die Übertragungsgeschwindigkeit für das 2,4-GHz-Frequenzband erneut verbessert
und auf 54 Mbps erhöht. Dies wird durch die Einführung der vom 802.11a-Standard bekannten OFDM-Technik erreicht. Neben dem OFDM ist auch das CCK vorgesehen, um
eine Abwärtskompatibilität für Geräte, die auf dem 802.11b Standard basieren, zu garantieren. Als optionale PHY-Komponente sieht der Standard das Packet Binary Convolution
Coding (PBCC) vor, das einer proprietären Entwicklung für 22-MBit-WLANs entstammt
(vgl. Ahlers (2002)), und darüber hinaus die Kombination CCK/OFDM, was einer CCKKodierung des Headers bei einer OFDM-Kodierung des Frame Bodys entspricht; vgl. IEEE
(2003a). Es ist zu erwarten, daß der 802.11g-Standard eine ebenso große Verbreitung wie
der 802.11b-Standard findet, bietet er doch eine Möglichkeit, unter Beibehaltung einer bestehenden 802.11b-Infrastruktur schrittweise auf die höhere Geschwindigkeit umzustellen.
IEEE 802.11h Im 802.11h-Standard werden Anpassungen der MAC-Schicht von WLANs
im 5-GHz-Frequenzbereich, wie sie im 802.11a-Standard festgelegt wurde, vorgenommen,
um den europäischen Funkvorschriften Rechnung zu tragen, die bisher eine Zulassung
des 802.11a-Standards verhindert hatten; vgl. IEEE (2002a). (Aufgrund dessen konnte
sich HIPERLAN/2 in 5-GHz-Domäne zwischenzeitlich durchsetzen.) Der IEEE 802.11hStandard steht kurz vor seiner Verabschiedung, kommt aber sehr wahrscheinlich dennoch
zu spät, um sich als vorherrschender Standard bei 54-Mbps-Netzen durchzusetzen. Er wird
nach seiner Zulassung sicher zu einer stärkeren Verbreitung von 5-GHz-WLANS in Europa führen, doch gegenüber der 2,4-GHz-Technik, die mit dem 802.11g-Standard auch bei
54 Mbps angekommen ist, in seiner Verbreitung zurückbleiben. Denkbar wären allerdings
auch Kombigeräte, die aufgrund der gemeinsamen PHY-Schicht beide Frequenzbereiche
bedienen können.
5
2.1 WIRELESS-LAN
IEEE 802.11i Der 802.11i-Standard liegt derzeit auch noch als Draft vor. Offiziell verfügbar ist nur die Version 3.0 des Drafts vom November 2002 (vgl. IEEE (2002b)), intern
befindet sich der Standard aber bereits näher an seiner Fertigstellung in der Version 7.0
vom Oktober 2003; vgl. IEEE (2003b). Mit diesem Standard wird eine erweiterte Sicherheitsarchitektur für den 802.11-Standard vorgestellt, die den Namen RSN (Robust Security
Network) trägt. Er wird gültig sein für die Standards 802.11a, 802.11b und 802.11g und bietet vor allem eine Alternative zur WEP-Sicherheitsarchitektur mit einem Schlüsselmanagement, neuen Authentifizierungsverfahren und Verschlüsselungsmethoden. Dabei stützt sich
der 802.11i-Standard unter anderem auch auf den 802.1x-Standard und die darin enthaltenen Protokolle; dazu siehe unten. Daneben gehören zu den neuen Verfahren des Standards
z.B. das Temporal Key Integrity Protocol (TKIP) oder der Verschlüsselungsalgorithmus
AES (Advanced Encryption Standard). Eingehend behandelt wird der 802.11i-Standard in
Kapitel 4.
IEEE 802.1x Dieser Standard gehört nicht direkt zur 802.11-Serie, kommt hier aber
auch zum Tragen, da er allgemein für die 802-Familie gilt. Er wurde 2001 verabschiedet
und beschreibt eine Möglichkeit zu einer portbasierenden Authentifizierung und Autorisierung von LAN-Geräten und Benutzern an Punkt-zu-Punkt-Verbindungen und zur Sicherung der Ports vor unbefugten Zugriffen; vgl. IEEE (2001c). Dies geschieht in der Regel
über RADIUS (Remote Authentication Dial In User Service) im Zusammenspiel mit dem
Extensible Authentication Protocol (EAP). Detaillierter geht Abschnitt 4.5.1 auf diesen
Standard ein.
Höhere
Schichten
(ISO 3 – 7)
”Upper-Layer”-Protokolle
LLC
802.2
DLL
802.1(x) – ”Bridging”
802.11
MAC
802.11d
802.11
PHY
802.11a
802.11h
802.11i
802.11b
802.11g
MAC
PHY
Abbildung 1: IEEE 802.11-Standards im ISO-OSI-Modell
6
SicherungsSchicht
(ISO 2)
(2a / 2b)
Physische
Schicht
(ISO 1)
2.2 SICHERHEIT
2.1.2
Architektur
Entsprechend den IEEE-Standards spezifizierte WLANs können sowohl als Peer-to-PeerNetze – im sog. Ad-hoc-Modus – als auch in Form von vollwertigen Netzwerken – im sog.
Infrastrukturmodus – betrieben werden, wobei in den meisten Fällen der Infrastrukturmodus eingesetzt wird, zumal von der Verwendung des Ad-hoc-Modus aus Sicherheitsgründen ohnehin abzuraten ist. In den folgenden beiden Abschnitten werden die Eigenschaften
beider Betriebsmodi kurz beschrieben; vgl. dazu auch BSI (2002, S. 2 + 3) und Schulte
(1999).
Ad-hoc-Modus Im Ad-hoc-Modus findet die Kommunikation zwischen verschiedenen
Rechnern auf direktem Weg statt. Ein Peer-to-Peer-Netz kann dabei zwei oder mehrere
Rechner umfassen, die jeweils mit einem WLAN-Adapter ausgestattet sind. Teilnehmende
Adapter müssen hierbei auf denselben Kanal eingestellt sein und können bei entsprechender räumlicher Nähe direkt mit anderen Rechnern Daten austauschen. Solch ein begrenzter
Bereich wird allgemein Basic Service Set (BSS) bzw. im Fall des Ad-hoc-Netzes auch Independent BSS (IBSS) genannt. Bei der Verwendung unterschiedlicher Kanäle können auch
mehrere Ad-hoc-Netze am gleichen Ort betrieben werden, die dann aber nicht untereinander
kommunizieren können. Ad-hoc-Netzwerke stellen die preiswerteste Variante eines WLANs
dar, da außer den WLAN-Adaptern keine weiteren Geräte benötigt werden. Allerdings sind
sie meist auch die unsichersten, da in diesem Betriebsmodus oft keine Sicherheitsmechanismen zur Anwendung kommen. Ein Angreifer kann dann allein durch die Einstellung des
richtigen Kanals Zugriff zum Ad-hoc-Netzwerk erlangen.
Infrastrukturmodus Im Infrastrukturmodus kommt eine zentrale Funkbrücke in einem
BSS zum Einsatz, ein sogenannter Access Point (AP), über den Clients miteinander kommunizieren. Der AP versorgt abhängig von der Umgebung eine Funkzelle in der Größe von
30 bis 150 Metern, aber durch den Einsatz mehrerer APs – mit sich überlappenden Funkzellen – kann mittels Roamings auch ein wesentlich größeres Gebiet abgedeckt werden. In
diesem Fall wird dann von einem Extended Service Set (ESS) gesprochen. Ein AP kann
darüber hinaus als Schnittstelle zu einem kabelbasierten LAN dienen oder als Repeater
zur Erweiterung der Reichweite eines Netzes. Bei Verwendung von zwei APs ist auch die
Funktion als Brücke zwischen zwei kabelbasierten LANs möglich, wobei ihre Reichweite
durch den Einsatz von Richtantennen noch erhöht werden kann. Im Gegensatz zum Adhoc-Modus werden im Infrastrukturmodus die Sicherheitsmechanismen für das Netz vom
AP determiniert, da alle Clients nur über diesen in das Netz gelangen. Dieser Modus ist
damit prinzipiell sicherer, zumindest aber leichter zu kontrollieren. (Zu Schwachstellen der
WEP-Sicherheitsarchitektur siehe Kapitel 2.3.)
2.2
Sicherheit
Bevor die durch den aktuellen Standard implementierten Maßnahmen zur Sicherung des
Datenverkehrs betrachtet werden, ist zu klären, was im Bezug auf Sicherheit denn überhaupt erreicht werden soll. Im folgenden wird darum erst erläutert, welche Schutzziele
allgemein und im Rahmen der Absicherung von Netzen zu erfüllen sind, bevor die mit dem
802.11-Standard verbundenen Sicherheitsmechanismen beschrieben werden.
7
2.2 SICHERHEIT
2.2.1
Schutzziele
Im Netzwerkbereich ebenso wie in der Kryptographie allgemein gilt es, bestimmte Schutzziele zu erreichen. Die wichtigsten Ziele lauten: Vertraulichkeit, Integrität, Authentizität,
Anonymität und Verfügbarkeit. Natürlich lassen sich je nach Anwendung unterschiedliche
Gewichtungen dieser Schutzziele festlegen oder vielleicht auch noch weitere finden. Für den
Bereich der Netzwerksicherheit und des Anwendungsportfolios von WLANs sollen die aufgeführten jedoch genügen. Was unter den Zielen im einzelnen zu verstehen ist, wird im
folgenden beschrieben.
Vertraulichkeit Das wohl naheliegendste Schutzziel im Kontext von Datenschutz ist die
Vertraulichkeit. Vertraulichkeit beinhaltet die Geheimhaltung von Informationen vor allen
nicht zum Zugriff berechtigten Personen und wird durch Verschlüsselung mittels kryptographischer Verfahren erreicht. Für das WLAN bedeutet dies, daß sowohl Nutzdaten als auch
Daten, die zur Herstellung und Aufrechterhaltung einer Verbindung nötig sind, nicht von
Dritten entschlüsselt werden können – selbst wenn ihnen das Abfangen der entsprechenden
Datenpakete gelingt.
Integrität Mit der Integrität wird die Authentizität von Daten gefordert. Für das WLAN
bedeutet dies wiederum, daß der Empfänger hierbei sicher sein kann, daß er genau die Daten des Senders erhalten hat, die dieser auch gesendet hat. Für den Fall, daß Informationen
manipuliert worden sind, muß der Empfänger dies zuverlässig erkennen können. Der Integritätssicherung ähnlich ist der Schutz gegen zufällige Übertragungsfehler beim Übermitteln
der Nachricht. Dieser kann Bitfehler entdecken, aber im allgemeinen nicht die Authentizität
von Daten garantieren.
Authentizität Die Authentizität von Kommunikationspartnern muß vor der Bereitstellung von Daten oder Diensten sichergestellt werden, um eine Zugangskontrolle zu ermöglichen. Authentizität ist damit eng mit der Integrität verbunden: Es muß nicht nur sichergestellt sein, daß übertragene Daten unverändert den Empfänger erreichen, sondern auch,
daß die Herkunft und das Ziel dieser Daten zweifelsfrei bekannt ist. Dies ist unter anderem
auch eine Voraussetzung für Verbindlichkeit.
Anonymität Wenn nicht nur die übermittelten Informationen vor Dritten verborgen
bleiben sollen, sondern auch die Identität der miteinander kommunizierenden Dienstanbieter bzw. Dienstnutzer, so wird Anonymität gefordert. In diesem Fall müssen auch die
Verkehrsdaten einer Verbindung verschlüsselt werden. Anonymität kann in anderen Anwendungsfällen aber auch bedeuten, daß die Kommunikationspartner untereinander anonym
bleiben möchten. Anonymität würde damit aber im Widerspruch zum Schutzziel Authentizität stehen und ist darum im Kontext von WLANs nicht anwendbar.
Verfügbarkeit Verfügbarkeit bedeutet, daß ein Dienst immer dann zur Verfügung steht,
wenn ein berechtigter Nutzer diesen Dienst in Anspruch nehmen möchte. Sie kann unter
anderem durch Überlastung oder Sabotage beeinträchtigt werden. Ziel ist es, Störungen bei
der Dienstbereitstellung auszuschließen bzw. zumindest soweit wie möglich einzugrenzen.
8
2.2 SICHERHEIT
Im Fall einer Störung sollte diese sicher erkannt werden und Maßnahmen eingeleitet werden,
die die Verfügbarkeit wiederherstellen können.
2.2.2
WLAN-Sicherheit
Der IEEE 802.11-Standard enthält grundlegende Sicherheitsmechanismen im Bezug auf die
Kommunikation in den im Standard spezifizierten drahtlosen Netzen und den Zugriff darauf. Es ist aber zu ermitteln, inwieweit diese Mechanismen tatsächlich die eben geschilderten Schutzziele berücksichtigen. Unter dieser Fragestellung werden im folgenden die durch
den 802.11-Standard implizierten Sicherheitskonzepte vorgestellt, wobei nicht nur die Sicherheitselemente des Standards selbst, sondern auch generelle Sicherheitsmaßnahmen und
Aspekte der Administration betrachtet werden.
MAC-Adresse Merkmal einer Netzwerkkarte im allgemeinen und somit auch der Hardware für den Zugang zu einem WLAN ist eine eindeutige, bereits beim Hersteller vorgegebene Hardwarekennung, die MAC-Adresse. Im AP kann eine Liste von MAC-Adressen
gespeichert werden, denen ein Zugriff auf das WLAN gewährt werden soll, alle anderen
werden abgelehnt; vgl. BSI (2002, S. 5). Dieser MAC-Adressfilter könnte vom Prinzip her
das Schutzziel Authentizität gewährleisten, wenn nicht das folgende Problem vorläge: Eine
MAC-Adresse einer Netzwerkkarte – obwohl ursprünglich so angedacht – ist nicht unveränderbar. Somit kann ein Angreifer bei Kenntnis einer zugelassenen MAC-Adresse seine
eigene MAC-Adresse anpassen und diesen Filter umgehen. MAC-Adressfilter bieten also
nur eine sehr geringe Sicherheit und werden deshalb auch kaum eingesetzt, zumal diese
Art der Zugangskontrolle einen hohen administrativen Aufwand erfordert, denn die Listen
im AP müssen von Hand gepflegt werden. Darüber hinaus kann bezüglich dieser Sicherungsmaßnahme keine vollständige Interoperabilität garantiert werden, da sie zwar auf
dem 802.11-Standard aufsetzt, aber nicht explizit in ihm enthalten ist; vgl. Wi-Fi Alliance
(2003a, S. 5).
SSID Ein BSS kann durch einen Netzwerknamen, den Service Set Identifier (SSID) identifiziert werden; vgl. Gast (2002, S. 75). Es besteht die Möglichkeit, bei einem AP einen
solchen 0 bis 32 Bytes langen Netzwerknamen zu vergeben. Ist dieser Name 0 Byte lang bzw.
der Betriebsmodus Any gesetzt, kann sich jeder Client beim AP anmelden. Der AP macht
in diesem Betriebsmodus mittels regelmäßig ausgesandter Beacon-Frames (Signalfeuer) auf
sich aufmerksam. Wird jedoch ein Name vergeben, so werden nur diejenigen Clients zugelassen, die eben diesen Netzwerknamen kennen. Der AP sendet in diesem Modus auch keine
Beacon-Frames sondern wartet nur auf passende Anfragen. Dieser Mechanismus dient zwar
primär der Identifikation von Service Sets (insbesondere in Extended Service Sets für den
Übergang zwischen verschiedenen Basic Service Sets), er kann aber auch als Zugangskontrolle zu diesen verstanden werden. Wobei auch hier nur eine minimale Sicherheit gewährt
werden kann, da die SSID meist im Klartext übermittelt wird und somit leicht abgefangen
werden kann. Die SSID kann darum das Schutzziel Authentizität allenfalls unterstützen,
aber nicht erfüllen. Dagegen stellt die SSID im Bezug auf das Schutzziel Anonymität eine
regelrechte Bedrohung dar: Wird als SSID zum Beispiel der Firmenname oder ein ähnliches
Identifizierungsmerkmal verwendet, so erfährt ein Angreifer bereits beim Abfangen einer
9
2.2 SICHERHEIT
Nachricht, wessen Daten er mitliest; vgl. Friedrich (2002). Unter anderem diese Nachlässigkeiten bei der Einrichtung von Firmennetzwerken aber auch von privaten Netzen hat dazu
geführt, daß das sog. ”War-Driving” immer beliebter wird; vgl. Edney und Arbaugh (2003,
S. 31 – 32). Es besteht darin, meist mit einem Auto und entsprechender Ausrüstung Straßen
in Ballungsgebieten abzufahren und nach angreifbaren Netzen zu suchen, die ausgespäht
werden können oder in die mit Hilfe von sog. Crack-Tools (siehe hierzu auch Abschnitt
2.3.2) eingebrochen werden kann. Diese Art von Massenangriff wird immer wieder auch
von Reportern verwendet, um mangelnde Sicherheitsvorkehrungen in zum Teil auch sehr
sensiblen Netzen wie denen von Arztpraxen aufzudecken. Ihre Berichte liefern meist ein
erschreckendes Bild; vgl. beispielsweise Accenture (2003, S. 21 – 24). Mehr Informationen
zum ”War-Driving” lassen sich z.B. auf Wardriving.com (HP) nachlesen.
Neben dem SSID kennt der 802.11-Standard auch die Basic Service Set Identification
(BSSID). Dabei handelt es sich aber schlicht um die MAC-Adresse eines APs in einem BSS;
vgl. Gast (2002, S. 41).
WEP-Sicherheitsarchitektur Die WEP-Sicherheitsarchitektur stellt den eigentlichen
Sicherheitsmechanismus des IEEE 802.11- bzw. 802.11b-Standards dar; vgl. IEEE (1999a,
S. 61 – 65). Es beinhaltet sowohl Mittel zur Verschlüsselung der Datenübertragung als
auch zum Schutz der Datenintegrität und zur Authentifizierung der Teilnehmer im Netz.
Diese drei Kernpunkte der WEP-Sicherheitsarchitektur versuchen die für das WLAN wichtigsten Schutzziele Vertraulichkeit, Authentizität und Integrität zu gewährleisten, doch zu
allen Teilen sind mittlerweile zahlreiche Schwachstellen bekannt, wodurch keines der drei
Ziele adäquat erreicht werden kann. Das Ziel der Anonymität wird aufgrund der bereits
erwähnten Übermittlung der MAC-Adresse im Klartext während der Authentifizierung
auch nicht erreicht. (Tatsächlich könnte theoretisch nur ein Angreifer mit einer gefälschten
MAC-Adresse anonym bleiben.)
Eine ausführliche Beschreibung der Elemente und Schwachstellen der WEP-Sicherheitsarchitektur folgt in den Abschnitten 2.3.1 und 2.3.2.
Administration Der Administration von WLANs kommt im Vergleich zum LAN eine
wesentlich höhere Bedeutung zu, denn im Gegensatz zum herkömmlichen kabelbasierten
LAN treten beim WLAN vor allem die physischen Sicherheitsprobleme in den Vordergrund. Während für einen Angriff auf ein kabelbasiertes Netz der physische Zugriff auf die
Datenleitung nötig ist, der bei entsprechenden Sicherheitsvorkehrungen im Bezug auf die
Räumlichkeiten und Gebäude, in denen das Netz betrieben wird, leicht unterbunden werden kann, machen Funkwellen nicht vor Gebäudegrenzen halt. Der Betrieb eines isolierten
Netzes (beispielweise ohne Internetanbindung und mit begrenztem Nutzerkreis) ist mit einem Funk-LAN nicht ohne weiteres möglich. Es ist also nötig, das WLAN vor allem logisch
abzusichern.
Eine gute logische Absicherung ist aber nicht allein von den eingesetzten Verfahren
abhängig, sondern auch von einer verantwortungsvollen Administration. Ein sonst sehr
gutes Authentifizierungsverfahren kann angreifbar werden, wenn der Schlüssel beispielweise nicht häufig genug gewechselt wird. (Zu einer der größten Schwachstellen der WEPSicherheitsarchitektur gehört daher auch die Langlebigkeit des verwendeten Schlüssels, wie
in Abschnitt 2.3.2 gezeigt wird.)
10
2.3 WEP-SICHERHEITSARCHITEKTUR
Wie oben bereits erwähnt, scheitert auch der Schutz durch die Überprüfung der MACAdressen an meist mangelndem administrativem Einsatz.
Ein wichtiger Bestandteil der Administration von WLANs ist außerdem die Auswahl des
Standortes der verwendeten APs. Denn Funkwellen können sich auch über die spezifizierte
Reichweite von 30 bis 150 Metern hinaus unkontrolliert ausbreiten, wodurch unter Umständen ein Abhören des WLANs auch außerhalb der vorgesehenen Nutzreichweite möglich ist.
Aber auch umgekehrt kann der Einfluß elektromagnetischer Funkwellen den Betrieb eines
WLANs stören, sei es unbeabsichtigt durch andere technische Systeme oder auch in Form
einer Denial Of Service (DoS)-Attacke durch den Einsatz von Störquellen (sog. Jammer);
vgl. auch BSI (2002). Der Administrator ist also gehalten, den Einfluß von elektromagnetischen Funk-Störquellen zu minimieren und bei etwaigen Störungen entsprechend schnell
handlungsfähig zu sein, um dem Schutzziel der Verfügbarkeit Rechnung zu tragen.
2.3
WEP-Sicherheitsarchitektur
Neben den nur eingeschränkt wirksamen Möglichkeiten, die SSID oder die MAC-Adresse
zur Absicherung eines auf dem IEEE 802.11- oder 802.11b-Standard beruhenden WLANs
heranzuziehen, beinhaltet die WEP-Sicherheitsarchitektur als Teil des Standards die eigentlichen Sicherheitsmechanismen zur Verschlüsselung, Integritätswahrung und Authentifizierung. Allerdings ist es auch gerade diese Sicherheitsarchitektur, die die größten Sicherheitsprobleme in WLANs impliziert. Obwohl sich der Name daraus ableitet, Wired Equavalent
Privacy kann dieses Protokoll sicher nicht erreichen.
Die folgenden Abschnitte zeigen auf, welche Verfahren durch WEP festgelegt werden,
und welche Schwachstellen diese Verfahren mit sich bringen.
2.3.1
Funktionsweise
WEP soll Vertraulichkeit, Integrität und Authentizität im WLAN sicherstellen. Für die
Vertraulichkeit kommt die Stromchiffre RC4 von RSA Security (HP) zum Einsatz (vgl.
IEEE (1999a, S. 61 – 65)), die Integrität wird mittels einer CRC (Cyclic Redundancy
Check)-Summe geschützt (vgl. IEEE (1999a, S. 40 – 41)) und für die Authentifizierung wird
ein Challenge-Response-Verfahren eingesetzt; vgl. IEEE (1999a, S. 59 – 61). Im folgenden
wird die Funktionsweise der einzelnen Verfahren kurz beschrieben.
Verschlüsselung Für die Verschlüsselung mittels des Stromchiffrier-Algorithmus RC4
wird wahlweise ein 40 oder 104 Bits langer Schlüssel verwendet, der sowohl dem AP als auch
allen im Netz befindlichen Clients bekannt sein muß. Es handelt sich um eine symmetrische
(Shared Key) Verschlüsselung, da der Schlüssel sowohl für die Verschlüsselung als auch
die Entschlüsselung verwendet wird. Der Standard sieht vor, daß bis zu vier verschiedene
Shared Keys definiert werden können, deren jeweilige Key-ID (KID) dann im Frame Body
mit übermittelt werden muß.
Die Verschlüsselung eines zu sendenden Datenpaketes, einer MSDU (MAC Service Data
Unit) (im folgenden Nachricht genannt), läuft wie folgt ab: Die Nachricht M (Message) wird
im ersten Schritt mit einer 32 Bits langen CRC-Prüfsumme (CRC-32) versehen, dem ICV
(Integrity Check Value); siehe dazu weiter unten. Dieser wird an das eigentliche Datenpaket angehängt und bildet verkettet mit der Nachricht den Klartext (MkICV). In einem
11
zweiten Schritt wird ein 24 Bits langer, zufälliger Initialisierungsvektor (IV) erzeugt und
mit dem geheimen Schlüssel K (Key) verkettet. Dieser String (KkIV), der je nach gewähltem geheimen Schlüssel 64 oder 128 Bits lang ist, dient als Grundlage für die Erzeugung
eines Schlüsselstroms durch den RC4-Algorithmus, aus dem ein Schlüssel RC4(KkIV) mit
der Länge des Klartextes entnommen wird. Als letzter Schritt folgt die XOR-Verknüpfung
des Klartextes mit dem Schlüsselstrom (MkICV) ⊕ RC4(KkIV), die den Schlüsseltext C
(Cyphertext) ergibt.
Abbildung 2 zeigt eine solche durch WEP verschlüsselte Nachricht (vgl. auch Freudl
(2003, S. 7)), der zur Vervollständigung des Frame Bodys noch der IV und eine 2 Bits
lange Key-ID für den verwendeten Schlüssel vorangestellt wird. (Die Schlüssel-ID wird
dabei mit Hilfe von 6 Füllbits auf die Länge eines vollen Bytes gebracht.)
Nachricht0-2304 Byte
ICV4 Byte
⊕
IV3 Byte
Schlüssel5|13 Byte
RC4-
Schlüsselstrom4-2308 Byte
=
IV3 Byte
Schlüsseltext4-2308 Byte
KID1 Byte
?
Frame Body
Abbildung 2: WEP-Verschlüsselung
Die maximale Länge von Nachrichten ist für den 802.11-Standard beschränkt auf 2304
Bytes. Damit ist die Länge des Frame Bodys von MAC-Frames beim Einsatz der WEPArchitektur gleich 2312 Bytes; vgl. IEEE (1999a, Abschnitt 6.2.1.1.2). Um die Zuverlässigkeit der Übertragung zu sichern, wird die Nachricht unter Umständen fragmentiert, bevor
sie verschlüsselt wird. Dies hat beim Einsatz von WEP allerdings keinen Einfluß auf die
Sicherheit und den Ablauf der Verschlüsselung. Die Fragmentierung wird deshalb hier nicht
weiter besprochen. Für weitere Informationen dazu siehe IEEE (1999a, Abschnitt 9.1.4).
Entschlüsselung Wird eine mittels WEP verschlüsselte Nachricht empfangen, so erfolgt
die Entschlüsselung der Daten folgendermaßen: Der Empfänger erhält die nötigen Informationen zur Entschlüsselung – nämlich den IV und die Schlüssel-ID – unverschlüsselt
übermittelt. Mit Hilfe des durch die KID festgelegten Schlüssels K und des IVs kann der
Empfänger denselben Schlüsselstrom RC4(KkIV) wie der Sender erzeugen. Da der Schlüsseltext C durch ein einfaches XOR mit dem Schlüsselstrom entstanden ist, kann wiederum
durch ein erneutes einfaches XOR des Schlüsseltextes C mit dem Schlüsselstrom der Klartext (MkICV) erzeugt werden. Es gilt (mit RC4 = RC4(KkIV)):
C ⊕ RC4 = {(M kICV ) ⊕ RC4} ⊕ RC4 = (M kICV ) ⊕ (RC4 ⊕ RC4) = (M kICV )
12
Abschließend wird über die entschlüsselte Nachricht der ICV berechnet und mit dem
erhaltenen ICV verglichen. Nur bei Übereinstimmung der beiden Prüfsummen wird die
Nachricht akzeptiert.
Integrität Zur Wahrung der Integrität einer Nachricht kommt eine CRC-32 Checksumme
zum Einsatz, die sonst eigentlich nur für die Absicherung gegenüber zufälligen Übertragungsfehlern eingesetzt wird. Um diese darum völlig unzureichende Integritätssicherung
etwas aufzuwerten, wird die Berechnung – wie in Abbildung 3 zu sehen – bereits durchgeführt, bevor die Nachricht verschlüsselt wird.
Nachricht0-2304 Byte
ICV4 Byte
6
CRC-32
Abbildung 3: WEP-Integritätswahrung
Der ICV wird anschließend mit der Nachricht verschlüsselt, doch auch das verhilft dem
ICV zu keiner höheren Sicherheit, wie in Abschnitt 2.3.2 gezeigt wird.
Einen eigentlich passenderen Einsatz erfährt CRC-32 bei der Absicherung des letztlich
zu übermittelnden Frames gegen Übertragungsfehler. Nachdem dem WEP Frame Body,
bestehend aus IV, Schlüssel-ID und der verschlüsselten Kombination aus Nachricht M und
ICV, ein MAC-Header vorangestellt wurde, der für die Adressierung im 802.11-Netz verwendet wird, wird mittels CRC-32 die Frame Check Sequence (FCS) berechnet. Abbildung
4 zeigt einen vollständigen MAC-Frame inklusive der angehängten FCS; vgl. IEEE (1999a,
S. 34).
MAC-Hdr.30 Byte
IV3 Byte
KID1 Byte
Schlüsseltext4-2308 Byte
FCS4 Byte
6
CRC-32
Abbildung 4: WEP-Fehlerkorrektur
Bevor der Empfänger die übermittelten Daten wie weiter oben beschrieben entschlüsselt
und deren Integrität überprüft, wird anhand der FCS sichergestellt, daß die Datenübermittlung fehlerfrei verlaufen ist.
Authentifizierung Der IEEE 802.11-Standard erlaubt zwei Betriebsmodi für die Authentifizierung in einem WLAN: Open System und Shared Key. Ist der Access Point auf
13
Open System konfiguriert, findet keine Authentifizierung statt und jeder Client kann sich
an dem AP anmelden. Im Shared-Key-Modus müssen sich die Clients in einem ChallengeResponse-Verfahren mit dem bereits aus der Verschlüsselung bekannten gemeinsamen
Schlüssel am AP authentifizieren; vgl. Weatherspoon (2000, S. 3).
Der Client muß für eine Anmeldung gegenüber dem AP beweisen, daß er den geheimen
gemeinsamen Schlüssel kennt. Im ersten Schritt stellt der Client die Authentifizierungsanfrage an den AP. Hierbei übermittelt der Client seine Identität in Form seiner MAC-Adresse
(48 Bits), eine 16 Bits lange Authentication Algorithm Identification (AAI), die die Authentifizierungsmethode angibt (in diesem Fall 1 für Shared Key), und eine ebenfalls 16
Bits lange Sequenznummer (SN), die für Kontinuität bei den vier Authentifizierungsschritten sorgen soll. Der AP antwortet darauf im zweiten Schritt mit der gleichen AAI, einer
um 1 erhöhten Sequenznummer und einer 128 Bytes langen Zufallszahl. Als Antwort auf
diese Challenge des APs verschlüsselt der Client in einem dritten Schritt alle drei Angaben,
die er von dem AP erhalten hat, mit dem gemeinsamen geheimen Schlüssel (allerdings mit
einer wieder um 1 erhöhten Sequenznummer) und sendet den Schlüsseltext zurück an den
AP. Dieser verifiziert im letzten Schritt die Response des Clients und schickt bei erfolgreicher Entschlüsselung des Schlüsseltextes neben der AAI und einer erneut um 1 erhöhten
Sequenznummer die Authentifizierungsbestätigung successful an den Client. Im negativen
Fall würde unsuccessful übertragen. Abbildung 5 zeigt die vier Schritte des Ablaufs der
Challenge-Response-Authentifizierung; vgl. auch Freudl (2003, S. 10).
MAC6 Byte , AAI=12 Byte , SN=12 Byte
-
AAI=12 Byte , SN=22 Byte , Challenge128 Byte
Client
WEP AAI=12 Byte , SN=32 Byte , Challenge128 Byte
AP
-
AAI=12 Byte , SN=42 Byte , successful
Abbildung 5: WEP-Authentifizierung
Bei der Verwendung von Open System würde die erste Nachricht mit der AAI = 0 gesendet werden und bereits die Antwort darauf würde mit successful die Anmeldung bestätigen,
wenn der AP auf Open System konfiguriert wurde.
2.3.2
Schwachstellen
Abgesehen von systematischen Schwächen der einzelnen Verfahren liegt eine nicht zu unterschätzende Schwachstelle von WLAN-Komponenten darin, daß die optionalen Sicherheitsmechanismen der WEP-Sicherheitsarchitektur im Auslieferungszustand meist deaktiviert
sind. So wird z.B. Open System als Standardeinstellung sogar im 802.11-Standard vorgegeben. In vielen Fällen werden somit aufgrund von Unwissenheit entsprechende Verfahren
überhaupt nicht eingesetzt.
14
Aber selbst wenn sie eingesetzt werden, bieten sie nicht den gewünschten Schutz vor
Angriffen: Sowohl passive Angriffe, die darauf abzielen, den Inhalt der Datentransfers zu
ermitteln, also die Vertraulichkeit auszuhebeln, sind möglich, als auch aktive Angriffe, die
die Integrität und Authentizität der übermittelten Daten bedrohen und dazu dienen, z.B.
fremde oder manipulierte Daten in den Datenverkehr einzuschleusen oder diesen ganz zu
verhindern. Zu den passiven Angriffen gehören z.B. Brute-Force-Attacken, bei denen durch
systematisches Ausprobieren aller Möglichkeiten versucht wird, den gemeinsamen Schlüssel
zu brechen, oder auch die sog. Known-Plaintext-Attacke, bei der ein Angreifer, der bereits
in Besitz eines oder mehrerer Klartext/Schlüsseltext-Paare ist, versucht, weitere Schlüsseltexte zu entschlüsseln. Eine aktive Attacke bestünde z.B. darin, mit einem eigenen AP die
Nutzer eines WLANs von ihrem eigentlichen AP abzuziehen (Spoofing) oder mittels einer
Replay-Attacke bereits verwendete Datenpakete bestimmten Inhalts in den Datenverkehr
einzuschleusen.
Im folgenden werden die wichtigsten Schwachstellen in der WEP-Sicherheitsarchitektur
kurz beschrieben und mögliche Angriffe skizziert. Für eine intensivere Untersuchung der
einzelnen Schwächen und den daraus resultierenden Angriffsszenarien sei hier aber z.B. auf
Borisov et al. (2001), Fluhrer et al. (2001), Arbaugh et al. (2001) oder Potter und Fleck
(2003) verwiesen.
Administration Ein Teil der Probleme bezüglich mangelnder Sicherheit sind nicht ausschließlich technischer Natur. Durch fehlende oder schlechte Administration werden eventuelle Angriffe gefördert bzw. auch erst möglich gemacht. So ist eines der Hauptprobleme
ein über viel zu lange Zeit gleichbleibender verteilter Schlüssel, der somit auch rechen- bzw.
zeitintensiven Angriffen Erfolg verspricht. Bei entsprechend großen WLANs beinhaltet ein
Schlüsseltausch allerdings auch einen nicht unerheblichen Aufwand, da dieser Wechsel manuell durchgeführt werden muß – die eigentliche Ursache des Problems ist also hier wiederum im Design der WEP-Sicherheitsarchitektur zu suchen. Eine weitere Gefahr stellt
das mangelnde Sicherheitsbewußtsein von Anwendern aber auch von Administratoren dar.
Hier erliegen nicht nur unbedarfte Privatanwender den nebulösen Sicherheitsversprechen
der Hardwarehersteller und Händler, die ihnen suggerieren, daß allein die Aktivierung von
WEP bereits eine ausreichende Sicherung ihres Netzes zur Folge hätte.
Schlüssellänge Eine Schlüssellänge von 40 Bits ist vollkommen unzureichend. (Diese
Schlüssellänge war allerdings die größte, problemlos aus den USA zu exportierende zu der
Zeit, als die WEP-Sicherheitsarchitektur entwickelt wurde.) Bei einem so kurzen Schlüssel
kann bereits nach dem Abfangen einer einzigen verschlüsselten Nachricht durch einen BruteForce-Angriff, also durch einfaches Durchprobieren aller möglichen 40 Bits langen Schlüssel,
der geheime verteilte Schlüssel ermittelt werden. Hinzu kommt, daß von vielen Herstellern Keygeneratoren eingesetzt werden, die es den Benutzern ermöglichen, sich aus reinen
ASCII-Zeichenfolgen Schlüssel generieren zu lassen, statt den Schlüssel in hexadezimaler
Schreibweise selbst einzugeben. Diese Keygeneratoren sind mit einer Schwäche behaftet,
die dazu führt, daß die Möglichkeiten für die Startsequenz des der WEP-Architektur eigenen PRNGs (Pseudo-Random Number Generator) eingeschränkt werden, wodurch sich die
Anzahl der bei einem Angriff zu prüfenden Schlüssel erheblich reduziert; vgl. Freudl (2003,
S. 11 – 13). Erst eine Schlüssellänge von 104 Bits bietet (allerdings auch nur bei sinn15
voller Schlüsselwahl) Sicherheit gegenüber Brute-Force-Attacken auf der Basis der heute
verfügbaren Rechenleistung.
Initialisierungsvektor Die Länge von 24 Bits für den IV ist ebenfalls viel zu kurz. Da
der Shared Key als konstant anzunehmen ist, erlaubt diese Länge lediglich 224 verschiedene
Schlüssel. Es ist hierbei auch unerheblich, ob der eigentliche Schlüssel 40 oder 104 Bits lang
ist. Spätestens also nach 224 versendeten Paketen wiederholt sich der IV. Obwohl der IV
zufällig gewählt werden sollte, wurde von vielen Herstellern meist nur ein einfacher Zähler
verwendet, der bei jedem Reset der Hardware wieder bei 0 beginnt. Aber selbst wenn der
IV zufällig gewählt wird, ist die Wahrscheinlichkeit der erneuten Verwendung eines IVs
bereits nach 4823 übermittelten Paketen größer als 50%. Es liegt also auf der Hand, daß es
ein Leichtes sein wird, zwei Pakete abzufangen, die mit dem gleichen Schlüssel verschlüsselt wurden. Liegen zwei solche Pakte vor, kann durch die Anwendung eines XORs auf
die beiden Schlüsseltexte der Schlüsselstrom entfernt werden. Das Ergebnis entspricht der
Anwendung eines XORs auf die beiden unverschlüsselten Datenpakete. Sind nun Teile des
einen Klartextes bekannt, kann der andere einfach abgelesen werden. Durch die Anwendung
von Wörterbüchern oder Heuristiken können die Klartexte entschlüsselt werden. Gelingt
dies, ist natürlich auch die Kombination von IV und Shared Key bekannt, was erlaubt,
beliebige Nachrichten einzuschleusen, da keine Prüfung der Wiederverwendung von IVs
vorgenommen wird.
Schon im Standard selbst wurde auf dieses Problem hingewiesen; vgl. IEEE (1999a, S.
63).
Prüfsumme Eine CRC-Summe ist für die Integritätsprüfung völlig wirkungslos. Das
Verfahren diente ursprünglich dazu, Übertragungsfehler zu erkennen. Diese zufälligen Störungen vermag das Verfahren auch mit einer sehr geringen Fehlerwahrscheinlichkeit von
2−32 zu entdecken; vgl. BSI (2002, S. 7). Borisov et al. (2001) zeigen jedoch, daß es die
CRC-Summe aufgrund ihrer linearen Form in Kombination mit der ebenfalls linearen
Stromchiffre RC4 erlaubt, kontrollierte Änderungen am Schlüsseltext vorzunehmen, ohne die Checksumme zu verletzen. Damit kann also das Hauptziel der Integrität durch die
WEP-Sicherheitsarchitektur nicht gewährleistet werden, da bereits einfache passive Angriffe möglich sind.
Chiffrealgorithmus Die Stromchiffre RC4 leidet an einem grundsätzlichen Designfehler, der passive Angriffe ermöglicht. Von Fluhrer et al. (2001) wurde dargelegt, daß die
weitestgehend auf Permutationen basierende Stromchiffre RC4 unter Umständen nicht gut
genug permutiert und dadurch bestimmte Gruppen von IVs ermittelt werden können, die
zu besonders einfach zu brechenden Verschlüsselungen führen; vgl. auch Mann (2003). Die
Attacke auf diese Schwachstelle wird teilweise auch nach den Autoren des Papers über die
Sicherheitslücke als Fluhrer-Mantin-Shamir (FMS)-Attacke bezeichnet; vgl. Edney und Arbaugh (2003, S. 242 + 243). Eine ausführliche Beschreibung zur Anwendung dieses Angriffs
bieten Stubblefield et al. (2001).
Die Schwäche des Chiffrealgorithmus ist das häufigste Ziel der zahlreichen frei im Internet erhältlichen Crack-Tools, mit denen es jedem möglich ist, Angriffe auf WLANs durchzuführen. Am bekanntesten unter diesen Angriffswerkzeugen ist das Programm AirSnort
16
(PRG); vgl. auch Potter und Fleck (2003, S. 16). Wie auch WEPCrack (PRG) ermöglicht
es dem Benutzer, auf relativ einfachem Weg den der WEP-Sicherheitsarchitektur zugrundeliegenden Schlüssel zu ermitteln. (Zu weiteren Angriffswerkzeugen siehe unten.)
Wie ein auf der Schwäche der RC4-Stromchiffre basierender Angriff praktisch durchgeführt werden kann und wieviele Pakete hierfür bei welcher Paketgröße und Netzauslastung
abgefangen werden müssen, beschreibt z.B. BSI (2002, S. 7 – 8).
Schlüsselmanagement Ein Schlüsselmanagement ist in der WEP-Sicherheitsarchitektur
nicht vorgesehen. Deshalb muß bei einem Schlüsselwechsel in allen Clients und APs manuell ein neuer Schlüssel eingetragen werden, was physischen Zugriff auf die entsprechenden
Komponenten erfordert. Dies führt meist dazu, daß der Schlüssel nur sehr selten bzw. überhaupt nicht gewechselt wird, oder aber dazu, daß der Schlüssel mangels physischem Zugriff
über unsichere Übertragungswege zum Anwender übermittelt wird.
Eine im Standard vorgesehene Speicherung von bis zu vier verschiedenen Shared Keys
auf einem WLAN-Gerät hätte die Situation zumindest etwas verbessern können, bloß erlaubt bisher kein Gerät einen automatischen Wechsel zwischen den einzelnen Schlüsseln,
wodurch meist doch nur ein einziger Schlüssel verwendet wird; vgl. IEEE (1999a, S. 64 –
69).
Authentifizierung Das Authentifizierungsprotokoll (sofern es überhaupt aktiviert ist)
kann leicht gebrochen werden. Ist der Angreifer in der Lage, einen vollständigen ChallengeResponse-Austausch einer Datenstation mit dem AP mitzuschneiden, kann durch die Anwendung eines einfachen XORs auf Challenge und Response der Schlüsselstrom errechnet
werden, mit dem der Angreifer anschließend die Möglichkeit besitzt, zu jeder Challenge
eine entsprechende Response zu erzeugen.
Weiterhin erlaubt das Protokoll lediglich eine einseitige Authentifizierung, denn es sieht
nur die Anmeldung des Clients am AP vor. Der AP muß sich dagegen nicht authentifizieren.
Somit kann der Client nicht erkennen, ob seine Nachrichten nicht von einem fremden AP,
der mit einer stärkeren Sendeleistung den eigentlichen AP überlagert, abgefangen werden.
In diesem Fall wird von dem sog. Spoofing gesprochen. Schließlich ist zu bemängeln, daß die
Authentifizierung nur die verwendete Hardware betrifft, nicht aber die Benutzer. Aufgrund
dieser fehlenden Nutzer-Kontrolle, kann jeder, der Zugriff auf einen Client erlangt, auch
Zugriff zum WLAN erlangen.
Schlüsselunabhängigkeit Für die Erreichung von zwei verschiedenen Sicherheitszielen
sollten unabhängige Schlüssel eingesetzt werden. Da in der WEP-Sicherheitsarchitektur
aber sowohl für die Authentifizierung als auch für die Verschlüsselung derselbe Schlüssel
verwendet wird, bedeutet der erfolgreiche Angriff auf eines der beiden Verfahren zugleich
auch den Bruch des jeweils anderen.
Angriffswerkzeuge Nicht nur zur Ermittlung des WEP-Schlüssels existieren fertige Softwarelösungen. Auch das komfortable Abhören (vgl. Aerosol (PRG)) und Analysieren von
Datenpaketen (vgl. Etheral (PRG)) und sogar das Vortäuschen eines APs mittels einer einfachen WLAN-Netzwerkkarte ist möglich; vgl. HostAP (PRG). Diese Tools sollen hier aber
nur als Referenz für weitere Recherchen erwähnt werden. Eine sehr umfangreiche Liste an
17
verfügbaren Werkzeugen, die neben den oben genannten eine ganze Reihe von verschiedenen
Angriffen auf WLANs ermöglichen, bietet Accenture (2003, S. 33 + 34).
18
3
Zwischenlösungen
Nachdem die gravierenden Unzulänglichkeiten der WEP-Sicherheitsarchitektur schon früh
bekannt geworden sind, wuchs der Bedarf an einer verbesserten Sicherheitsarchitektur sehr
schnell, da auch zu befürchten war, daß die WLAN-Technologie aufgrund der Sicherheitsprobleme keinen großen Erfolg haben würde – vor allem nicht im professionellen Umfeld. An
eine schnelle Verabschiedung eines neuen IEEE-Standards, der die Sicherheitsarchitektur
komplett überarbeiten würde, war hierbei allerdings nicht zu denken. Deshalb mußte vor allem versucht werden, auf der Basis der Sicherheitsmechanismen des IEEE 802.11-Standards
eine Absicherung der über das WLAN übertragenen Daten zu erreichen. Hier bieten sich
Mechanismen an, die – bezogen auf das ISO-OSI-Modell – in höheren Schichten angesiedelt
sind als die der WEP-Architektur: Anstatt Änderungen an der zugrundeliegenden Übertragungsart der Daten vorzunehmen, werden so einfach die Datenpakete selbst abgesichert,
bevor sie über ein WLAN in Frames übertragen werden. Zum Einsatz kommen dabei Techniken wie Virtual Private Networks (VPNs) auf der Basis von IPsec (Internet Protocol
Security) oder z.B. mittels SSH (Secure Shell) verschlüsselte Verbindungen.
Selbstverständlich wurde das Problem der Unsicherheit des 802.11-Standards auch seitens der IEEE selbst angegangen. Bereits Ende 2000 begannen die Arbeiten an einer Erweiterung und Verbesserung der Sicherheitsarchitektur von 802.11-WLANs. Der neue IEEE
802.11i-Standard soll alle Probleme, an denen die WEP-Sicherheitsarchitektur krankt,
durch den Einsatz neuer Sicherheitsmechanismen beheben; siehe hierzu Kapitel 4. Er hat
aber auch den Nachteil, daß mit dem Wechsel der Sicherheitsarchitektur ein Wechsel der
zugrundeliegenden Hardware einhergehen muß, da nicht alle Elemente aus dem 802.11iStandard kompatibel zu der bestehenden Hardware sind. Darüber hinaus ist eine mögliche
Verabschiedung des neuen Standards nicht vor Anfang 2004 zu erwarten.
Es mußte allerdings schnell etwas getan werden, um dem Unsicherheitsmakel von
WLANs entgegenzutreten, insbesondere da die Lösungen auf der Basis von VPNs langfristig nicht zufriedenstellend sind, wenn bedacht wird, daß die Neueinrichtung von VPNs
mit nicht unerheblichem Mehraufwand verbunden ist, bzw. auch nicht in jedem Fall möglich ist. So wurden auf Bestreben der Wi-Fi Alliance im letzten Jahr die bis dahin bereits
fertigen Teile des IEEE 802.11i-Standards, die auf der bestehenden Hardware einsetzbar
waren, zu der Wi-Fi Protected Access (WPA)-Sicherheitsarchitektur zusammengefaßt und
schon im April dieses Jahres als eigenständiger Standard veröffentlicht; vgl. Wi-Fi Alliance
(2003c). Die WPA-Sicherheitsarchitektur wurde dabei so gestaltet, daß sie sowohl kompatibel zu der bereits existierenden Hardware ist und dort durch ein einfaches Software-Update
eingespielt werden kann, als auch zu der für den 802.11i-Standard nötigen neuen Hardware,
so daß eine Investition in WPA sicher ist, zugleich aber auch wegbereitend für die nächste
Generation von WLAN-Geräten. Bereits seit Mitte 2003 sind Produkte und Updates mit
WPA-Unterstützung auf dem Markt.
Da der 802.11-Standard generell Freiraum für Erweiterungen der Sicherheitsmechanismen gelassen hatte, ist zwar die WPA-Sicherheitsarchitektur die mit Abstand erfolgreichste,
aber dennoch nicht einzige Weiterentwicklung der bestehenden Systeme. So wird z.B. von
Agere Systems Inc. (HP) die WEP-Erweiterung WEPplus angeboten und RSA hat mit FPK
(Fast Packet Keying) ein neues Verfahren entwickelt, um dynamische WEP-Schlüssel zu erzeugen. Ansätze, die sich allerdings nicht in den bestehenden Rahmen der IEEE-Umgebung
einfügen, haben wohl nur geringe Chancen am Markt.
19
3.1 VPN MIT IPSEC
Bei der Betrachtung der möglichen Abhilfen für die unzureichenden Sicherheitsmechanismen in der WEP-Architektur stellt sich – bevor der falsche Eindruck entsteht, WLANs
seien bisher nicht einsatzfähig gewesen – allerdings auch die Frage, ob eine so hohe Sicherheit denn überhaupt in allen Fällen zwingend nötig ist. Beim Einsatz eines WLANs
in einem Firmennetzwerk ist diese Frage sicher leicht zu beantworten, doch bei einem Adhoc-Netzwerk beispielsweise für den Zweck und die Dauer eines Netzwerkspiels kann auf
Sicherheit durchaus verzichtet werden. Sie kann sogar unerwünscht sein, wenn z.B. für
Verschlüsselungen Rechenleistung gebraucht wird, die dann dem Spielablauf verloren geht.
Grundsätzlich gilt deshalb, daß Betrachtungen der Sicherheitsmechanismen auch im Kontext des angestrebten Einsatzbereiches der WLAN-Technik zu beurteilen sind.
Die folgenden Abschnitte beschreiben, welche Zwischenlösungen derzeit und sehr wahrscheinlich auch über die bevorstehende Verabschiedung des IEEE 802.11i-Standards hinaus zur Anwendung kommen. Nach der Vorstellung der am häufigsten eingesetzten zusätzlichen Techniken unter Beibehaltung des ursprünglichen Standards wird die WPASicherheitsarchitektur beschrieben. Hierbei wird auf eine genauere Betrachtung der zugrundeliegenden Sicherheitsmechanismen verzichtet, da diese als Bestandteil des 802.11iStandards anschließend in Kapitel 4 detailliert besprochen werden. Schließlich geht dieses
Kapitel noch kurz auf alternative Ansätze zur Ablösung bzw. Verbesserung der WEPSicherheitsarchitektur ein.
3.1
VPN mit IPsec
Der Haupteinsatzzweck von VPNs war ursprünglich die Bereitstellung einer Möglichkeit,
die Sicherheit, die durch gemietete bzw. dedizierte Netzwerkleitungen z.B. eines firmenweiten Intranets gegeben ist, auch auf öffentlichen Leitungen (Internet) zu erreichen, um
somit Kosten für private Leitungen sparen zu können. VPNs simulieren dazu mittels eines sog. Tunnels die Abwicklung des Datenverkehrs auf einer isolierten Datenleitung über
das WAN (Wide Area Network), obwohl der Datenverkehr tatsächlich parallel zu fremden
Datenübertragungen durch eine gemeinsam genutzte, ungeschützte Datenleitung geführt
wird; vgl. VPN Consortium (2003).
Das WLAN ist zwar von seinem Aufbau her als Intranet angelegt, doch aufgrund der
Unsicherheit eher mit dem Internet zu vergleichen, bei dem auch damit gerechnet werden muß, daß die übermittelten Daten abgehört oder verfälscht werden können. Was liegt
da also näher, als eine bewährte Sicherheitstechnologie, die bereits erfolgreich über offene
WANs angewendet wird, auch im Bereich von WLANs einzusetzen. Bereits seit 1990 werden
VPNs im überwiegend betrieblichen Umfeld in herkömmlichen LAN/WAN Kombinationen
verwendet. Die Ausweitung des Einsatzes dieser Technologie auf WLANs bedarf in diesen
Fällen darüber hinaus also nicht einmal großer Anstrengungen; vgl. Wi-Fi Alliance (2003a,
S. 5).
Unter einem Tunnel im Sinne von VPNs ist ein Verfahren zu verstehen, nach dem
ein zu sendendes Datenpaket komplett in ein weiteres Paket gekapselt (im allgemeinen
verschlüsselt) wird, um dann als neues Datenpaket über das Netz versendet zu werden. Auf
der Empfängerseite wird dann das eigentliche Datenpaket aus dem empfangenen Paket
wieder extrahiert bzw. entschlüsselt. Der Transport der Daten erfolgt damit wie durch
einen Tunnel. Hierbei ist zu beachten, daß sich Sender und Empfänger vor der Etablierung
der Tunnel-Verbindung authentifiziert haben müssen, damit das jeweils andere Tunnelende
20
3.1 VPN MIT IPSEC
auch lokal bekannt ist.
Es ist ersichtlich, daß bei dem Einsatz eines Tunnels neben dem eigentlichen Übertragungsprotokoll der Originalnachricht zwei weitere Technologien bzw. Protokolle involviert sind: Das Träger-Protokoll, mit dem die gekapselte Nachricht transportiert wird, und
das Verschlüsselungs-Protokoll, mit dem die Original-Nachricht vor unbefugtem Zugriff
geschützt wird. Prinzipiell wären hier beliebige Kombinationen von Protokollen möglich,
durchgesetzt hat sich jedoch die Verwendung von IPsec – und zwar sowohl als TrägerProtokoll als auch für die Verschlüsselung. Dies ist möglich, da IPSec aus einer Reihe von
verschiedenen Protokollnormen besteht, die auch miteinander kombiniert werden können.
Sie wurden in Form von RFCs (Requests For Comments), den Standardisierungsdokumenten der Internet Engineering Task Force (IETF) dokumentiert. Der größte Vorteil von IPsec
ist die Tatsache, daß dieses Protokoll auf der Netzwerkschicht (Schicht 3) angesiedelt ist.
Es ist somit ein transparenter Einsatz von IPsec möglich – völlig unabhängig von den
verwendeten Anwendungsprogrammen.
IPsec bietet aber noch mehr als nur einen verschlüsselten Übertragungsmechanismus in
Gestalt des ESPs (Encapsulating Security Payload): Es ermöglicht darüber hinaus, die Integrität und die Authentizität der Nachricht zu garantieren (Authentication Header (AH))
und stellt sogar Mittel für ein integriertes Schlüsselmanagement (IKE (Internet Key Exchange)) zur Verfügung. All diese Merkmale von IPsec werden in den RFCs 2401 bis 2409
beschrieben; vgl. z.B. Kent und Atkinson (1998). Eine zusammenfassende Beschreibung der
einzelnen Protokolle findet sich darüber hinaus z.B. bei Richter (2003).
IPsec kann jedoch nur eine sichere Verbindung zwischen Geräten und nicht zwischen Benutzern herstellen, weshalb beim Einsatz von IPsec als Tunneling-Protokoll die Verwendung
einer weiteren Authentifizierungsinstanz nötig ist. Der Benutzer muß sich erst bei einem
VPN-Authentifizierungsserver, der direkt an den AP angeschlossen sein sollte, authentifizieren. Dies geschieht nach Möglichkeit mittels digitaler Zertifikate in einer etablierten PKI
(Public Key Infrastruktur). Erst nach erfolgreicher Anmeldung erfolgt dann der Aufbau
eines sicheren VPN-Tunnels mittels IPsec. Falls kein dedizierter VPN-Server auf der Seite
des APs zum Einsatz kommt, bietet es sich an, zusätzlich noch eine Firewall einzusetzen.
Eine weitere Einschränkung von IPsec besteht darin, daß es auf das Tunneln von IP
(Internet Protocol)-Paketen beschränkt ist. Dienste, die auf ältere Protokolle der Netzwerkschicht wie beispielsweise das X.25-Protokoll oder IPX (Internet Packet Exchange)
von Novell angewiesen sind, können damit nicht ausgeführt werden. Diese Möglichkeit bietet allerdings ein weiteres Tunneling-Protokoll, das L2TP (Layer 2 Tunneling Protocol),
das aus dem Point-to-Point Tunneling Protocol (PPTP) und dem L2F (Layer 2 Forwarding) hervorgegangen ist. Jedoch verwendet L2TP weder Verschlüsselung noch eine Paketauthentifizierung. Erst wieder in Verbindung mit IPsec könnte somit ein Einsatz als
VPN-Tunnelling-Protokoll sinnvoll sein; vgl. Patel et al. (2001). Da aber dem Einsatz von
Netzen, die noch auf alten Netzwerkprotokollen basieren, immer geringere Bedeutung zukommt, wird IPsec wohl die einzige Grundlage für VPNs – zumindest in den niedrigen
ISO-OSI-Schichten – bleiben.
Insgesamt erscheinen VPNs in der Tat als eine sehr praktikable Lösung für die Sicherheitsprobleme der 802.11-Hardware. Nachteilig für den Einsatz von VPNs wirkt sich
allerdings aus, daß die Technologie einen erhöhten administrativen Einsatz erfordert. Entgegen einer Sicherheitslösung, die in der WLAN-Hardware implementiert ist, bedarf es für
21
3.2 SSL UND SSH
die Nutzung eines VPNs der Installation einer VPN-Software auf jedem Client; vgl. Wi-Fi
Alliance (2003a, S. 5).
Weitere Informationen zu VPNs und IPsec, insbesondere auch zu den zugrundeliegenden
Standards und RFCs finden sich beim Virtual Private Network Consortium (VPNC) (vgl.
VPNC (HP)) und der IETF (HP).
3.2
SSL und SSH
Das SSL (Secure Socket Layer)-Protokoll kann, obwohl es kein Tunneling-Protokoll im
eigentlichen Sinne ist, ebenfalls als Basis für ein VPN genutzt werden. Allerdings ist hierbei
darauf zu achten, daß es sogar noch oberhalb von TCP (Transmission Control Protocol)
angesiedelt ist und sich zusammen mit diesem auf Schicht 4 des ISO-OSI-Modells – der
Transportschicht – einordnen läßt.
Ein Vorteil des zertifikatbasierenden SSL-Protokolls ist allerdings, daß kein VPN-Client
benötigt wird. Die Funktion des Clients übernimmt meist der lokal installierte WebBrowser. (Was nicht weiter verwundert, da das SSL-Protokoll eine Entwicklung von Netscape ist.) Das SSL-Protokoll verwendet eine Public-Key-Verschlüsselung für die Authentifizierung und den Schlüsselaustausch der eingesetzten Verschlüsselungsalgorithmen unter Verwendung von durch vertrauenswürdigen Institutionen ausgestellten Zertifikaten. Als
Verschlüsselungsprotokolle unter dem Einsatz des SSL-Protokolls kommen beispielsweise
die RC4-Verschlüsselung oder der DES in Frage.
Zu den auf der Anwendungsschicht angesiedelten Diensten, die über SSL gesichert werden können, gehört beispielsweise das HTTP (Hypertext Transfer Protocol), das durch SSLAbsicherung zum HTTPS (HTTP Secure) wird. Gleiches gilt für das FTP (File Transfer
Protocol) und SFTP (Secure FTP). Aber auch Mail- und Verzeichnisdienste wie z.B. das
POP3 (Post Office Protocol 3), das IMAP4 (Internet Message Access Protocol 4) oder das
LDAP (Lightweight Directory Access Protocol) profitieren von einer durch SSL geschützten
Verbindung; vgl. Potter und Fleck (2003, S. 34 + 35).
Obwohl im SSL-Protokoll auch die RC4-Verschlüsselung zur Anwendung kommen kann,
ist dieses Protokoll nicht von der in Abschnitt 2.3.2 beschriebenen Anfälligkeit für schwache Schlüssel betroffen, da hier die Schlüssel (mittels einer Hashfunktion) für eine Session
und nicht für jedes einzelne Paket generiert werden und somit Wiederholungen praktisch
ausgeschlossen sind; vgl. RSA Security (2001).
Das SSL-Protokoll kommt im übrigen in einer standardisierten Version unter dem Namen TLS (Transport Layer Security) auch als sog. Upper-Layer-Authentifizierungsprotokoll
im IEEE 802.11i-Standard zum Einsatz. Für weitere Informationen zu der Funktion des
Protokolls siehe deshalb auch Abschnitt 4.5.4.
Bei SSH (Secure Shell) handelt es sich um ein weiteres Protokoll, das auf der Transportschicht oberhalb von TCP/IP angesiedelt ist. Es wird für Remote-Logins genutzt und
bietet dabei wie das SSL-Protokoll eine Public-Key-Verschlüsselung der Authentifizierung
und des Schlüsselaustausches für verschiedene Verschlüsselungsalgorithmen; vgl. Potter und
Fleck (2003, S. 35 + 36). Ferner ist es auch mit Hilfe des SSH-Protokolls möglich, Tunnel
zwischen zwei Rechnern zu erstellen. In diesem Fall kann damit aber jeweils nur ein bestimmtes Protokoll abgesichert werden, eine vollständige VPN-Funktionalität ist also nicht
möglich. Erreicht wird die Absicherung dabei durch das Weiterleiten eines bestimmten
Ports eines Rechners – beispielsweise Port 110 für POP3 – zu einem bestimmten Port eines
22
3.3 WPA-SICHERHEITSARCHITEKTUR
anderen Rechners. Zugriffe auf den lokalen Port werden über diesen abgesicherten Tunnel
automatisch an den entsprechenden Port des fremden Rechners weitergeleitet.
Derzeit wird seitens der IETF an einer offiziellen Standardisierung des Protokolls gearbeitet; vgl. Ylonen (2003).
3.3
WPA-Sicherheitsarchitektur
Ebenso wie bei der Einführung des Wi-Fi-Logos hat auch bei der WPA-Architektur, die
ursprünglich als Safe Secure Network (SSN) geplant war (vgl. Burns und Hill (2003)),
der Zusammenschluß von Herstellern und die Einigung auf eine gemeinsame Sicherheitsarchitektur zu einem wesentlich größeren Erfolg auf dem Markt geführt, als dies wohl bei
mehreren Einzellösungen der Fall gewesen wäre. Die treibende Kraft bei der Entwicklung
war dabei der Hersteller Intersil (HP), der auch als erster entsprechende Produkte auf den
Markt gebracht hat.
Die WPA-Sicherheitsarchitektur (vgl. Wi-Fi Alliance (2003c)) sollte mehreren wichtigen Zielen genügen: Sie mußte eine wesentlich höhere Sicherheit als die WEP-Sicherheitsarchitektur bieten, aber dabei die Fähigkeit besitzen, per Software-Update auf bestehende Hardware mit Wi-Fi-Logo installierbar zu sein. Des weiteren sollte die Technik
sowohl für den Privatanwender als auch für Firmennetze verfügbar sein und das – so die
wichtigste Anforderung – möglichst sofort. Darüber hinaus war aber auch bekannt, daß ein
neuer IEEE-Standard in der Entwicklung war, der sicher die Zukunft der Entwicklung im
WLAN-Bereich bestimmen würde. Auf eine Aufwärtskompatibilität zum 802.11i-Standard
zu verzichten, wäre offenkundig nicht ratsam gewesen. Es bot sich also an, die bereits fertiggestellten Elemente des 802.11i-Standards, die sich auf bestehender Hardware einsetzen
ließen, zu einer eigenen Sicherheitsarchitektur zu kombinieren und möglichst schnell auf
den Markt zu bringen, denn auf die Umsetzung vom 802.11i-Standard muß wohl noch bis
2004 gewartet werden; vgl. Wi-Fi Alliance (2003b).
Entgegen der WEP-Sicherheitsarchitektur ist die WPA-Architektur nur für den Infrastruktur-Modus spezifiziert; vgl. Lowery und Miller (2003, S. 118). In diesem führt sie
neben einem Schlüsselmanagement auch neue Protokolle und Verfahren zur Erreichung
der wichtigsten Schutzziele Vertraulichkeit, Integrität und Authentizität ein; vgl. Wi-Fi
Alliance (2002) oder Wi-Fi Alliance (2003b). Die folgenden Abschnitte fassen kurz die entsprechenden Neuerungen zusammen, da es sich bei der WPA-Sicherheitsarchitektur wie
oben erwähnt lediglich um eine Teilmenge der Bestandteile des IEEE 802.11i-Standards
handelt, und dieser im Anschluß an dieses Kapitel ausführlich analysiert wird. Für eine detaillierte Beschreibung der einzelnen Verfahren wird deshalb jeweils auf die entsprechenden
Abschnitte in Kapitel 4 verwiesen.
3.3.1
Schlüsselmanagement
Die WPA-Sicherheitsarchitektur erweitert die WEP-Architektur um ein robustes Schlüsselmanagement, das eng mit der Authentifizierung verknüpft ist. Das Konzept der Schlüsselhierarchien wird eingeführt, so daß für die tatsächliche Verschlüsselung und Integritätssicherung nur noch eigens dafür erzeugte temporäre Schlüssel zum Einsatz kommen. Der
Abschnitt 4.2 beschreibt das Schlüsselmanagement für zwei Verschlüsselungsprotokolle –
23
3.4 WEITERE ALTERNATIVEN
darunter auch das TKIP, das in der WPA-Sicherheitsarchitektur zum Einsatz kommt; siehe unten.
3.3.2
Verschlüsselung
Eine Verschlüsselung der Nachrichten ist unter der WPA-Architektur vorgeschrieben. Hierfür kommt das Temporal Key Integrity Protocol (TKIP) zum Einsatz. Es kapselt den
WEP-Verschlüsselungsmechanismus derart, daß fast alle Schwächen beseitigt werden. Dafür kommt ein temporärer Schlüssel und verschiedene Schlüssel-Mix-Funktionen zum Einsatz. Die WEP-Verschlüsselung bleibt zwar erhalten, doch werden alle sicherheitsrelevanten
Schritte bereits vorher durchgeführt. Der genaue Ablauf der Ver- und Entschlüsselung mit
Hilfe von TKIP wird in Abschnitt 4.3.1 gezeigt.
3.3.3
Integrität
Ebenfalls Teil des TKIPs ist das Verfahren zur Integritätssicherung der Nachrichten. Zum
Einsatz kommt ein Message Integrity Code (MIC) in Form des sog. Michael-Algorithmus.
Da dieser aber – trotz seiner Überlegenheit gegenüber dem mangelhaften Integrity Check
Value (ICV) der WEP-Architektur – aufgrund der Leistungsbeschränkung älterer Hardware keine vollständige Sicherheit bieten kann, wird das Konzept der Gegenmaßnahmen
eingeführt: Wenn ein Angriff schon nicht verhindert werden kann, so soll er zumindest erkannt und abgewehrt werden können. Das Michael-Verfahren ist das Thema des Abschnitts
4.4.1.
3.3.4
Authentifizierung
Bei der Verwendung der WPA-Sicherheitsarchitektur auf bestehender 802.11-Hardware
wird die Open-System-Authentifizierung der zugrundeliegenden WEP-Architektur aktiviert, die WEP-Authentifizierungsmaßnahmen also abgeschaltet. Stattdessen wird die Authentifizierung mittels eines anderen IEEE-Standards zur Pflicht: Mit Hilfe des 802.1xStandards als portbasierende Zugangskontrolle in Kombination mit dem Extensible Authentication Protocol (EAP) wird eine gegenseitige Authentifizierung eingeführt. Die Vorstellung der Protokolle erfolgt in den Abschnitten 4.5.1 und 4.5.2. Für den Einsatz in
Firmen-Netzwerken kommen ferner RADIUS-Authentifizierungsserver zum Einsatz; hierzu siehe Abschnitt 4.5.3. Bei kleineren Netzen können stattdessen Preshared Keys (PSK)
verwendet werden. Sie werden im Rahmen des Schlüsselmanagements in Abschnitt 4.2 vorgestellt.
3.4
Weitere Alternativen
Wenngleich die WPA-Sicherheitsarchitektur aufgrund der Kompatibilität mit dem kommenden 802.11i-Standard gewiß die größten Chancen in einem ohnehin durch IEEE 802.11kompatible Geräte dominierten Markt hat, gab es zuvor dennoch Bestrebungen um Alternativen bei der Verbesserung der WEP-Sicherheitsarchitektur, die auch in Produkten
eingesetzt wurden und werden. Diese sind allerdings nicht so umfassend wie die WPASicherheitsarchitektur, sondern setzen nur an den Verschlüsselungsproblemen an. Die wichtigsten zwei Vertreter dabei sind WEPplus und FPK.
24
Letztlich sind die genannten Bestrebungen aber nicht vergebens, denn die Ideen wurden
zum Teil im 802.11i-Standard aufgegriffen und erweitert. So basiert beispielsweise das TKIP
zum Teil auch auf den Verfahren aus WEP2 und dem FPK; siehe auch Abschnitt 4.3.1.
3.4.1
WEPplus
Von Agere Systems wurde in der ORiNOCO Produktreihe Ende 2002 die WEP-Erweiterung
WEPplus eingeführt; vgl. Agere Systems Inc. (2001). Die Erweiterungen der WEPSicherheitsarchitektur beschränken sich allerdings darauf, daß bei der Auswahl des IVs,
der zusammen mit dem geheimen Schlüssel zur Erzeugung des RC4-Schlüsselstroms verwendet wird, die z.B. bei Mann (2003) beschriebenen schwachen Schlüssel ausgeschlossen
werden; siehe auch Abschnitt 2.3.2. Damit zielt die Erweiterung auf die Angreifbarkeit
durch Angriffswerkzeuge wie beispielsweise AirSnort; vgl. AirSnort (PRG). WEPplus ist
somit voll kompatibel zur WEP-Architektur, kann den Sicherheitsvorteil aber nur dann
ausnutzen, wenn beide an einer Übertragung beteiligte Stationen den WEPplus Standard
unterstützen, da die IVs immer vom jeweiligen Sender erzeugt werden. (Dies gilt natürlich
nur für einen Angriff auf genau diese Verbindung. Soll ein ganzes WLAN von der höheren
Sicherheit profitieren, müssen alle angeschlossenen Geräte WEPplus unterstützen.)
3.4.2
FPK
An der gleichen Schwachstelle der WEP-Sicherheitsarchitektur setzt auch das FPKVerfahren von RSA Security (HP) zur Erzeugung von dynamischen WEP-Schlüsseln an;
vgl. RSA Security (2001). Für jedes übermittelte Paket wird unter Verwendung einer speziellen Hashfunktion und eines temporären Schlüssels ein individueller RC4-Schlüsselstrom
generiert. Somit sind Schlüsselwiederholungen ausgeschlossen. Das Verfahren zur Schlüsselerzeugung besteht aus zwei Phasen: In einer ersten Phase wird ein 128 Bits langer temporärer Schlüssel TK (Temporal Key), der beiden Kommunikationspartnern bekannt ist, jeweils
mit der 48 Bits langen Adresse des Senders (TA (Transmitter Address)) vermischt, um zu
erreichen, daß beide Kommunikationspartner mit verschiedenen Schlüsselräumen arbeiten.
Das Ergebnis von Phase eins ist dann ein 128 Bits langer Schlüssel, der in der zweiten
Phase mit einem 16-Bit-IV zu einem 128-Bit-Paketschlüssel vermischt wird und letztlich
anstatt der WEP-Kombination von 24-Bit-IV und 104-Bit-Shared-Key zum Einsatz für die
Erzeugung der RC4-Stromchiffre kommt. Dabei wird darauf geachtet, daß jeder IV nur ein
einziges Mal für einen TK zum Einsatz kommt. Nach 65535 Paketen muß der TK also
gewechselt werden. Mit diesem Vorgehen greift FPK wesentlich weiter als WEPplus, denn
die Wiederholung eines Pärchens von (WEP-)IV und Schlüsselstrom ist fast ausgeschlossen
und somit keine Known-Plaintext-Attacke mehr möglich; vgl. Schmidt (2002)). Doch ist
dieses Verfahren ohne ein sinnvolles Schlüsselmanagement dennoch unbrauchbar, da wegen
des nur 16 Bits langen IVs der TK viel zu oft gewechselt werden muß. Die Probleme bei
der Authentifizierung und der Wahrung der Integrität sind hiermit selbstverständlich auch
noch nicht behoben.
3.4.3
WEP2
Bevor die Arbeit der Task Group i (TGi) des IEEE Früchte in Form des seit letztem Jahr
vorliegenden Drafts des 802.11i-Standards trug, wurde von ihr im übrigen auch ein eigener
25
Versuch verworfen, der die WEP-Sicherheitsarchitektur ablösen sollte: Der von der TGi
anfangs geplante Nachfolger sollte WEP2 heißen und versprach mit einer IV-Länge von
128 Bits und Möglichkeiten zum periodischen Schlüsselwechsel Besserung. Darüber hinaus
sollte zur Authentifizierung auch Kerberos (vgl. Kohl und Neumann (1993)) einsetzbar
sein. Doch dieser Nachfolger wurde schon nach kurzer Zeit wieder verworfen, da nach wie
vor Known-Plaintext-Attacken möglich waren und mit Kerberos sogar ein weiterer, auf der
Verwendung von Wörterbüchern basierender Angriff möglich wurde; vgl. Schmidt (2002).
26
4
Neue Sicherheit
In Kürze soll der neue IEEE 802.11i-Standard verabschiedet werden. Er enthält eine völlig
neue Sicherheitsarchitektur, die endlich eine robuste Sicherheit für WLANs gewährleisten
soll. Von der TGi wurde diese neue Sicherheitsarchitektur deshalb auch Robust Security Network (RSN) getauft. Die Erwartungen an die RSN-Sicherheitsarchitektur sind sehr
hoch, da sie im Grunde alles besser machen muß als es die WEP-Sicherheitsarchitektur derzeit tut, und einige Sicherheitsmechanismen sind bereitzustellen, die im 802.11-Standard
überhaupt noch nicht vorhanden waren. Darüber hinaus muß der neue 802.11i-Standard
auch zum existierenden Standard zumindest teilweise kompatibel sein, um eine stufenweise
Einführung neuer Hardware für die neue Sicherheitsarchitektur zu ermöglichen.
Neben der obligatorischen Ausstattung des Standards mit den nötigen robusten Sicherheitsmechanismen ist es aber auch wichtig, daß in der Praxis möglichst viel automatisch
und vor allem einfach für den Benutzer und den Administrator abläuft. Die Erfahrung
hat gezeigt, daß schlecht zu administrierende oder im Auslieferungszustand deaktivierte
Sicherheitsmechanismen nicht gepflegt bzw. gar nicht erst eingeschaltet werden. Neben der
Technik selbst ist also auch die Anwendbarkeit der Technik ein wichtiges Ziel dieses neuen
Standards.
Der nächste Abschnitt gibt zuerst einen Überblick über die neuen bzw. erweiterten
Sicherheitsmechanismen des IEEE 802.11i-Standards. Anschließend werden die zugrundeliegenden Verfahren und Protokolle im Bezug auf das neu hinzugekommene Schlüsselmanagement und die wichtigsten Sicherheitsbereiche Verschlüsselung, Integritätssicherung
und Authentifizierung eingehender beschrieben. Diese Beschreibung hebt dabei die wichtigsten Details der Verfahren und Änderungen im Vergleich zum ursprünglichen 802.11Standard hervor – für eine noch umfassendere Auseinandersetzung mit den Neuerungen
des 802.11i-Standards sei auf den aktuellen Draft in der Version 7.0 verwiesen; vgl. IEEE
(2003b).
Auch an dieser Stelle ergeht noch einmal der Hinweis, daß die Informationen, die den folgenden Ausführungen zugrundeliegen, nur so aktuell sein können, wie es der zur Zeit vorliegende Draft erlaubt, und deshalb nur unter Vorbehalt auf spätere Gültigkeit wiedergegeben
werden. Die beschriebenen Protokolle und Verfahren könnten sich bis zur Verabschiedung
des 802.11i-Standards durchaus noch in Details ändern. Grundsätzliche Änderungen sind
aber – zumindest in den hier ausführlich beschriebenen Verfahren – nicht zu erwarten.
4.1
RSN-Sicherheitsarchitektur
Die RSN-Sicherheitsarchitektur wird antreten, um die seit der Einführung der WEPSicherheitsarchitektur vorherrschenden Mißstände im Bezug auf die Sicherheit von WLANs
zu beseitigen. Daß es der neue 802.11i-Standard sein wird (oder Teile daraus, wie beispielsweise in WPA), der die Sicherheit in WLANs revolutionieren wird, steht angesichts des
Mangels an Alternativen außer Frage: Es gibt derzeit keine zweite Weiterentwicklung, die
eine ähnlich umfangreiche Basis für die Sicherheit von drahtlosen lokalen Netzwerken bietet
– und das Problem der fehlenden Sicherheit in WLANs ist drängender denn je. Ob jedoch
mit den in der RSN-Sicherheitsarchitektur vorgeschlagenen Maßnahmen eine Sicherheitsstufe erreicht wird, die allen Anforderungen gerecht wird und über Jahre hinaus möglichen
Angriffen standhalten wird, bleibt zu überprüfen.
27
4.1 RSN-SICHERHEITSARCHITEKTUR
Die Sicherheitsarchitektur des 802.11i-Standards hat neben dem primären Ziel der vollständigen Absicherung der Kommunikation in WLANs auch die Vorgabe, eine Weiterverwendung existierender Hardware – zumindest kurzfristig – zu ermöglichen. Der Standard
enthält deshalb zwei verschiedene Basisprotokolle für die Verschlüsselung und Integritätssicherung: Zum einen ein auf dem Advanced Encryption Standard (AES) basierendes Verfahren, das CTR/CBC-MAC Protocol (CCMP). Die Entscheidung für das CCMP als neues
Verfahren für die Verschlüsselung im RSN wurde dabei bereits gefällt, bevor die gravierendsten Sicherheitsprobleme der WEP-Sicherheitsarchitektur bekannt wurden. Es war geplant, daß diese auf AES basierende Lösung WLANs, die die WEP-Sicherheitsarchitektur
verwenden, schrittweise ersetzen sollte. Eine Erweiterung der bestehenden Systeme wurde
ursprünglich gar nicht in Betracht gezogen. Als dann aber schließlich die große Unsicherheit der WEP-Sicherheitsarchitektur offenbar wurde, entstand ein wesentlich drängenderer
Bedarf an sichereren WLAN-Systemen. Deshalb wurde zum anderen das Temporal Key
Integrity Protocol (TKIP) entwickelt und als Alternative zum CCMP in den Standard
aufgenommen.
Oberhalb dieser auf der MAC-Schicht angesiedelten Protokolle, definiert die RSNSicherheitsarchitektur ferner Verfahren für das Schlüsselmanagement und die Authentifizierung. Basis der Authentifizierung bildet der IEEE 802.1x-Standard mit einer portbasierenden Zugangskontrolle. In der Form wie dieser Standard in der RSN-Sicherheitsarchitektur
eingesetzt wird, ermöglicht er in Verbindung mit RADIUS oder dem Extensible Authentication Protocol (EAP) eine Zugangskontrolle sowohl für kleine lokale Netze als auch komplette
Firmennetze; vgl. Eaton (2002). Eine Benutzerauthentifizierung wird durch die Verwendung
von sog. Upper-Layer-Authentifizierungsprotokollen gewährleistet, die entsprechend wiederum oberhalb des 802.1x-Standards im ISO-OSI-Modell angesiedelt sind und zusammen
mit einem Authentifizierungsserver arbeiten. Der 802.11i-Standard stellt eine entsprechende
Schnittstelle zur Verfügung, so daß die Auswahl der Upper-Layer-Authentifizierungslösung
dem Anwender bzw. Administrator überlassen wird. Zu diesen Protokollen gehören beispielsweise das Transport Layer Security (TLS)-Protokoll oder Kerberos. Mit dem ebenfalls
durch diese Protokolle realisierten Schlüsselmanagement und der Benutzerauthentifizierung
bietet die RSN-Sicherheitsarchitektur somit neben den verbesserten Verschlüsselungsprotokollen zwei Funktionalitäten, die in der WEP-Sicherheitsarchitektur bisher gar nicht enthalten waren.
Insgesamt kommen im 802.11i-Standard bis auf das TKIP Protokolle zum Einsatz,
die bereits außerhalb dieses Standards zum Teil schon mehrere Jahre erfolgreich verwendet wurden. Somit stehen die Chancen, keine ähnliche Pleite wie bei der WEPSicherheitsarchitektur zu erleiden, gar nicht schlecht – wenngleich sich mögliche Sicherheitslücken natürlich auch noch nach der Ratifizierung des Standards ergeben können. Die
frühzeitige Einführung des TKIPs und des Authentifizierungsverfahrens für den Infrastrukturmodus im Rahmen der WPA-Sicherheitsarchitektur läßt sich allerdings bereits als ein
erster Erfolg verbuchen; vgl. Burns und Hill (2003).
Die wichtigsten Elemente der RSN-Sicherheitsarchitektur werden in den folgenden Abschnitten dieses Kapitels eingehend vorgestellt. Sie werden aufgeteilt in Mechanismen zur
Verschlüsselung, zur Integritätssicherung und schließlich zur Authentifizierung. Zu Beginn
wird allerdings das Schlüsselmanagement, das eigentlich Teil der Authentifizierungsverfahren ist, analysiert, da die Verschlüsselungsverfahren teilweise darauf zurückgreifen.
28
4.2 SCHLÜSSELMANAGEMENT
4.2
Schlüsselmanagement
Im Gegensatz zur WEP-Sicherheitsarchitektur kommen in der RSN-Sicherheitsarchitektur
sehr viele verschiedene Schlüssel zum Einsatz, die alle Teil einer mehrstufigen Schlüsselhierarchie sind. Um die unterschiedliche Bedeutung der jeweiligen Schlüssel besser zu verstehen,
folgt eine kurzer Überblick über die generellen Funktionen von Schlüsseln.
Schlüssel werden im allgemeinen für zwei verschiedene Zwecke benötigt: Zum einen
dienen sie der Erlangung des Zugriffs auf die Nutzung einer Ressource im Sinne beispielsweise eines Autoschlüssels, zum anderen erfüllen Schlüssel die Aufgabe, die Identität seines Inhabers zweifelsfrei zu beweisen, ähnlich der Funktion eines Ausweises. In der RSNSicherheitsarchitektur werden beide Arten von Schlüsseln verwendet: Ein Benutzer muß
sich zuerst ausweisen, indem er beweist, daß er Kenntnis von einem Geheimnis hat, und
bekommt anschließend die Schlüssel zugeteilt, die es ihm ermöglichen, bestimmte Dienste zu
nutzen. Diese Schlüssel sind temporäre Schlüssel, die nur für die Zeit der jeweiligen Nutzung
des Dienstes Gültigkeit besitzen. Während diese temporären Schlüssel in Echtzeit erzeugt
werden können, muß für den erstgenannten Schlüssel ein Geheimnis zwischen den beteiligten
Parteien vereinbart werden. Da von diesem Schlüssel alle anderen Schlüssel abhängen, muß
bei seiner Erzeugung und Übermittlung besonders sorgfältig vorgegangen werden. Aufgrund
seiner wichtigen Funktion wird dieser Schlüssel auch Master Key genannt. Direkt verwendet
werden sollte so ein Master Key so selten wie möglich. In der RSN-Sicherheitsarchitektur
dient der Master Key deshalb ausschließlich der Erzeugung von temporären Schlüsseln. Im
Vergleich dazu wurde in der WEP-Sicherheitsarchitektur, in der überhaupt kein Schlüsselmanagement existierte, im Grunde ausschließlich dieser Master Key eingesetzt – und dies
auch noch gleichzeitig für die Verschlüsselung und die Authentifizierung; vgl. Edney und
Arbaugh (2003, S. 109 + 110).
Das Schlüsselmanagement muß, um die Schlüssel angemessen zu schützen, zwei Schwierigkeiten meistern: Einerseits muß ein Weg gefunden werden, um zu garantieren, daß die
temporären Schlüssel nicht vorhersagbar und dabei auch immer unterschiedlich sind. Andererseits muß dafür gesorgt werden, daß die an der gesicherten Kommunikation beteiligten
Stationen die gleichen Schlüssel erhalten bzw. erzeugen, ohne daß dies von Dritten untergraben wird.
Wie oben bereits erwähnt, muß eine neue Sicherheitsarchitektur neben der zwingend
nötigen Sicherheit auch eine unkomplizierte Handhabung bieten und wenig Administrationsaufwand erfordern. Dies wird vom RSN eingehalten. Die Arbeit mit den im folgenden
vorgestellten verschiedenen Schlüsseln gestaltet sich für den Administrator demzufolge auch
entsprechend einfach, denn das einzige was für den reibungslosen Betrieb des RSNs vom
Benutzer getan werden muß, ist ggf. die manuelle Vergabe des Master Keys. Alles weitere – also vor allem die Generierung der jeweiligen temporären Schlüssel – übernimmt das
Schlüsselmanagement automatisch.
Das im folgenden beschriebene Schlüsselmanagement ist eigentlich ein Teil der Authentifizierung, zumal hierbei auch die Authentifizierungsprotokolle verwendet werden, doch
da die Schlüssel in allen Verfahren zur Erreichung der Sicherheitsziele eingesetzt werden,
sollen sie bereits an dieser Stelle vorgestellt werden. Dies führt allerdings dazu, daß an
einigen Stellen aus Mangel an vereinzelten Grundlagen keine ausführlichen Beschreibungen
vorgenommen werden können. Weitere Informationen zu diesen Bereichen werden dann in
Abschnitt 4.5 nachgereicht.
29
4.2.1
Schlüsselarten
Neben der Trennung nach Master Key und temporären Schlüsseln ist noch eine zweite Aufteilung der Schlüssel für die Beschreibung des Schlüsselmanagements nötig: Ein
Wireless-LAN ist dafür ausgelegt, Datenaustausch sowohl zwischen jeweils nur zwei Stationen als auch zwischen mehreren Stationen gleichzeitig zu ermöglichen. Entsprechend
dieser Möglichkeiten existieren auch zweierlei Kommunikationsmethoden, die unterschiedliche Schlüssel erfordern.
In der Kommunikation zwischen zwei Stationen (also z.B. einer mobilen Station und
einem AP) kommen sog. Unicast-Datenpakete zum Einsatz. Das Datenpaket wird vom
Sender an genau einen Empfänger gesendet. Sendet eine Station dagegen Daten an mehrere Stationen gleichzeitig, geschieht dies in Form eines Multicast-Datenpaketes. (Sind davon
alle im Netz des Senders befindlichen Stationen betroffen, wird auch von Broadcast gesprochen.) Es liegt auf der Hand, daß diese beiden Kommunikationsmodi verschiedene Schlüssel
benötigen.
Zur sicheren Kommunikation zwischen jeweils zwei Stationen muß ein Schlüssel zum
Einsatz kommen, der ausschließlich genau diesen beiden Stationen bekannt ist. In diesem
Fall wird von paarweisen Schlüsseln gesprochen. Typischerweise betrifft dies die Kommunikation zwischen einer mobilen Station und dem AP. Die Station muß demnach einen
paarweisen Schlüssel speichern, während der AP paarweise Schlüssel für alle angeschlossenen Stationen bereit halten muß.
Im Gegensatz dazu findet die Kommunikation über Multicast innerhalb von sog. Trusted
Groups statt, das heißt einer Gruppe von Anwendern bzw. Stationen, die sich untereinander vertrauen. Damit eine Kommunikation in der Gruppe möglich ist, muß ein Schlüssel
(der Gruppenschlüssel) unter allen Mitgliedern der Gruppe verteilt werden. Die Sicherheit, die durch den kleineren Gruppenschlüssel gewährt wird, ist im Vergleich zur reinen Unicast-Kommunikation geringer, doch ist der Anwendungsbereich für MulticastNachrichten auch eher eingeschränkt und im allgemeinen nicht so sensibel. Zur Anwendung
kommen Multicast-Nachrichten beispielsweise für das Streaming von Video- oder Audiodaten oder für Ticker-Anwendungen. Multicast-Nachrichten werden im übrigen nur vom AP
an die angeschlossenen Clients versendet. Soll von einem Client aus eine Nachricht an die
anderen Gruppenmitglieder gesendet werden, muß dieser Client seine Nachricht zuvor als
Unicast-Nachricht an den AP übermitteln. Somit würde sich der Erfolg eines möglichen
Angriffs auf den Gruppenschlüssel auf das Mithören der Multicast-Nachrichten beschränken.
4.2.2
Schlüsselhierarchien
In der RSN-Sicherheitsarchitektur werden entsprechend der eben beschriebenen Schlüsselarten zwei Schlüsselhierarchien definiert: Die paarweise Schlüsselhierarchie, um den UnicastNetzwerkverkehr zu schützen, und die Gruppenschlüsselhierarchie, um die MulticastNachrichten abzusichern. Diese Schlüsselhierarchien können jeweils auf die Verwendung
zusammen mit einer der beiden Verschlüsselungsverfahren TKIP und CCMP, die in Abschnitt 4.3 beschrieben werden, ausgerichtet sein. Da die Verschlüsselungverfahren zum Teil
mit unterschiedlichen Schlüsseln arbeiten, werden im folgenden jeweils zwei Hierarchien für
paarweise Schlüssel und Gruppenschlüssel vorgestellt.
30
Zuvor aber werden die Methoden beschrieben, mit denen die Zufallszahlen erzeugt werden, auf denen die Schlüsselhierarchien aufbauen.
PRNGs Eine sehr wichtige Grundlage eines Schlüsselmanagements ist die Erzeugung
von Zufallszahlen kryptographischer Qualität mit Hilfe eines Pseudozufallszahlengenerators
(Pseudo-Random Number Generator (PRNG)). Kryptographische Qualität besitzt eine Zufallszahl dann, wenn sie einer perfekten Zufälligkeit unterliegt, es also keine Möglichkeit gibt,
die Grundmenge der Zahlen, aus der die Zufallszahl stammt, in der Analyse einzuschränken.
Jede Zahl der Grundmenge ist gleichwahrscheinlich. Das heißt, bei 2n möglichen Werten
für eine Zufallszahl, die alle die selbe Wahrscheinlichkeit besitzen, würde ein Angreifer im
n
Durchschnitt 2 2 Versuche benötigen, bis er den richtigen Wert erraten hat.
Gute PRNGs, die gleichverteilte Zufallszahlen erzeugen können, sind bereits etabliert
und können bedenkenlos für sicherheitsrelevante Aufgaben eingesetzt werden. Aber aufgrund der Tatsache, daß PRNGs deterministisch vorgehen, also bei gleichen Eingabewerten auch immer den gleichen Strom von Ausgabewerten produzieren, kommt der Auswahl
des Eingabe- bzw. Startwertes besondere Bedeutung zu. Dieser ist anhand möglichst vieler
zufallsabhängiger Daten zu konstruieren, um eine ausreichende Zufälligkeit zu generieren.
Damit wird verhindert, daß über den Startwert des PRNGs auf die möglicherweise damit
erzeugten Zufallszahlen geschlossen werden kann. Wird ein PRNG darüber hinaus nicht
dazu verwendet, einen Strom von Zufallszahlen zu liefern, sondern für jede benötigte Zufallszahl erneut aufgerufen, so kommt dem Startwert eine noch höhere Bedeutung zu. Die
im folgenden Abschnitt vorgestellte Pseudozufallsfunktion verwendet einen PRNG, aus dessen Zahlenstrom Zufallszahlen gebildet werden, doch wird für jeden Aufruf der Funktion
wieder ein neuer Startwert benötigt.
In IEEE (2003b, S. 179 – 181) werden sowohl Methoden vorgestellt, die es erlauben,
auf Softwarebasis als auch durch Einsatz bestimmter Hardware entsprechend gute Startwerte zu ermitteln. Ausführlich untersucht wurden die Möglichkeiten zur Erzeugung von
Zufallszahlen als Basis für Verschlüsselungen bereits in Eastlake et al. (1994).
PRF Während der Berechnungen der einzelnen Elemente der Schlüsselhierarchien kommt
wiederholt die folgende Pseudozufallsfunktion zum Einsatz: Die PRF (Pseudo-Random
Function) ist eine Funktion, die einen n Bits langen Ausgabewert produziert. Als Eingabewerte erhält die Funktion neben der gewünschten Länge der Ausgabe noch drei weitere,
in ihrer Länge nicht näher spezifizierte Parameter. (Sie dürfen lediglich zusammen nicht
die Länge von 128 Bytes übertreffen; vgl. IEEE (2003b, S. 171).) Dies sind ein geheimer Schlüssel K (oder ersatzweise ein Zufallswert), eine Beschreibung A der Funktion, die
mit diesem Aufruf von PRF bezweckt wird (beispielsweise ”Pairwise key expansion”) und
schließlich eine Bytefolge B, die aus der MAC-Adresse besteht, gefolgt von einer Zahl, die
die Zeit repräsentiert bzw. in die ein solcher Zeitwert eingeflossen ist. Die gewünschte Länge
n der Ausgabe kann auch in folgender Schreibweise deutlich gemacht werden. Es gilt:
PRF − n(K, A, B) = PRF (K, A, B, n).
Der Zweck dieser Funktion liegt darin, einen pseudozufälligen Wert vorgegebener Länge
zu konstruieren, der unabhängig von der Länge der Eingabewerte ist, und von dem aus
nicht auf die Eingabewerte geschlossen werden kann. Dafür verwendet die Funktion einen
31
Algorithmus, der neben der Einsatzmöglichkeit als PRNG auch zur Integritätssicherung
verwendet werden kann. Der HMAC (Hashed Message Authentication Code) (vgl. Krawczyk et al. (2001)) in Kombination mit dem Secure Hash Algorithm (SHA)-1 (vgl. NIST
(1993)), kurz HMAC-SHA-1, produziert einen 20 Bytes (160 Bits) langen Hashwert aus
den Eingabedaten. Für HMAC-SHA-1 gilt, daß auch bei der Änderung nur eines Bits des
Eingabewertes ein vollkommen anderer Hashwert erzeugt wird.
Um HMAC-SHA-1 dafür zu nutzen, eine Pseudozufallszahl vorgegebener Länge zu erzeugen, wird die Hashfunktion innerhalb der PRF einfach mehrfach aufgerufen (jeweils mit
einem um 1 inkrementierten Eingabewert). Die Ergebnisse werden dabei solange aneinandergehängt, bis die gewünschte Länge der Zufallszahl erreicht bzw. überschritten ist.
Abbildung 6 zeigt den Algorithmus zur Berechnung der PRF Funktion unter Verwendung von HMAC-SHA-1. Die Funktion (x k y) steht dabei für die Verkettung von x und
y. Die Funktion L(x, y, n) liefert ab dem durch y angegebenen Bit n Bits des Wertes x. Die
0 im Eingabewert für HMAC-SHA-1 kennzeichnet ein Null-Byte.
Die auszugebende Pseudozufallszahl Z wird schließlich aus den ersten n Bits des durch
die wiederholte Ausführung des HMAC-SHA-1 erzeugten Pseudozufallszahlenstroms gebildet.
Eingabe: (K, A, B)≤128 Byte , n1 Byte
Ausgabe: Z n Bit
PRF (K, A, B, n)
R ← NIL
for i = 0 to (n + 159) div 160 do
R ← R k HMAC-SHA-1(K, A k 0 k B k i)
end
Z ← L(R, 0, n)
return Z
Abbildung 6: Pseudozufallsfunktion (PRF)
In den folgenden Abschnitten werden die Funktionen PRF-128, PRF-256, PRF-384 und
PRF-512 eingesetzt. Eine Referenzimplementation der Pseudozufallsfunktion findet sich in
IEEE (2003b, S. 171 – 172).
4.2.3
Paarweise Schlüssel
An der Spitze der Hierarchie der paarweisen Schlüssel steht der 256 Bits lange Pairwise
Master Key (PMK). Bevor die Mechanismen der RSN-Sicherheitsarchitektur zum Einsatz
kommen können, muß dieser wichtigste Schlüssel für die sichere Kommunikation zuerst
auf den beiden beteiligten Stationen eingerichtet werden. Dies kann auf zwei verschiedenen Wegen geschehen: Die erste Möglichkeit ist die Verwendung von sog. Preshared Keys,
was bedeutet, daß der PMK manuell auf dem Access Point und der mobilen Station eingetragen werden muß, ohne daß dabei die Übertragung von Daten über das WLAN nötig
wäre. (Zu den Einzelheiten dieser Alternative siehe weiter unten.) Die zweite Möglichkeit
32
nutzt die Zugangskontrollmechanismen, die durch den IEEE 802.1x-Standard (vgl. IEEE
(2001c)) realisiert werden, und ein Verfahren der Upper-Layer-Authentifizierung, um damit
auf beiden Stationen gleichzeitig den PMK zu erzeugen. Die hierbei eingesetzten Protokolle
werden hier aber nicht in ihren Einzelheiten betrachtet; siehe dazu auch Abschnitt 4.5. Hier
sollen vorerst vor allem die Schlüssel selbst besprochen werden.
In der Hierarchie an zweiter Stelle steht der sog. Pairwise Transient Key (PTK), der
unter Zuhilfenahme eines PRNGs aus dem PMK erzeugt wird. Dieser Schlüssel ist für die
Verwendung des TKIPs 512 Bits lang, für das CCMP nur 384 Bits. Der PTK wird zur
Erzeugung der temporären Schlüssel anschließend in vier (TKIP), bzw. drei (CCMP) je
128 Bits kleine Stücke zerteilt. Die jeweils ersten zwei Schlüssel dienen der Verschlüsselung und der Integritätssicherung von EAPOL (EAP over LAN)-Key-Nachrichten – und
damit der Absicherung der Schlüsselübertragung selbst. (EAPOL ist ein Protokoll, das in
IEEE 802.1x definiert wird und dazu dient, EAP-Nachrichten zu übermitteln. Es wird in
Abschnitt 4.5.2 genauer beschrieben.) Der jeweilige Rest des PTKs wird für das eingesetzte Verschlüsselungsprotokoll zur Absicherung der Datenübertragung verwendet. Für das
TKIP sind dies zum einen der Session Key für den Einsatz bei der Verschlüsselung und
zum anderen der Michael Key für die Integritätssicherung. Im Fall von CCMP kommt ein
einziger Schlüssel für beide Funktionen zum Einsatz.
Abbildung 7 zeigt die Schlüsselhierarchie der paarweisen Schlüssel für den Fall, daß als
Verschlüsselungsmechanismus das TKIP zum Einsatz kommt.
Pairwise Master Key (PMK)256 Bit
?
Pairwise Transient Key (PTK)512 Bit
?
?
128 Bit
EAPOL Encr.K.
?
Session Key128 Bit
128 Bit
EAPOL MIC K.
?
Michael Key64+64 Bit
?
?
Schutz der Schlüsselübertragung
Schutz der Datenübertragung
Abbildung 7: TKIP Pairwise Key – Schlüsselhierarchie
Während der Session Key in voller Länge für die Verschlüsselung im TKIP Verwendung
findet (siehe Abschnitt 4.3.1), liegt für den Michael Key eine Besonderheit vor: Der vom
Michael-Verfahren verwendete Schlüssel (siehe Abschnitt 4.4.1) hat nur eine Länge von 64
Bits. Deshalb wird der im PTK erzeugte 128 Bits lange Schlüssel zweigeteilt: Die erste
Hälfte des Schlüssels wird von den Stationen, die die Authentifizierung innerhalb der Kommunikation übernommen haben, als Michael Key für die zu sendenden Frames verwendet.
Eine solche Station wird im folgenden auch Authentifizierer genannt – es handelt sich dabei im allgemeinen um den AP. Die zweite Hälfte des Schlüssels kommt entsprechend zur
Anwendung, wenn die anfragende Station (im Standard Bittsteller (Supplicant) genannt)
33
Frames an den Authentifizierer sendet. Zur Vereinfachung wird diese Station im folgenden
Client genannt.
Für den Einsatz vom CCMP als Verschlüsselungsmechanismus unter Verwendung von
paarweisen Schlüsseln zeigt Abbildung 8 die entsprechende Schlüsselhierarchie.
Pairwise Master Key (PMK)256 Bit
?
Pairwise Transient Key (PTK)384 Bit
?
?
128 Bit
?
Session/MIC Key128 Bit
128 Bit
EAPOL Encr. Key
EAPOL MIC Key
?
?
Schutz der Schlüsselübertragung
Schutz der Datenübertragung
Abbildung 8: CCMP Pairwise Key – Schlüsselhierarchie
Der dritte temporäre Schlüssel, der aus dem PTK für das CCMP gewonnen wird, kommt
sowohl für die Verschlüsselung als auch für die Integritätssicherung im CCMP zum Einsatz.
Siehe hierzu die Abschnitte 4.3.2 und 4.4.2.
Pairwise Master Key Wie bereits erwähnt wurde, kann die Einrichtung des PMKs auf
zwei Wegen geschehen. Die erste Möglichkeit der Preshared Keys ist im Grunde nur in kleinen Netzwerken praktikabel. Dort kann der PMK vom Administrator oder dem Benutzer
der mobilen Station von Hand eingetragen werden. Aber auch gerade in der praktischen
Anwendung zeigt sich in dieser Form der Schlüsseleinrichtung ein Problem: Die Schlüssel,
die auf diesem Wege verwendet werden, sind im allgemeinen relativ schwach, da anstatt beliebiger 256-Bit-Schlüssel eher 32-Byte-Worte (oder sogar kürzere) eingetragen werden, die
der natürlichen Sprache entstammen. Dies ist ein weiterer Grund dafür, daß in einer Sicherheitsarchitektur möglichst viel automatisch ablaufen sollte. Zu einer im 802.11i-Standard
vorgeschlagenen Methode, für die Erzeugung der Preshared Keys tatsächlich natürlichsprachliche Paßwörter einzusetzen, siehe den nächsten Abschnitt.
Die automatisierte Methode, um beide Stationen mit dem Pairwise Master Key auszustatten, basiert auf der Verwendung des IEEE 802.1x-Standards und einem Upper-LayerAuthentifizierungsprotokoll. Während der Authentifizierung eines Clients am Authentifizierungsserver wird auf beiden Seiten der PMK erzeugt. Deshalb wird bei dieser Art der
Schlüsselerzeugung auch von serverbasierenden Schlüsseln gesprochen. Anschließend wird
der PMK vom Authentifizierungsserver an den AP weitergegeben. Damit steht auf beiden
miteinander kommunizierenden Stationen der PMK zur Erzeugung des PTKs und damit
der temporären Schlüssel bereit.
34
Preshared Keys Da ein PMK eine Länge von 256 Bits bzw. 32 Bytes hat, eignet
er sich nur sehr schlecht, um manuell in Stationen eingetragen zu werden. Beispielsweise
für den Fall, daß ein Administrator einem neuen Nutzer den PMK per Telefon durchgeben
will, damit ihn der Benutzer selbst in seiner Station eintragen kann, ist ein beliebiger
Zeichenstrom sicher nicht praktikabel. Um dies zu vereinfachen, wurde in IEEE (2003b, S.
177 + 178) ein Verfahren vorgeschlagen, mit dem natürlichsprachliche Paßwörter in PMKs
gewandelt werden können, um somit auch Laien den Umgang mit der Sicherheitstechnik
zu ermöglichen – allerdings zu dem hohen Preis der Sicherheit selbst. Denn ein einfaches
Paßwort hat im Gegensatz zu einem tatsächlich zufälligen Schlüssel, der die Grundmenge
von 2256 verschiedenen Schlüsseln ausnutzt, nur eine eine vergleichbare Sicherheit von 2,5
Bits pro Buchstaben. Die TGi weist deshalb auch darauf hin, daß eine Paßwortlänge unter
20 Zeichen kaum Schutz vor Angriffen bietet und daß diese Art der PMK-Erzeugung nur
eingesetzt werden sollte, wenn es keine praktikable Möglichkeit gibt, sicherere Schlüssel zu
verwenden.
Es wird in IEEE (2003b, S. 178 + 179) eine Referenzimplementation für ein Verfahren
zur einheitlichen Umwandlung eines Paßwortes in einen PMK angegeben, das im Gegensatz
zu den Keygeneratoren, die in WEP-Hardware eingesetzt wurden (siehe Abschnitt 2.3.2)
tatsächlich zufällige Schlüssel generiert. Das Verfahren basiert auf der Password Based Key
Derivation Function (PBKDF) 2 aus dem Public-Key Cryptography Standard (PKCS) 5,
Version 2.0 von RSA Security (1999) und berechnet aus dem Paßwort, der SSID und der
SSID-Länge mittels Hashings den 256-Bit-PMK. Die Paßwörter müssen dabei zwischen 8
und 63 ASCII-Zeichen enthalten. (Da nur Zeichen mit der ASCII-Kodierung 32 bis 126
(dezimal) erlaubt sind, benötigt ein Buchstabe nur 4 Bits.) 63 ASCII-Zeichen wurden als
maximale Länge gewählt, um den Unterschied zum vollständigen, 32 Bytes langen PMK
zu wahren.
In Abhängigkeit von der Länge n (Anzahl der Buchstaben) des Paßwortes liefert das
angegebene Verfahren eine sicherheitsrelevante Schlüssellänge von 2, 5 · n + 12; vgl. IEEE
(2003b, S. 177).
Serverbasierte Schlüssel Im Gegensatz zu den Preshared Keys wird bei dieser zweiten Methode die Schlüsselgenerierung ohne das Einwirken des Benutzers vorgenommen, was
aufgrund der oben besprochenen Probleme im allgemeinen zu wesentlich besseren Schlüsseln
führt. Der Name der serverbasierten Schlüssel kommt durch die Verwendung des zweistufigen Authentifizierungsmechanismus zustande, der in Abschnitt 4.5 genauer beschrieben
wird. An dieser Stelle wird der Prozeß der automatischen Schlüsselerzeugung deshalb nur
prinzipiell erörtert.
Bei der im IEEE 802.11i-Standard verwendeten Authentifizierung sind drei Rollen zu
identifizieren: Zu dem bereits bekannten Authentifizierer und dem Client kommt ein sog.
Authentifizierungsserver (AS). Dieser übernimmt die eigentliche Authentifizierung, während dabei dem Authentifizierer eher die Rolle der Zugangskontrollinstanz zukommt. Anfragen, die von einem Client an einen Authentifizierer gerichtet werden, läßt dieser vom AS
bearbeiten und handelt anschließend im Sinne der Antwort des Authentifizierungsservers.
Hierdurch wird erreicht, daß die Authentifizierung zentral (eben auf dem AS, der somit
auch mehrere APs bedienen kann) erfolgt.
Auf dem AS können verschiedene sog. Upper-Layer-Authentifizierungsprotokolle zum
35
Einsatz kommen, wovon einige die Eigenschaft besitzen, schlüsselerzeugend zu sein. Das
bedeutet, daß sie bei der Durchführung der Authentifizierung eines Clients aus dem dafür
nötigen Zufallszahlenmaterial den PMK erzeugen können. Zu diesen Protokollen gehören
z.B. das TLS (Transport Layer Security)-Protokoll oder Kerberos; siehe dazu Abschnitt
4.5.4. Als Kommunikationsprotokoll bei der Aushandlung des PMKs wird dabei das Extensible Authentication Protocol (EAP) eingesetzt; siehe Abschnitt 4.5.2.
Da die Authentifizierung zwischen dem Client und dem Authentifizierungsserver stattfindet, muß der PMK, nachdem er zugleich auf dem Client und dem Server erzeugt wurde, noch vom Server zum AP übertragen werden, damit er dort für die Erstellung des
PTK und der nötigen temporären Schlüssel verwendet werden kann. Im Gegensatz zur
WPA-Sicherheitsarchitektur, in der die Verwendung des RADIUS (siehe auch Abschnitt
4.5.3) für die Übertragung des PMKs zum AP vorgeschrieben ist, wird für die RSNSicherheitsarchitektur hier nur das EAP als Kommunikationsprotokoll festgelegt – als Authentifizierungsserver kann auch ein anderer Service verwendet werden. Vereinfacht wird
dieser Schritt, wenn der Authentifizierungsserver direkt im AP realisiert wurde, was vor
allem in neuerer Hardware für kleine lokale Netze immer häufiger anzutreffen ist.
Die während der Authentifizierung vorgenommene Schlüsselerzeugung hängt auch von
dem letztlich eingesetzten Protokoll der Upper-Layer Authentication (ULA) ab. Da diese
aber nicht Teil des IEEE 802.11i-Standards ist, wird hier auf eine detaillierte Beschreibung
des Ablaufs verzichtet; siehe dazu auch Abschnitt 4.5.4.
Temporäre Schlüssel Nachdem der PMK auf beiden Stationen abgelegt wurde, können der Pairwise Transient Key und daraus anschließend die temporären Schlüssel für die
tatsächliche Kommunikation erstellt werden. Die Erzeugung des PTK wird gemeinsam von
beiden Stationen durchgeführt. Während eines 4-Way-Handshakes zwischen den Stationen
erzeugen beide Stationen Pseudozufallszahlen und tauschen sie aus. Aus diesen Zahlen und
weiteren Daten (siehe unten) wird daraufhin auf beiden Stationen ein identischer PTK berechnet, der entsprechend der obigen Beschreibungen für das TKIP und das CCMP in die
benötigten temporären Schlüssel aufgeteilt wird.
Der PTK unterscheidet sich zwischen dem TKIP und dem CCMP nur durch die Anzahl
der zu generierenden Schlüssel, der Ablauf der Erzeugung ist dagegen gleich. Bevor der
eigentliche Handshake durchgeführt wird, erstellen beide Parteien jeweils einen sog. NonceWert. Nonce steht dabei für einen Wert, der für den Bereich, in dem er eingesetzt wird,
eindeutig bzw. einmalig ist. Es gilt also für die beiden von den Stationen erzeugten Werte,
daß sie weder untereinander gleich sind, noch daß sie gleich einem Nonce-Wert sind, der
auf einer der Stationen für die Erzeugung der temporären Schlüssel zur Kommunikation
mit einer dritten Station erzeugt wird. Und dies gilt solange, wie kein Wechsel des PMKs
vorgenommen wird.
Es sei hier angemerkt, daß es sich bei den Nonce-Werten tatsächlich um Pseudozufallszahlen handelt, für die immerhin die theoretische Möglichkeit besteht, zufällig eben doch
den gleichen Wert zu besitzen. Die Wahrscheinlichkeit aber, bei z.B. 10000 mittels eines
guten PRNGs erzeugten, 256 Bits langen Nonce-Werten auch nur ein Mal den gleichen
Nonce-Wert zu erhalten, liegt laut Edney und Arbaugh (2003, S. 225) bei etwa 10−70 . Es
kann also ohne weiteres angenommen werden, daß alle erzeugten Nonce-Werte unterschiedlich sind.
36
Zur Unterscheidung wird der auf der Seite des Authentifizierers erzeugte Wert ANonce
genannt, der auf der Seite des Clients SNonce (für Supplicant). Die Erzeugung der 256
Bits langen Nonce-Werte ist im Standard nicht fest vorgeschrieben. Um aber die oben
beschriebenen Eigenschaften von Nonce-Werten einzuhalten, schlagen Edney und Arbaugh
(2003, S. 224 + 225) in einem etwas vereinfachten Verfahren (im Vergleich zu dem in IEEE
(2003b, S. 180) beschriebenen Algorithmus) vor, die bereits vorgestellte PRF-256 Funktion
hierfür einzusetzen. Für die Erzeugung der beiden Nonce-Werte kommen dabei jeweils eine
von der Station nach einer oder mehreren der in Eastlake et al. (1994) vorgeschlagenen
Methoden ermittelte Zufallszahl zum Einsatz. Diese weisen dementsprechend eher keine
kryptographische Qualität auf. Der String ”Init Counter” und eine Verkettung der eigenen
MAC-Adresse mit der Netzzeit werden ebenfalls als Parameter der PRF-256 verwendet. In
der folgenden allgemeinen Berechnungsvorschrift ist für den SNonce- bzw. ANonce-Wert
jeweils die entsprechende MAC-Adresse zu verwenden.
Nonce = PRF-256(Zufallszahl,”Init Counter”, MAC k Zeit)
Der Erzeugung der Nonce-Werte folgen die vier Schritte des Handshakes, die jeweils
das Senden einer EAPOL-Key-Nachricht beinhalten. (Zu EAPOL siehe Abschnitt 4.5.2.)
Die Nonce-Werte werden dabei jeweils zur anderen Station übertragen, damit anschließend auf beiden Stationen der PTK berechnet werden kann. Darüber hinaus dient der
4-Way-Handshake im Fall der Verwendung von serverbasierten Schlüsseln gleichzeitig der
Authentifizierung des PMKs.
1. Authentifizierer −→ Client
Die erste Nachricht des Handshakes wird vom Authentifizierer an den Client gesendet
und beinhaltet lediglich den ANonce-Wert. Der Wert wird dabei ungeschützt übertragen, was aber nicht weiter bedenklich ist. Sollte ein Angreifer den Wert ändern
können, wird der Handshake lediglich nicht erfolgreich beendet werden können, ohne weiteren Schaden anzurichten. Hat der Client diesen Wert empfangen, kann er
zusammen mit dem PMK, dem eigenen SNonce-Wert, der MAC-Adresse des Senders und seiner eigenen MAC-Adresse den PTK und damit die temporären Schlüssel
berechnen. (Zu der genauen Berechnung siehe unten.)
2. Client −→ Authentifizierer
Damit der Authentifizierer ebenfalls den PTK berechnen kann, benötigt dieser wiederum den SNonce-Wert des Clients. Dieser wird zwar in der entsprechenden Nachricht auch unverschlüsselt übertragen, doch wird hier mit Hilfe des zuvor berechneten
EAPOL MIC Schlüssels ein Integritätscheck mit übermittelt. Nach der Übertragung
der Nachricht kann der Authentifizierer nun seinerseits die benötigten temporären
Schlüssel berechnen (siehe unten) – unter ihnen auch der EAPOL MIC Key. Mit
diesem kann er anschließend überprüfen, ob der erhaltene SNonce-Wert auch unverfälscht übertragen wurde. (Sollte bereits bei der Übertragung des ANonce-Wertes ein
Fehler aufgetaucht sein, so wird auch dieser bei der Prüfung des MICs offenbar.) Wird
der MIC als korrekt identifiziert, kann der Authentifizierer sicher sein, daß der Client
in Kenntnis des gemeinsamen PMKs ist.
Der Authentifizierer schickt nun wiederum eine durch einen MIC gesicherte Nachricht
37
an den Client, in der er ihm mitteilt, daß die Aktivierung der temporären Schlüssel
vorgenommen werden kann. Die Nachricht enthält darüber hinaus den Initialisierungswert (normalerweise 0) für die Sequenznummer der zukünftig zu übertragenden
MPDUs (MAC Protocol Data Unit); siehe dazu auch die Abschnitte 4.3.1 und 4.3.2.
Im letzten Schritt des Handshakes bestätigt der Client dem Authentifizierer wiederum
nur unter Verwendung des MICs die erfolgreiche Schlüsselerzeugung und aktiviert
anschließend die Verschlüsselung für diese Verbindung. Nach dem Empfang dieser
Nachricht (und entsprechender Prüfung des MICs) nimmt auch der Authentifizierer
seine temporären Schlüssel in Betrieb.
Nach der erfolgreichen Ausführung dieses Handshakes sind beide Stationen im Besitz
der nötigen temporären Schlüssel und haben die Verschlüsselung aktiviert. Das heißt, eine
sichere Kommunikationsverbindung wurde hergestellt. Da im übrigen der EAPOL MIC Key
immer aus dem aktuellen PMK gebildet wird, kann im 4-Way-Handshake keine ReplayAttacke angewendet werden.
Die eigentliche Berechnung des PTKs, aus dem dann anschließend die temporären
Schlüssel entnommen werden, geschieht wiederum unter Verwendung der PRF. Durch den
Einsatz von PRF-512 (für das TKIP), bzw. PRF-384 (für das CCMP) wird der nur 256 Bits
lange PMK auf die für den PTK benötigte Länge von n = 512 bzw. n = 384 Bits erweitert.
Die MAC-Adressen der beiden Stationen werden dabei ebenso wie ihre Nonce-Werte in aufsteigend sortierter Reihenfolge zu einem Parameter der PRF verkettet. (Die Nonce-Werte,
die selbst durch eine PRF erzeugt wurden, dienen also selbst wieder der Initialisierung
für einen PRF-Aufruf.) In beiden PRF-Berechnungen kommen darüber hinaus der PMK
und ein Textstring, der kennzeichnet, daß es sich um die Erweiterung des PMK zum PTK
handelt, als Parameter zum Einsatz.
PTK = PRF-n(PMK,”Pairwise key extension”, MAC1 k MAC2 k Nonce1 k Nonce2)
Die vier bzw. drei temporären Schlüssel (EAPOL Encryption Key, EAPOL MIC Key
für beide Protokolle, Session Key und Michael Key für das TKIP und Session/MIC Key
für das CCMP) erhalten die Stationen durch einfaches Aufteilen des PTK in jeweils 128
Bits lange Teilschlüssel.
Im Anschluß an die Etablierung der paarweisen temporären Schlüssel kann die Erstellung und Verteilung des Gruppenschlüssels unter Verwendung der bereits existierenden
sicheren Verbindung erfolgen.
4.2.4
Gruppenschlüssel
Analog zum Pairwise Master Key bildet der nur 128 Bits lange Group Master Key (GMK)
den Kopf der Hierarchie der Gruppenschlüssel. Die Verteilung desselben gestaltet sich wesentlich einfacher als die des PMKs und wird ausschließlich vom AP vorgenommen. Das
heißt, daß auch die Erstellung des Schlüssels ohne Mitwirken des Clients erfolgt; hierzu
siehe unten.
38
Dem GMK folgt in der Hierarchie entsprechend der Abfolge für die paarweisen Schlüssel
der Group Transient Key (GTK). Er besitzt bei der Verwendung des TKIPs eine Länge
von 256 Bits, für das CCMP sogar nur 128 Bits, da nur zwei temporäre 128-Bit-Schlüssel
im TKIP bzw. ein temporärer 128-Bit-Schlüssel im CCMP benötigt werden. Die Erstellung
von EAPOL-Schlüsseln entfällt hier, denn alle Nachrichten, die mit der Schlüsselerzeugung
bzw. dem Schlüsseltransfer zu tun haben, werden nur mit Hilfe der paarweisen Schlüssel
abgewickelt.
Abbildung 9 zeigt die Schlüsselhierarchie, die beim Einsatz vom TKIP als Verschlüsselungsmechanismus unter Verwendung von Gruppenschlüsseln erzeugt wird.
Group Master Key (GMK)128 Bit
?
Group Transient Key (GTK)256 Bit
?
?
128 Bit
Michael Key128 Bit
Session Key
?
Schutz der Multicast-Datenübertragung
Abbildung 9: TKIP Group Key – Schlüsselhierarchie
Die Aufteilung des GTKs in die Schlüssel zur Verschlüsselung und Integritätssicherung
der Datenübertragung entspricht damit dem Vorgehen beim PTK. Die Schlüsselhierarchie
für den Einsatz vom CCMP als Verschlüsselungsmechanismus unter Verwendung von Gruppenschlüsseln zeigt Abbildung 10.
Group Master Key (GMK)128 Bit
?
Group Transient Key (GTK)128 Bit
?
Session/MIC Key128 Bit
?
Schutz der Multicast-Datenübertragung
Abbildung 10: CCMP Group Key – Schlüsselhierarchie
39
Auch der Gruppenschlüssel für das CCMP vereint die Funktionen der Verschlüsselung
und der Integritätsicherung von Datenübertragungen in einem einzigen 128-Bit-Schlüssel.
Group Master Key Für die Bereitstellung des GMK muß bei weitem kein so großer Aufwand betrieben werden wie im Fall des PMK. Er muß nur auf der Seite des APs erzeugt
werden und bedarf dafür keiner Informationen der Clients. Da zum Zeitpunkt der Erzeugung bereits eine sichere Verbindung zu allen Clients besteht, ist auch die anschließende
Übertragung des GTKs an die Clients einfacher.
Da der GMK nur für die Sicherung der Datenübertragung eingesetzt wird und keinerlei
Authentifizierungsaufgaben übernimmt, ist es nicht nötig, ihn an bestimmte Daten des APs
zu binden. Die Konstruktionsvorschrift für den 256 bzw. 128 Bits langen GMK ist daher
entsprechend einfach: Es ist lediglich eine Zufallszahl von kryptographischer Qualität der
entsprechenden Länge zu erzeugen. Die jeweiligen Verfahren für (Pseudo-)Zufallszahlen
dieser Eigenschaft wurden in Abschnitt 4.2.2 bereits besprochen.
Temporäre Schlüssel Die Erzeugung des GTKs aus dem GMK geschieht auf dem AP
wiederum unter Verwendung der bekannten Pseudozufallsfunktion. Auch hier werden für
den Einsatz der verschiedenen Verschlüsselungsprotokolle unterschiedliche Längen des GTK
benötigt. So kommt für den TKIP GTK die PRF-256 zum Einsatz, während für den CCMP
GTK nur die PRF-128 benötigt wird. Sowohl beim GMK des TKIPs mit n = 256 Bits
als auch für den des CCMPs mit n = 128 Bits bleibt die Länge für den GTK gleich.
Neben dem GMK und der Kennzeichnung, daß es sich hier um die Erweiterung des GMK
zum GTK handelt, kommen die MAC-Adresse des APs und eine weiterer Nonce-Wert als
Parameter zum Einsatz. Für den Nonce-Wert (hier GNonce bezeichnet) kann die gleiche
Konstruktionsvorschrift eingesetzt werden, die bereits bei den Nonce-Werten im 4-WayHandshake der paarweisen Schlüssel zur Anwendung kam:
GTK = PRF-n(GMK,”Group key extension”, MAC Authentifizierer k GNonce)
Während der 4-Way-Handshake für die Erzeugung der temporären paarweisen Schlüssel
ohne irgendeine existierende Sicherung durchgeführt werden mußte, kann beim Gruppenschlüssel die bereits bestehende Absicherung durch den PTK genutzt werden. Der nötige
Handshake zur Verteilung des GTKs benötigt deshalb auch nur zwei Nachrichten:
In der ersten Nachricht sendet der Authentifizierer den bereits erstellten GTK (256
Bits für das TKIP und 128 Bits für das CCMP) in einer EAPOL-Key-Nachricht
(Verschlüsselt durch den EAPOL Encryption Key und abgesichert durch den EAPOL
MIC Key) an den Client.
Hat der Client die Nachricht empfangen und ggf. nach Trennung des GTKs in Session Key und Michael Key die bzw. den Gruppenschlüssel (Session/MIC Key im Fall
des CCMP) lokal installiert, sendet er eine ebenfalls abgesicherte und verschlüsselte Bestätigung an den Authentifizierer. Der Authentifizierer aktiviert daraufhin die
Verschlüsselung auf der Basis des verteilten Gruppenschlüssels.
40
Nach diesem kurzen Handshake ist der verschlüsselte Empfang von Multicast-Nachrichten durch den Client möglich.
Das Verfahren für die Schlüsselgenerierung (sowohl der paarweisen Schlüssel als auch der
Gruppenschlüssel) beim Anmelden am Netz ist somit bekannt. Es bleibt, wie der nächste
Abschnitt zeigt, zu klären, welche Maßnahmen durch das Verlassen des Netzes ausgelöst
werden.
4.2.5
Schlüsselwechsel
Verläßt ein Client das Netz, so braucht sein paarweiser Schlüssel nur auf dem AP gelöscht
werden. Der Client sendet dazu eine Nachricht an den den AP, in der er mitteilt, daß er das
Netz verlassen will. Der AP stoppt daraufhin das Senden aller Nachrichten an den Client
und entfernt den paarweisen Schlüssel. Beim erneuten Anmelden des Clients wird ein neuer
paarweiser Schlüssel erzeugt.
Beim Gruppenschlüssel ergibt sich allerdings ein Problem: Auch nach dem Abmelden
vom Netz kann der Client noch Multicast-Nachrichten empfangen und entschlüsseln. Um
auch das zu verhindern, muß also der Gruppenschlüssel für alle Stationen im Netz gewechselt werden. Aufgrund der Tatsache, daß der Schlüssel allein vom AP erstellt und verteilt
wird, ist der Aufwand vergleichsweise gering, doch bei hoher Fluktuation der Clients im
Netz könnte dies eine nicht unerhebliche Beeinträchtigung des Multicast-Verkehrs bedeuten.
Denn es stellt sich die Frage, wann die Gültigkeit vom alten auf den neuen Gruppenschlüssel wechseln soll. Geschieht dies, bevor alle Clients den neuen Schlüssel haben, sind die
Clients, die noch den alten Schlüssel verwenden, vom Multicast-Empfang abgeschnitten.
Im gegenteiligen Fall würden alle Clients, die den neuen Schlüssel bereits erhalten haben,
solange von der Multicast-Kommunikation ausgeschlossen sein, bis der letzte Client den
neuen Schlüssel erhalten hat.
Zur Lösung dieses Dilemmas wird eine Eigenschaft der WEP-Sicherheitsarchitektur ausgenutzt, die in dieser Architektur selbst zuvor kaum genutzt wurde: In dieser wurde vorgesehen, daß bis zu vier verschiedene Schlüssel gespeichert werden können, die durch eine
Schlüssel-ID (KID) identifiziert werden (siehe auch Abschnitt 2.3). Der auf einem Client
gespeicherte paarweise Schlüssel besitzt bereits die KID 0. So bleibt Platz für bis zu drei
verschiedene Gruppenschlüssel. Der AP kann also einen neuen Gruppenschlüssel verteilen, während er Multicast-Nachrichten weiterhin unter Verwendung des alten Schlüssels
versendet. Erst wenn der letzte Client den neuen Schlüssel erhalten hat, verschlüsselt der
AP alle weiteren Multicast-Nachrichten mit dem neuen Schlüssel und deaktiviert den alten
Schlüssel. Damit wird erreicht, daß vor allem für Multicast prädestinierte Anwendungen
wie z.B. Video- oder Audio-Streaming durch einen Schlüsselwechsel nicht beeinträchtigt
werden.
4.2.6
Mischbetrieb
Speziell zu Beginn der Einführung von Geräten, die auf der Basis des 802.11i-Standards
arbeiten, wird häufig der Fall anzutreffen sein, daß nicht nur das CCMP in einem Netz
zur Anwendung kommt, sondern gleichzeitig auch ältere Geräte darin vertreten sind, die
auf die Verwendung des TKIPs angewiesen sind. Für einen modernen AP sollte dies im
Bezug auf die PMKs keine Schwierigkeit darstellen: Der AP erkennt selbsttätig das vom
41
4.3 VERSCHLÜSSELUNG
Client verwendete Protokoll und wendet die jeweils nötige Ver- und Entschlüsselung an.
Probleme allerdings bereitet das Senden von Multicast-Nachrichten. Wenn diese vom AP
aus an alle Clients gesendet werden sollen, muß diese Nachricht einheitlich verschlüsselt
sein, andernfalls müßte die Nachricht zweifach unter der Verwendung der verschiedenen
Verschlüsselungen gesendet werden, womit sie die Multicast-Eigenschaft verlieren würde.
Einziger Ausweg ist die Vereinbarung, in einem gemischten Netz als Verschlüsselungsverfahren für Multicast-Nachrichten für alle Clients das TKIP vorzuschreiben, auch wenn teilweise
das CCMP für die paarweise Verschlüsselung zur Anwendung kommt.
Wird jedoch in einem Netz bereits das CCMP für die Verschlüsselung von MulticastNachrichten verwendet, so ist der Einsatz des TKIP als Verschlüsselungsprotokoll auch
für die paarweise Kommunikation im Netz nicht möglich. Unter welchen Umständen ein
Wechsel des Betriebsmodus vorgenommen wird, um auch ältere Hardware in diesem Netz
zu betreiben, hängt von dem jeweiligen AP und der zugrundeliegenden Sicherheitspolitik
am Einsatzort ab.
4.3
Verschlüsselung
Der IEEE 802.11i-Standard definiert zwei Verschlüsselungs- und Integritätsprotokolle,
TKIP (Temporal Key Integrity Protocol) und CCMP (CTR/CBC-MAC Protocol). Während das TKIP nur eine Erweiterung des Verschlüsselungsmechanismus aus der WEPSicherheitsarchitektur darstellt und im übrigen auch auf älterer Hardware nachrüstbar ist,
basiert die Verschlüsselung bei CCMP bereits auf dem Advanced Encryption Standard.
Das TKIP ist schwächer und wird daher im Standard auch ausdrücklich nur als Option für
den gemeinsamen Betrieb von RSN- und nicht-RSN-Hardware vorgeschlagen. Die Implementierung des TKIPs ist jedoch nicht vorgeschrieben, um der RSN-Sicherheitsarchitektur
zu entsprechen. Einzig obligatorisch und damit das wichtigste Verschlüsselungsprotokoll
für RSN ist das CCMP; vgl. IEEE (2003b, S. 45). In IEEE (2002b) wurde auch noch ein
drittes Protokoll beschrieben, das ebenso wie das CCMP auf dem AES basierte. Das Wireless Robust Authenticated Protocol (WRAP) hatte gegenüber dem CCMP sogar noch
den Vorteil, neben der Verschlüsselung gleichzeitig die Integritätssicherung der Nachrichten
zu ermöglichen. (Im CCMP werden dafür zwei verschiedene Mechanismen bemüht.) Das
Protokoll wurde allerdings von der TGi wieder verworfen, da nicht geklärt werden konnte,
ob für den verwendeten Offset Codebook (OCB)-Mode, auf dem die Verschlüsselung im
WRAP basiert, ggf. später Lizenzgebühren zu zahlen gewesen wären.
In den folgenden Abschnitten wird die Funktionsweise der beiden Verschlüsselungsmethoden eingehender beschrieben. Es wird dabei ersichtlich, daß es aufgrund der HardwareRestriktionen bei der Entwicklung des TKIPs wesentlich leichter war, ein völlig neues Verschlüsselungssystem wie das CCMP zu entwickeln, das im Gegensatz zum TKIP keinerlei
zusätzliche Beschränkungen zu beachten hatte; vgl. auch Edney und Arbaugh (2003, S. 231
– 234). Die Integritätssicherungsmaßnahmen der beiden Protokolle werden anschließend in
Abschnitt 4.4 besprochen.
4.3.1
TKIP
Die Aufnahme vom TKIP in den 802.11i-Standard geschah aus reinen Kompatibilitätsgründen zu bereits existierender, auf dem 802.11-Standard basierender Hardware. Die Nutzung
42
des TKIPs auf RSN-Hardware soll deshalb auch ausschließlich auf den Mischbetrieb beschränkt sein.
Das TKIP wurde als Verbesserung der WEP-Sicherheitsarchitektur entwickelt und mußte vor allem der Anforderung genügen, auf bestehender Hardware nachrüstbar zu sein.
Deshalb wird beim TKIP zwangsläufig WEP verwendet, allerdings erweitert und umgeben
durch neue Funktionen, die die Schwächen von WEP ausgleichen sollen; vgl. IEEE (2003b,
S. 46). Das TKIP bietet dabei für alle bisher bekannten Schwächen Verbesserungen:
• Die Integrität von Nachrichten wird mittels einer Checksumme auf Nachrichten-Ebene
abgesichert statt wie bisher auf Paket-Ebene und bietet so einen Schutz gegen aktive
Angriffe (siehe hierzu Abschnitt 4.4.1).
• Da aufgrund der Restriktionen durch die weiterhin zu verwendende WEP-Sicherheitsarchitektur auch diese Checksumme keinen vollkommenen Schutz vor Angriffen bieten
kann, wurden für den Fall einer erfolgreichen Attacke Gegenmaßnahmen vorgesehen
(siehe auch hierzu Abschnitt 4.4.1).
• Die Konstruktion des IV wird verändert, so daß die bisher möglichen schwachen
Schlüssel verhindert werden. Dies wird durch die Verwendung einer längeren Sequenznummer ermöglicht, die auch in die Verschlüsselung mit eingeht. Die Sequenznummer
wird dabei im WEP-IV und darüber hinaus im erweiterten IV (EIV (Extended IV))
übertragen.
• Jeder übertragene Frame wird mit einem eigenen Schlüssel (Per-Packet Key (PPK))
abgesichert, statt wie bei WEP einen statischen Schlüssel zu verwenden.
• Und schließlich führt das TKIP – vor allem in Verbindung mit den Gegenmaßnahmen
– die Verwendung eines Schlüsselmanagements (vgl. Abschnitt 4.2) ein, was bei WEP
überhaupt nicht vorgesehen war.
Daß dies in Anbetracht der nur auf WEP ausgelegten Rechenleistung der Access Points
zu Engpässen führen kann, liegt auf der Hand; vgl. Walker (2002b). Wie das TKIP es
aber dennoch schafft, die gesteckten Sicherheitsziele auf der vorhandenen Plattform zu
erreichen, zeigen die folgenden Abschnitte. Neben der Beschreibung des geänderten Aufbaus
des MAC-Frames werden sowohl der Verschlüsselungs- als auch der Entschlüsselungsablauf
betrachtet.
Verschlüsselung Als Basis des gesamten Verfahrens dienen zwei vom Pairwise Master
Key oder Group Master Key abgeleitete temporäre 128 Bit Schlüssel, von denen einer
(TK oder Session Key) zur Verschlüsselung des Datenverkehrs eingesetzt wird und der
andere (Michael Key) die Datenintegrität sichert. Zu der Erzeugung dieser Schlüssel siehe Abschnitt 4.2. Im folgenden ist vor allem der zur Verschlüsselung benötigte TK von
Bedeutung.
Neben den beiden Schlüsseln findet auch die zu übertragende Nachricht (MSDU) Eingang in den Verschlüsselungsablauf, den Abbildung 11 schematisch zeigt. (Auf die Kennzeichnung der Übergabe von statischen Werten wie der Priorität und Füllbits wurde verzichtet.)
43
Schlüsselmanagement (PMK / GMK)
?
?
Nachricht (MSDU)
Michael Key
'
?
SA
Session Key (TK)
$
?
?
T
T A
K
-
Schlüsselmix
Phase 1
TA
MIC-Berechnung
?
DA
-
TSC
Schlüsselmix Phase 2
?
?
Fragmente (MSDU + MIC)
?
IV
?
PPK
?
?
WEP-Verschlüsselung (RC4)
&
%
?
?
MAC Hd.
-
MPDU(s)
EIV KID
Abbildung 11: TKIP-Verschlüsselung
Zu Beginn des Verfahrens wird die Integrität der Nachricht mittels einer Prüfsumme
gesichert, die mit Hilfe des Michael Keys unter anderem über die Nachricht (MSDU), ihre
Quelle (Source Address (SA)) und ihr Ziel (Destination Address (DA)) – in Form der jeweiligen MAC-Adressen – berechnet wird. (Es geht eigentlich auch noch eine Prioritätsangabe
mit in die Berechnung ein, da sie aber erst für eine zukünftige Nutzung vorgesehen ist und
im 802.11i-Standard immer den Wert 0 besitzt, wird sie hier nicht weiter betrachtet.) Der
berechnete TKIP Message Integrity Code (MIC) wird nach der Erzeugung an die Nachricht
angehängt. Über die genaue Berechnung des MIC gibt Abschnitt 4.4.1 Auskunft. Aufgrund
der Erweiterung der MSDU um 8 Bytes kann es vorkommen, daß die Nachricht zu lang für
den Frame Body eines MAC-Frames (MPDU) wird und die Nachricht deshalb fragmentiert
werden muß. (Natürlich kann Fragmentierung auch unbeeinflußt vom angefügten MIC vorkommen, wenn beispielsweise die Übertragungsqualität schlecht ist und somit bei zu langen
MAC-Frames zu häufig Wiederholungen nötig sind.) Die MIC-Berechnung liefert also ggf.
mehrere Fragmente der ursprünglichen Nachricht inklusive des angehängten MICs.
Das TKIP sorgt dafür, daß die Fragmente einer MSDU beim Einschließen in eine MPDU
mit einer Sequenznummer ausgestattet werden, die das anschließende Zusammenfügen der
Fragmente ermöglicht. Dieser TKIP Sequence Counter (TSC) hat eine Länge von 48 Bits
und wird teils im WEP IV (16 Bits) und teils im EIV (32 Bits) als Klartext zum Empfänger
44
übertragen. (Zu der genauen Aufteilung des TSC auf die Initialisierungsvektoren IV und
EIV siehe unten.) Zuvor findet er aber auch noch Verwendung während der Erstellung der
PPKs und geht als IV mit in die WEP-Verschlüsselung ein. Der TSC wird zu Beginn einer
Session auf 1 initialisiert und dann für jede zu versendende MPDU um 1 inkrementiert; vgl.
IEEE (2003b, S. 61). Sollten in einer Session mehr als 248 Datenpakete versendet werden,
so wird ein Wechsel des Session Keys veranlaßt und der TSC wieder auf 1 gesetzt.
Das Vorgehen (Schlüsselmix) zur Generierung der PPKs entspricht vom Prinzip her
dem bereits bekannten Fast Packet Keying (FPK)-Verfahren (vgl. Abschnitt 3.4). Vor allem aufgrund der Verwendung des TSCs wurden aber einige Veränderungen am Verfahren
vorgenommen. Wie genau beim TKIP unter Verwendung des Session Keys, der Senderadresse und der Sequenznummer der Per-Paket Key für jede zu übertragende MPDU erzeugt wird, zeigt der nächste Abschnitt. Für die nach erfolgreicher Erstellung des PPK und
Konstruktion des IV erfolgende WEP-Verschlüsselung siehe Abschnitt 2.3.
Auf der Seite des Empfängers werden anschließend zum Teil die gleichen Schritte
wie beim Sender ausgeführt, um die entsprechenden Schlüssel zur Anwendung der WEPEntschlüsselung auf das empfangene Datenpaket zu generieren. Da der TSC im Klartext
übertragen wird, kann der Empfänger prüfen, ob das Paket einen größeren TSC als das vorhergehende besitzt – ist dies nicht der Fall, wird das Paket verworfen. Ansonsten wird der
PPK berechnet und das Paket entschlüsselt. Daraufhin wird der TKIP MIC überprüft, und
bei Unstimmigkeiten werden Gegenmaßnahmen eingeleitet (siehe dazu Abschnitt 4.4.1).
Falls alle MPDUs mit einem korrekten MIC versehen waren, kann schließlich die MSDU
wiederhergestellt werden. Zu der Entschlüsselung beim TKIP siehe weiter unten.
Schlüsselmix / IV Die Funktion zum Erzeugen des zum Verschlüsseln einzelner Datenpakete nötigten PPKs und des IVs für die Initialisierung des RC4-Schlüsselstroms besitzt
zwei Phasen: In der ersten Phase wird ein Zwischenschlüssel gebildet durch das Mixen des
TKs mit der Senderadresse TA und einem Teil des TSCs. Dies geschieht mittels einer Hashfunktion und ist vergleichsweise aufwendig. Der Zwischenschlüssel (TKIP mixed Transmit
Address and Key (TTAK)) kann aber von der Station zwischengespeichert werden. Dies
kann maximal bis zum Ende einer Session sein, also so lange, wie der TK (Session Key)
beibehalten wird. Es kann auch früher eine Neuberechnung nötig sein; dazu siehe weiter
unten. In einer zweiten Phase, die für jede zu versendende MPDU ausgeführt wird, wird
der TTAK dann mit dem Rest des TSCs und dem TK erneut vermischt, um so schließlich
den PPK zu liefern, der zusammen mit einem ebenfalls in dieser Phase erzeugten IV als
Grundlage für die Erzeugung des RC4-Schlüsselstroms dient. Auch die zweite Phase kann
vorberechnet werden, da sich zwei aufeinanderfolgende PPKs nur durch den um 1 erhöhten
TSC in ihrer Konstruktion unterscheiden. Somit kann eine Station auch schon einige PPKs
”auf Vorrat” berechnen.
Erste Phase In der ersten Phase wird ein 80 Bits langer Schlüssel (TTAK) in Form
von fünf 16-Bit-Worten TTAK0 bis TTAK4 produziert. Hierzu wird der 128 Bits lange
Session Key TK (in 16 Bytes TK0 bis TK15 ) mit der 48 Bits langen Senderadresse TA
(sechs Bytes TA0 bis TA5 ) und den höherwertigen 32 Bits des TSCs (sechs Bytes TSC0 bis
TSC5 ) vermischt.
Abbildung 12 zeigt den Algorithmus der ersten Phase; vgl. IEEE (2003b, S. 59) und
45
Edney und Arbaugh (2003, S. 257 + 258). Die Funktion (x k y) verbindet dabei zwei 8-BitWerte x und y zu einem 16-Bit-Wert z in der Form z = 256 · x + y. Des weiteren kommt die
Funktion S(x) zum Einsatz; vgl. IEEE (2003b, S. 57 – 59). Sie stellt die Anwendung einer
Ersetzungstabelle (Substitution-Box (S-Box)) auf x dar und wird weiter unten genauer
beschrieben. Für die Anordnung der Bits gelten hier wie auch für die Berechnungen in
Phase 2 die Konventionen aus IEEE (1999a, Abschnitt 7.1.1). Das heißt, Bytes und Worte
bestehend aus mehreren Bytes enthalten die Bits der durch sie repräsentierten Zahl in
aufsteigender Signifikanz.
Eingabe: TA48Bit , TK 128Bit und (TSC2 , ..., TSC5 )32Bit
Ausgabe: T TAK 80Bit
PHASE1-KEY-MIXING (TA0 , ..., TA5 , TK0 , ..., TK15 , TSC2 , ..., TSC5 )
PHASE1-STEP1:
T TAK0 ← TSC3 k TSC2
T TAK1 ← TSC5 k TSC4
T TAK2 ← TA1 k TA0
PHASE1-STEP2:
for i = 0 to 7 do
j ← 2 · (i mod 2)
T TAK0 ← T TAK0
T TAK1 ← T TAK1
T TAK2 ← T TAK2
T TAK3 ← T TAK3
T TAK4 ← T TAK4
end
+
+
+
+
+
S[T TAK4
S[T TAK0
S[T TAK1
S[T TAK2
S[T TAK3
⊕ (TK1+j k TK0+j )]
⊕ (TK5+j k TK4+j )]
⊕ (TK9+j k TK8+j )]
⊕ (TK13+j k TK12+j )]
⊕ (TK1+j k TK0+j )] + i
return (T TAK1 , ..., T TAK4 )
Abbildung 12: TKIP Schlüssel-Mix Phase 1
Der Algorithmus der ersten Phase initialisiert in einem ersten Schritt die fünf 16-BitWorte des Zwischenschlüssels mit den höherwertigen vier Bytes des TSCs und den sechs
Bytes der TA. In einem zweiten Schritt wird dann eine Schleife acht mal durchlaufen, in
der die Variable j abwechselnd den Wert 0 und 2 annimmt. Während einer Iteration der
Schleife wird unter Verwendung der TKIP S-Box der Session Key in den Zwischenschlüssel
eingemischt.
Wie bereits erwähnt wurde, läßt sich das Ergebnis dieser ersten (rechenaufwendigen)
Phase zwischenspeichern. So lange wie der TK und die TA beibehalten werden, können
die ersten 16 Bits des TSCs inkrementiert werden. Das heißt, es können 216 = 65536
aufeinanderfolgende Pakete unter Verwendung des gespeicherten TTAKs versendet werden.
Sobald aber TSC2 hochgezählt werden muß, ist auch der TTAK neu zu berechnen. Sollte
46
aufgrund einzuleitender Gegenmaßnahmen ein Schlüsselwechsel durchzuführen sein, ist dies
natürlich schon früher nötig; dazu mehr weiter unten.
Zweite Phase Die zweite Phase generiert aus dem Zwischenschlüssel TTAK der ersten Phase (hier wieder repräsentiert durch fünf 16-Bit-Worte TTAK0 bis TTAK4 ) mit
Hilfe des Session Keys TK (16 Bytes TK0 bis TK15 ) und den niederwertigen zwei Bytes des
TSCs (TSC0 und TSC1 ) den 104 Bits langen PPK in Form von sechs 16-Bit-Worten PPK0
bis PPK5 . (Das untere Byte von PPK5 wird im Ergebnis zwei mal verwendet.) Zusammen
mit einem 24 Bits langen IV, der aus TSC0 und TSC1 erstellt wird, enthält die Ausgabe des
Algorithmus der zweiten Phase den 128 Bits langen Schlüssel RC4K mit den Bytes RC4K0
bis RC4K15 für die Berechnung des RC4 Schlüsselstroms.
Abbildung 13 zeigt den Algorithmus der zweiten Phase; vgl. IEEE (2003b, S. 60 + 61)
und Edney und Arbaugh (2003, S. 258 + 259). Die Funktion x >>> 1 steht dabei für das
rechtsseitige Rotieren des 32-Bit-Wortes x um ein Bit, wobei x >> 1 das rechtsseitige Verschieben des 32-Bit-Wortes x um ein Bit bezeichnet. LowerByte(x) liefert das niederwertige
Byte y zu einem 16-Bit-Wert x in der Form y = x mod 256, UpperByte(x) liefert entsprechend das höherwertige Byte. Weiterhin werden die Bitoperationen | und & verwendet.
x | y führt ein bitweises OR von x und y durch, während x & y eine bitweises UND von x
und y bestimmt.
Im Algorithmus der zweiten Phase werden als erstes die sechs 16-Bit-Worte des PPKs
mit den fünf Worten des Zwischenschlüssels und den beiden niederwertigen Bytes des TSC
initialisiert. Innerhalb des zweiten Schrittes wird unter Verwendung der TKIP S-Box erneut
der TK in den PPK eingemischt, wobei durch die anschließenden Rotationen eine noch
stärkere Vermischung erreicht wird. Im dritten Schritt wird der IV erstellt und der zu
erzeugende RC4-Schlüssel RC4K mit dem 24 Bits langen IV und dem 104 Bits langen PPK
belegt. Das erste Byte des IV erhält dabei den Wert von TSC1 , während TSC0 dem dritten
Byte des IV zugewiesen wird. Das zweite Byte des IV ist eine Wiederholung des ersten
Bytes mit dem Unterschied, daß das siebte Bit auf 0 und das fünfte Bit auf 1 gesetzt wird,
wobei das siebte Bit hier das signifikanteste Bit darstellt. Durch diese Konstruktion des
zweiten Bytes werden die sehr schwachen Schlüssel vermieden (vgl. Fluhrer et al. (2001))
– weitere Bedeutung kommt dem zweiten Byte des IVs sonst nicht zu. Der IV und der
PPK ergeben schließlich zusammen den RC4-Schlüssel als Startwert zur Erzeugung des
RC4-Schlüsselstroms im Sinne der WEP-Sicherheitsarchitektur.
Eine Referenzimplementation des TKIP Schlüssel-Mixes findet sich in IEEE (2003b, S.
154 – 161).
Ersetzungstabelle / S-Box In beiden Phasen des Schlüsselmixes kommt eine Ersetzungstabelle (S-Box) zum Einsatz. Eine solche S-Box ordnet jedem Wert aus der zugrundeliegenden Zahlenmenge einen Ersatzwert aus einer meist größeren Menge zu. Als
Grundmenge dienen im Fall vom TKIP die 16-Bit-Worte. Würde ein 16-Bit-Wort mit einer einzigen Ersetzungstabelle in ein anderes 16-Bit-Wort umgewandelt werden müssen, so
müßte diese Tabelle 216 , also 65536 Einträge besitzen und würde damit viel zu groß für den
Einsatz im TKIP sein. Für die TKIP S-Box wird deshalb eine Trennung des 16-Bit-Wortes
in zwei Bytes vorgenommen, auf die jeweils eine eigene, kleinere Ersetzungstabelle angewendet wird. Die erste S-Box dient der Ersetzung des höherwertigen Bytes des 16-Bit-Wortes
47
Eingabe: T TAK 80Bit , TK 128Bit und (TSC0 , TSC1 )16Bit
Ausgabe: RC4K 128Bit
PHASE2-KEY-MIXING (T TAK0 , ..., T TAK5 , TK0 , ..., TK15 , TSC0 , TSC1 )
PHASE2-STEP1:
P P K0 ← T TAK0
P P K1 ← T TAK1
P P K2 ← T TAK2
P P K3 ← T TAK3
P P K4 ← T TAK4
P P K5 ← T TAK4 + TSC1 k TSC0
PHASE2-STEP2:
P P K0 ← P P K0 + S[P P K5 ⊕ (TK1 k TK0 )]
P P K0 ← P P K0 + [(P P K5 ⊕ (TK13 k TK12 )) >>> 1]
P P K1 ← P P K1 + [(P P K0 ⊕ (TK15 k TK14 )) >>> 1]
P P K2 ← P P K2 + [P P K1 >>> 1]
P P K3 ← P P K3 + [P P K2 >>> 1]
P P K4 ← P P K4 + [P P K3 >>> 1]
P P K5 ← P P K5 + [P P K4 >>> 1]
PHASE2-STEP3:
RC4K0 ← TSC1
RC4K1 ← (TSC1 | 0x20) & 0x7F
RC4K2 ← TSC0
RC4K3 ← LowerByte[(P P K5 ⊕ (TK1 k TK0 )) 1]
for i = 0 to 5 do
RC4K4+(2·i) ← LowerByte(P P Ki )
RC4K5+(2·i) ← UpperByte(P P Ki )
end
return (RC4K0 , ..., RC4K15 )
Abbildung 13: TKIP Schlüssel-Mix Phase 2
48
(TKIP S-Box Upper (TSU)) durch ein anderes 16-Bit-Wort, die zweite entsprechend der
des niederwertigen Bytes (TKIP S-Box Lower (TSL)). Die beiden aus den Ersetzungstabellen ermittelten 16-Bit-Worte werden anschließend durch ein XOR verknüpft und ergeben
dann den Wert, durch den der Eingabewert ersetzt wird.
Durch dieses Verfahren wird zwar keine vollständige Permutation der Eingabewerte
erreicht, aber durch geschickte Konstruktion der beiden S-Boxen läßt sich dennoch eine
relativ große Bildmenge erreichen. Der gewählte Ansatz hierfür sieht vor, daß die TSU- und
TSL-S-Boxen aus den in Abbildung 14 und Abbildung 15 gezeigten Byte-Ersetzungstabellen
abgeleitet werden; vgl. St Denis (2003, S. 2). (Für die Ablesung gilt, daß die Spalte die
höherwertige Ziffer einer Hexadezimalzahl angibt – die Zeile entsprechend die niederwertige
Ziffer.)
Die TSU-Upper (TSU-U)-Tabelle und die TSL-Upper (TSL-U)-Tabelle enthalten jeweils nur den Wert für das höherwertige Byte der Einträge in der TSU- bzw. TSLTabelle. Darüber hinaus entspricht die TSU-Tabelle der TSL-Tabelle mit vertauschten höherwertigen und niederwertigen Bytes. Für die Konstruktion der Tabellen gilt also (mit
x ∈ {0x00,...,0xFF}):
TSU (U pperByte(x)) = TSU -U (U pperByte(x)) · 256 + TSL-U (U pperByte(x))
TSL(LowerByte(x)) = TSL-U (LowerByte(x)) · 256 + TSU -U (LowerByte(x))
0x
1x
2x
3x
4x
5x
6x
7x
8x
9x
Ax
Bx
Cx
Dx
Ex
Fx
x0
x1
x2
x3
x4
x5
x6
x7
x8
x9
xA
xB
xC
xD
xE
xF
198
143
117
8
18
166
187
162
129
192
219
213
111
224
217
3
248
31
225
149
29
185
197
93
24
25
100
139
240
124
235
89
238
137
61
70
88
0
79
128
38
158
116
110
74
113
43
9
246
250
76
157
52
193
237
5
195
163
20
218
92
204
34
26
255
239
108
48
54
64
134
63
190
68
146
1
56
144
210
101
214
178
126
55
220
227
154
33
53
84
12
177
87
6
169
215
222
142
245
10
180
121
102
112
136
59
72
156
115
247
7
132
145
251
131
47
91
182
17
241
46
11
184
73
151
28
51
208
96
65
104
14
164
212
138
99
147
140
159
216
203
194
45
130
2
179
81
36
118
141
233
119
85
199
189
172
161
106
60
41
206
95
209
27
183
103
4
175
252
107
67
243
232
174
21
90
86
69
249
223
125
114
254
66
122
40
196
207
62
105
201
30
231
35
226
205
82
148
160
32
200
167
57
202
150
23
135
123
181
83
171
78
221
152
120
229
186
188
49
244
97
153
170
168
77
228
98
127
94
176
37
253
50
22
211
71
13
58
80
109
236
155
42
234
19
133
75
191
230
173
242
16
15
39
165
44
Abbildung 14: TKIP TSU-U S-Box
Nachdem die beiden 16-Bit-Worte mit Hilfe dieser Tabellen ermittelt worden sind, werden sie per XOR verknüpft und liefern ein 16-Bit-Wort, welches den Eingabewert ersetzt.
49
0x
1x
2x
3x
4x
5x
6x
7x
8x
9x
Ax
Bx
Cx
Dx
Ex
Fx
x0
x1
x2
x3
x4
x5
x6
x7
x8
x9
xA
xB
xC
xD
xE
xF
165
69
194
12
27
245
107
243
76
160
59
50
213
144
56
143
132
157
28
82
158
104
42
254
20
152
86
67
136
66
19
248
153
64
174
101
116
0
229
192
53
209
78
89
111
196
179
128
141
135
106
94
46
44
22
138
47
127
30
183
114
170
51
23
13
21
90
40
45
96
197
173
225
102
219
140
36
216
187
218
189
235
65
161
178
31
215
188
162
126
10
100
241
5
112
49
177
201
2
15
238
200
85
72
204
171
108
210
199
1
137
198
84
11
79
181
251
237
148
4
57
131
228
224
81
18
167
184
80
236
92
9
246
190
207
223
87
202
93
180
35
163
182
195
3
103
244
54
77
70
16
193
242
41
110
250
124
95
34
176
169
253
52
155
97
217
6
117
130
211
239
7
156
249
146
119
125
234
8
61
206
75
129
99
71
60
166
37
33
208
32
17
25
191
147
38
123
222
240
48
172
121
168
175
221
145
73
203
98
247
115
105
62
212
68
26
231
226
164
142
220
88
255
252
230
150
83
205
113
232
186
14
43
29
55
233
134
39
120
214
154
91
63
159
151
74
227
109
149
118
139
24
133
185
122
58
Abbildung 15: TKIP TSL-U S-Box
Die in Phase 1 und 2 des Schlüsselmixes verwendete Funktion S(x) läßt sich wie folgt
beschreiben:
S(x) = T SU (U pperByte(x)) ⊕ T SL(LowerByte(x))
Natürlich lassen sich je nach implementierter Berechnung der S-Box-Werte und dem
verfügbarem Speicher auch direkt die TSU- und TSL-Tabellen mit 16-Bit-Werten ablegen;
vgl. IEEE (2003b, S. 58 + 59). Anhand der TSU-U- und TSL-U-Tabellen läßt sich allerdings
leichter ablesen, auf welchen Voraussetzungen die Ersetzungen basieren: Beide Tabellen sind
bijektiv, enthalten also eine Permutation der 256 Eingabewerte, und sind weder Inverse oder
Potenzierungen der jeweils anderen. In der TSU-U-Tabelle findet sich ein einziger Wert, der
fest bleibt: 102. Die TSL-Tabelle enthält keine festen Werte. Eine intensivere Analyse der
mathematischen Grundlagen und kryptographischen Eigenschaften der TKIP S-Box auf
der Basis von TSU-U und TSL-U bietet St Denis (2003, S. 2 – 6). Er bescheinigt darin der
gegebenen S-Box im Rahmen der Möglichkeiten einer solchen Konstruktion ein hohes Maß
an kryptographischer Robustheit.
MAC-Frame-Format Nachdem alle Elemente der beim TKIP zum Einsatz kommenden
MPDU bekannt sind, kann das TKIP MAC-Frame-Format vollständig beschrieben werden.
TKIP erweitert die aus der WEP-Sicherheitsarchitektur bekannte MPDU durch einen 4
Bytes langen erweiterten Initialisierungsvektor (EIV), der zwischen dem IV und dem verschlüsselten Teil der MPDU eingefügt wird. Darüber hinaus wird der Datenbereich der
MPDU, der die Nachricht bzw. ein Nachrichtenfragment enthält, um den 8 Bytes langen
TKIP MIC erweitert. Dieser wird vor der Berechnung des ICVs an die Nachricht angehängt
und zusammen mit dem Nachrichtenfragment und dem ICV mittels RC4 verschlüsselt. Im
50
übrigen schränkt der TKIP MIC die maximale Größe der MSDU (2304 Bytes) nicht ein.
Dagegen reduziert die Verwendung des EIVs die mögliche Länge des Datenteils um 4 Bytes.
Bevor eine MPDU versendet wird, erhält sie auch in diesem Fall einen MAC-Header mit
Daten zur Adressierung im Netz, auf die hier aber nicht näher eingegangen wird.
Die genaue Verwendung der einzelnen Bytes des IVs und des EIVs bei der TKIP MPDU
zeigt Abbildung 16. (Zur einfacheren Darstellung wird angenommen, daß keine Fragmentierung vorliegt.)
verschlüsselt
6
4 Byte
MAC-Hdr.30 Byte (IV+ID)
Nachricht≥1 Byte
EIV4 Byte
MIC8 Byte ICV4 Byte
?
TSC11 Byte *TSC11 Byte TSC10 Byte PAD5 Bit EIV1IDBit KID2 Bit
?
TSC12 Byte TSC13 Byte TSC14 Byte TSC15 Byte
Abbildung 16: TKIP MAC-Frame (MPDU)
Um zu kennzeichnen, ob die MPDU einen erweiterten IV enthält, wurde eines der Füllbits (PAD) des an den IV angehängten Bytes als Indikator verwendet. Ist die EIV ID auf
1 gesetzt, so wurde der IV durch die vier Bytes des EIVs erweitert. In WEP MAC-Frames
enthält dieses Bit immer 0, in TKIP MAC-Frames immer die 1. Die verbleibenden Füllbits
im Byte zwischen dem IV und dem EIV enthalten auch weiterhin die 0. Die letzten beiden
Bits kennzeichnen auch im TKIP MAC-Frame eine Schlüssel-ID (KID). An ihr ist abzulesen, welcher Session Key zum Einsatz kam. Ist die KID 0, so wurde die Nachricht mit dem
Session Key aus dem PTK verschlüsselt. Die KIDs 1 bis 3 dienen der Identifikation von
drei möglichen Gruppenschlüsseln; siehe Abschnitt 4.2.4.
Das erste und dritte Byte des IV sowie der gesamte EIV werden verwendet, um den
TSC zu übermitteln. Dabei werden die 6 Bytes des TSCs nach steigender Signifikanz der
Bits eingefügt – lediglich TSC0 und TSC1 werden im IV vertauscht, um den schwachen RC4
Schlüsseln entgegenzuwirken. Gleiches gilt auch für das zweite Byte, das eine veränderte
Kopie von TSC1 enthält. Bei *TSC1 wird Bit 5 immer auf 1 und Bit 7 immer auf 0 gesetzt. Dies soll ebenfalls die FMS-Attacke verhindern, da somit eine als besonders schwach
bekannte Klasse von IV Werten ausgeschlossen wird. Die hierdurch gegenüber WEP eingegrenzte Menge an verschiedenen IVs (bezogen auf die ersten drei Bytes des IV) wird durch
die grundsätzliche Erweiterung des IVs auf 48 Bits mehr als aufgehoben. Sie verhindert im
51
allgemeinen auch die Notwendigkeit des TK-Wechsels durch das Verbrauchen aller möglichen IVs. Wenn die ersten 16 Bits des TSCs bereits verwendet wurden, muß lediglich die
erste Phase des Schlüsselmixes erneut durchgeführt werden, um den TTAK an die geänderten oberen 32 Bits des TSCs anzupassen, aber es ist kein erneuter Schlüsseltausch nötig.
Hierzu siehe auch weiter oben.
Entschlüsselung Auf der Empfängerseite stehen bei der Verwendung des TKIPs im
Vergleich zur WEP-Sicherheitsarchitektur wesentlich bessere Möglichkeiten zur Verfügung,
die Korrektheit der empfangenen MPDUs zu verifizieren. Bereits vor der Entschlüsselung
wird anhand des im IV und EIV übertragenen TSCs geprüft, ob das Datenpaket, dessen
Sender durch seine Adresse im MAC-Header zu identifizieren ist, eine strikt aufsteigende
Sequenznummer im Bezug auf die bisher von diesem Sender erhaltenen MPDUs enthält.
Ist dies nicht der Fall, der TSC der aktuellen MPDU also kleiner als der TSC einer bereits
empfangenen MPDU der gleichen Session, so wird das Datenpaket verworfen. Hierdurch
wird die Gefahr des Einschleusens bereits verwendeter Nachrichten(-fragmente) (ReplayAttacke) reduziert.
Entspricht der TSC jedoch den Vorgaben, berechnet der Empfänger unter Verwendung des gemeinsamen TKs, den er entsprechend der Absenderadresse in der empfangenen
MPDU auswählt, der Senderadresse TA selbst und des TSCs mittels des aus der Verschlüsselung bekannten Schlüsselmixes den Per-Packet Key. Dieser und der IV werden dann mit
der empfangenen MPDU der WEP-Entschlüsselungsfunktion übergeben. Wenn dabei die
Überprüfung des ICVs erfolgreich verläuft und die anschließende Verknüpfung der MPDUs
zur Originalnachricht gelingt (also alle Fragmente übermittelt wurden), kann der TKIP
MIC überprüft werden. Sollte die MSDU nicht wiederhergestellt werden können, werden
die entsprechenden MPDUs verworfen.
Für die Verifikation des TKIP MICs berechnet der Empfänger die Checksumme über
die MSDU und die MAC-Adressen von Sender und Empfänger und vergleicht diese mit
dem erhaltenen MIC. Wenn auch diese Überprüfung erfolgreich ist, wird die Nachricht
an eine höhere Schicht weitergeleitet. Andernfalls wird die MSDU zurückgewiesen und
Gegenmaßnahmen eingeleitet, da von einem Angriff auf die Übertragung auszugehen ist.
Zur MIC-Berechnung und den Gegenmaßnahmen siehe Abschnitt 4.4.1.
Den gesamten Ablauf der Entschlüsselung der empfangenen MPDUs und deren Rekombination zur eigentlichen Nachricht zeigt schematisch Abbildung 17.
Die obige Beschreibung der Abwehrmaßnahme gegen Replay-Attacken muß eigentlich
noch etwas genauer gefaßt werden, da noch nicht geklärt ist, was mit Paketen geschieht,
die erneut übertragen werden müssen, da evtl. Übertragungsfehler aufgetreten sind. Gemäß
dem IEEE 802.11-Standard werden übertragene Pakete immer von einer ACK (Acknowledge)-Nachricht durch den Empfänger quittiert. Bleibt diese aus, wird das Paket erneut
(mit einem gesetzten Duplikatsbit) übertragen – allerdings mit dem gleichen TSC. Dies
führt aber nicht zu einer Ablehnung des Paketes. Der Empfänger akzeptiert das korrekt
übertragene Paket und verwirft die anderen, bevor er die ACK-Nachricht an den Sender
übermittelt.
Die Bestätigung jedes einzelnen Paketes bedeutet einen relativ hohen Effizienzverlust.
Edney und Arbaugh (2003, S. 241 + 242) erwähnen ein Verfahren, nach dem es möglich
ist, in schneller Abfolge 16 Pakete zu versenden, die der Empfänger dann mit einer einzigen
52
?
?
Session Key (TK)
Michael Key
MPDU(s) incl. TSC
'
$
?
T
T A
K
?
Schlüsselmix
Phase 1
TA TSCPrüfung
?
TSC Schlüsselmix Phase 2
TSC
korrekt
?
?
IV
?
MPDU(s) (Daten)
PPK
?
?
?
WEP-Entschlüsselung (RC4)
?
SA
?
MIC-Berechnung
DA
Defragmentierte MSDU
&
MIC
falsch
?
Gegenmaßnahmen
%
MIC
korrekt
TSC
falsch
?
?
MSDU
MPDU verwerfen
Abbildung 17: TKIP-Entschlüsselung
Nachricht quittiert. Dieses Burst-ACK genannte Verfahren ist derzeit noch nicht im Standard enthalten, wird nach ihrer Ansicht aber sicher in den Standard aufgenommen werden.
Das Verfahren bringt im Bezug auf die Verhinderung der Replay-Attacke jedoch Schwierigkeiten mit sich. Denn wenn eine MPDU der 16 gesendeten Pakete erneut übertragen werden
muß, kann diese MPDU einen TSC besitzen, der um bis zu 15 Zähler geringer ist als der des
zuletzt übertragenen Paketes. In diesem Fall wird es nötig sein, eine Art Empfangsfenster
offen zu halten. Das heißt, daß MPDUs mit einem TSC-Wert, der nicht kleiner als der
aktuelle Zähler minus 16 ist, und dessen TSC noch nicht durch den Empfänger registriert
wurde, nicht abgewiesen werden.
53
4.3.2
CCMP
Im Gegensatz zu dem Ausgangspunkt für die Entwicklung des TKIPs, bei dem auf der Basis
existierender Hardware und einer zu verwendenden Sicherheitsarchitektur eine verbesserte
Sicherheit erreicht werden mußte, konnte das eigentliche neue Verfahren zur Verschlüsselung
der Daten in der RSN-Sicherheitsarchitektur ohne Einschränkungen modelliert werden. In
diesem Fall sind also nur die Vorgaben der aktuellen technischen Entwicklung im Gebiet
der MAC-Level-Verschlüsselung maßgebend. Walker (2002c) hat die grundsätzlichen Anforderungen an ein solches Protokoll zusammengefaßt:
• Das Protokoll muß die Verschlüsselung korrekt umsetzen.
• Da Verschlüsselung allein noch keine Sicherheit garantiert, muß das Protokoll darüber hinaus gegen Fälschungen immun sein, denn anderenfalls kann ein Angreifer die
Eigenschaften des Protokolls selbst für einen Angriff ausnutzen.
• Die Gestaltung des Protokolls muß Replay-Attacken verhindern. (Diese Sonderform
eines Angriffs bedarf meist einer speziellen Behandlung.)
• Es dürfen niemals Schlüssel wiederverwendet werden, da gerade dies Replay-Attacken
ermöglicht. (Diese Vorgabe entspricht im Grunde der Befolgung der Anforderung nach
korrekter Umsetzung des Verschlüsselungsalgorithmus.)
• Da die Wiederverwendung von IVs oder Nonce-Werten oder generell aller Informationen, die als Zufallsfaktor für die Verschlüsselung genutzt werden, ebenfalls eine Form
der Schlüsselwiederverwendung darstellt, ist dies auch zu verhindern, was wiederum
korrekter Implementierung der Verschlüsselung entspricht.
• Quell- und Zieladressen dürfen nicht modifizierbar sein, um zu verhindern, daß die
Identität eines Senders mißbraucht wird, sei es, um Pakete im falschen Namen zu
senden, oder Pakete an unautorisierte Ziele umzuleiten.
• Die Anzahl der verwendeten kryptographischen Mechanismen sollte minimiert werden, um Hardwarekosten zu minimieren und die Anwendungsfreundlichkeit nicht
durch unnötige Installationsmöglichkeiten zu verringern.
• Der Rechenaufwand der kryptographischen Algorithmen sollte minimal sein, da die
Rechenleistung eines APs auch weiterhin einen Kostenfaktor darstellen wird und somit nur wenig Rechenoperationen pro Zeiteinheit für die Verschlüsselung zur Verfügung stehen werden.
• Es sollten möglichst solche kryptographische Mechanismen verwendet werden, die
sich bereits als optimales Verfahren bewährt haben, um die Lebensdauer dieser Sicherheitslösung zu maximieren.
Entsprechend dieser Voraussetzungen wurde als Grundlage des neuen Verfahrens der
Advanced Encryption Standard als Verschlüsselungsalgorithmus ausgewählt. Der AES wurde im November 2001 von dem National Institute of Standards and Technology (NIST)
54
(vgl. NIST (HP)) zum amerikanischen Verschlüsselungsstandard (Federal Information Processing Standard (FIPS) 197) erhoben und löste damit das seit 1977 eingesetzte DES (Data
Encryption Standard)-Verfahren ab; vgl. Tanenbaum (1996, S. 588 – 595). Der AES hatte
nicht nur den Vorteil, aufgrund des enormen Auswahlaufwandes, der vom NIST betrieben
wurde, um eine Ablösung für DES zu finden (vgl. Nechvatal et al. (2000), ein hohes Maß
an Vertrauen zu genießen, sondern bot darüber hinaus in der Eigenschaft, ein wohldokumentierter FIPS zu sein, Vorteile bei der Beantragung von amerikanischen Exportlizenzen;
vgl. Edney und Arbaugh (2003, S. 263).
Zum AES wurde vom NIST der Rijndael-Algorithmus erklärt, vgl. Daemen und Rijmen (2001). Es handelt sich dabei um eine Blockchiffre die im Gegensatz zur RC4Verschlüsselung eben nicht Byte für Byte verschlüsselt, sondern immer ganze Blöcke von
Bytes. Während der Rijndael-Algorithmus verschiedene Block- und auch Schlüssellängen
zur Auswahl stellt, wurde im 802.11i-Standard beides jeweils auf 128 Bits festgelegt. Ein
Problem bei der Verschlüsselung von Blöcken fester Größe ist aber die Tatsache, daß die zu
verschlüsselnden Daten eben nicht in solchen Blöcken vorliegen. Im WLAN ist auch nicht
jede MPDU gleichlang, typischerweise enthält ein Frame zwischen 64 und 1500 Bytes. Die
Daten müssen also vor der Verschlüsselung in Blöcke umgewandelt werden. Die Art der
Umwandlung der Quelldaten ungleicher Länge in durch den AES verschlüsselbare Blöcke
wird als Operationsmodus des AES bezeichnet. (Zu den Vor- und Nachteilen verschiedener
Modi siehe weiter unten.) Der für den 802.11i-Standard ausgewählte Modus ist der Counter
(CTR)-Mode. Zusammen mit dem Cipher Block Chaining – Message Authentication Code
(CBC-MAC) (zur Integritätssicherung) bildet dieser den CCM (CTR/CBC MAC)-Mode
und damit die Grundlage für das im 802.11i-Standard verwendete Verfahren CCMP.
Die anfangs erwähnten Vorgaben für ein Verschlüsselungsprotokoll scheinen im Bezug
auf den AES erfüllt zu sein. Ob sich auch die Vorgaben, die über den reinen Verschlüsselungsalgorithmus hinausgehen, durch CCMP einhalten lassen, zeigen die folgenden Abschnitte. Um den Rahmen dieser Arbeit aber nicht zu sprengen, wird dabei der AES allerdings nicht in allen Einzelheiten des Algorithmus beschrieben. Für weiterführende Informationen zur Implementierung des AES sei deshalb auf die Originalpublikationen Daemen
und Rijmen (2001) und NIST (2001) verwiesen.
Verschlüsselung Im Gegensatz zum TKIP wird die Verschlüsselung des CCMPs nicht
auf Nachrichten (MSDUs) durchgeführt sondern auf der MPDU-Ebene. Eine evtl. nötige Fragmentierung der zu sendenden Nachricht muß also schon vor der Verschlüsselung
vorgenommen werden. Dem CCMP zur Verschlüsselung übergeben werden im Grunde vollständige MPDUs, die nur noch nicht verschlüsselt sind. Darüber hinaus wird wie auch
beim TKIP ein temporärer Schlüssel für eine Session durch das Schlüsselmanagement bereitgestellt (siehe Abschnitt 4.2). Allerdings wird beim CCMP für die Verschlüsselung und
die Integritätssicherung nur ein einziger TK verwendet. Dies erscheint eigentlich problematisch, da keine Schlüssel mehrfach verwendet werden sollten, doch dafür wird jeweils ein
Nonce-Wert für die Initialisierung sowohl der Verschlüsselung als auch der MIC-Berechnung
verwendet. Dieser Nonce-Wert ist innerhalb einer Session einmalig – und zwar für alle an
der Kommunikation teilnehmenden Parteien. Dies wird, wie Abbildung 18 zeigt, durch die
Konstruktion des Nonce-Wertes aus der MAC-Senderadresse (SA) und einer Sequenznummer – hier PN (Packet Number) genannt – erreicht.
55
Prio.1 Byte
Prio.4 Bit
SA6 Byte
PN6 Byte
?
PAD4 Bit
Abbildung 18: CCMP-Nonce
Für die PN gilt ebenso wie für den TSC, daß sich während des Einsatzes einer TK
keine PN wiederholen darf. Allerdings gilt dies für beide Teilnehmer der Kommunikation.
Es wäre also möglich, daß eine PN doch zwei mal in der Kommunikation verwendet wird.
Deshalb sorgt die SA für Abhilfe, durch sie enthält der Nonce-Wert für jede Station eine
andere Adresse. Das Prioritätsbyte im Nonce-Wert ist wie auch beim TKIP für zukünftige
Erweiterungen vorgesehen, in der ggf. verschiedene Arten von Paketen unterschieden werden
müssen, wie z.B. Audio- oder Videodaten, die im Streamingmodus übertragen werden.
Derzeit ist der Wert der vier Prioritätsbits wie auch der vier Füllbits immer 0.
Neben der Erstellung des Nonce-Wertes wird vor der Berechnung des MICs und der
Verschlüsselung der Daten in der MPDU noch ein 8 Bytes langer CCMP-Header erzeugt,
der zwischen den MAC-Header und den eigentlichen Daten der MPDU eingefügt wird. Er
erfüllt den Zweck, die PN und die Schlüssel-ID im Klartext zum Empfänger übermitteln
zu können. Seine Form ist stark an die Konstruktion des IVs und des EIVs aus dem TKIP
angelehnt wie Abbildung 19 zeigt.
PN10 Byte
PN11 Byte PAD1 Byte
PN12 Byte
ID1 Byte
PN14 Byte
PN15 Byte
?
PAD5 Bit
PN13 Byte
EIV1IDBit
KID2 Bit
Abbildung 19: CCMP-Header
Es ist zu sehen daß der CCMP-Header in zwei jeweils 4 Bytes lange Teile trennbar wäre,
die auch als (IV + ID) und EIV des CCMPs bezeichnet werden könnten. Die PN wird hier
ähnlich der Übermittlung des TSCs auf die ersten beiden und die letzten vier Bytes des
Headers verteilt. Das dritte Byte wird nicht benötigt und wird mit Nullen gefüllt. Das
vierte Byte trägt an bekannter Position wiederum die KID, während an der Position des
sechsten Bits vergleichbar zur EIV ID eine 1 gesetzt wird, um zu kennzeichnen, daß es sich
bei dem verwendeten Protokoll um CCMP handelt. (Die Bezeichnung EIV ID wird hier
deshalb beibehalten.) Die restlichen Bits am Anfang des vierten Bytes werden schließlich
wieder mit Nullen gefüllt.
Nach der Erzeugung des Nonce-Wertes und des CCMP-Headers können die eigentli56
chen Schritte zur Absicherung der Kommunikation vorgenommen werden – die Integritätssicherung und die Verschlüsselung. Dies zeigt schematisch auch Abbildung 20. (Auf die
Kennzeichnung der Übergabe von statischen Werten wie der Priorität und Füllbits wurde
verzichtet.)
?
Nachricht (Fragment)
SA
Session Key (TK)
'
?
PN
-
$
Nonce-Konstruktion
?
?
?
?
?
?
-
KID
CCMP-Hd.Konstruktion
-
MIC-Berechnung
(CDC-MAC)
-
AES-Verschlüsselung
(CTR)
&
%
?
MAC-Hd.
-
?
MPDU
Abbildung 20: CCMP-Verschlüsselung
Die Erzeugung des MICs geschieht im Vergleich zum TKIP nicht nur auf der Basis
des Nachrichtenteils sondern entsprechend der zu Beginn aufgeführten Bedingungen auch
unter Einbeziehung von Teilen des MAC-Headers. Der berechnete MIC wird wie gehabt an
die eigentlichen Daten, also die Nachricht bzw. den Nachrichtenteil, angehängt, bevor diese
beiden Felder schließlich durch den AES im Counter-Mode verschlüsselt werden. Details zur
Berechnung des CCMP MICs unter Zuhilfenahme des Session Keys und des Nonce-Wertes
folgen in Abschnitt 4.4.2. Eine genauere Beschreibung der der Verschlüsselung zugrundeliegenden Verfahren enthält der nächste Abschnitt. Diese kommen im übrigen anschließend
auch auf der Seite des Empfängers zum Einsatz.
AES Der Advanced Encryption Standard ist inzwischen in sehr vielen Verfahren über
längere Zeit zum Einsatz gekommen und hat seine Sicherheit damit nachhaltig unter Beweis
gestellt. Dies ist natürlich keine Garantie für die fortwährende Sicherheit des Algorithmus,
doch im Vergleich zu der Zeit, nach der WEP gebrochen wurde, auf jeden Fall ein hoch zu
schätzender Qualitätsfaktor. Es wird von Kryptographen davon ausgegangen, daß der AES
noch für mehrere Jahrzehnte mit der im CCMP gewählten Schlüssellänge von 128 Bits sicher
57
bleibt; vgl. Walker (2002c). Und auch darüber hinaus könnte der AES weiter eingesetzt
werden, indem die Schlüssellänge vergrößert wird, was allerdings auch Änderungen an der
zu verwendenden Hardware zu Folge hätte.
Die in der RSN-Sicherheitsarchitektur eingesetzte AES-Blockchiffre entspricht dem
Rijndael-Algorithmus bis auf den Unterschied, daß sowohl die Blocklänge als auch die
Schlüssellänge auf 128 Bits festgelegt werden. Deshalb können für das Verständnis der
verwendeten Blockchiffre dennoch auch die bereits oben genannten Quellen herangezogen
werden. Eine genau auf die in der RSN-Sicherheitsarchitektur verwendete Variante bezogene
Beschreibung findet sich dagegen in Edney und Arbaugh (2003, Appendix A). Sie kommen
unter anderem zu dem Schluß, daß sich die Operationen, die im AES zur Berechnung des
Schlüsseltextes nötig sind, sehr gut auf im WLAN einzusetzender Hardware umsetzen lassen
und somit der AES nicht nur ein sicherer sondern auch praktikabler Standard ist.
Aufgrund der großen Bekanntheit des AES wird hier nicht weiter auf die Funktion dieser Blockchiffre eingegangen. Im folgenden gilt deshalb, daß durch den AES ein 128 Bits
langer Klartext unter Verwendung eines 128 Bits langen Schlüssels zu einem wiederum 128
Bits langen Chiffretext umgewandelt wird. Das Hauptaugenmerk der folgenden Betrachtungen liegt indes auf der Kapselung des AES durch den CCM-Mode. Daneben werden
aber auch noch zwei weitere Modi vorgestellt, die bei der Einordnung und dem Verständnis
des Vorgehens vom CCMP unterstützen sollen.
ECB Der einfachste der verfügbaren Modi für AES ist der Electronic Codebook
(ECB)-Mode. Dieser wird hier aufgeführt, um das Problem bei der Aufteilung des Quelltextes in zu verschlüsselnde Blöcke aufzuzeigen. Der ECB-Mode teilt den Quelltext einfach
der Reihe nach in 128-Bit-Blöcke auf und verschlüsselt sie jeweils mit dem gleichen Schlüssel.
(Es sind auch andere Blocklängen möglich, doch aufgrund der Vorgabe für CCMP sei für
diesen und die folgenden Modi eine feste Blocklänge von 128 Bits angenommen.) Der letzte Block muß dabei durch Füllwerte auf 128 Bits verlängert werden, wenn die Länge des
Quelltextes keinem Vielfachen von 128 Bits entspricht. Die Anzahl dieser Füllbits muß
darüber hinaus auch vermerkt werden, damit sie bei der Entschlüsselung bedacht werden
können. Den schematischen Ablauf der AES-Verschlüsselung (im Beispiel bei einer Nachrichtenlänge von mindestens vier Blöcken) im ECB-Mode zeigt Abbildung 21; vgl. auch
Edney und Arbaugh (2003, S.266). (Die Abbildung deutet eine parallele Berechnung der
einzelnen Blöcke an. Das Verfahren könnte aber genauso seriell angewendet werden.)
M1128Byte
M2128Byte
M3128Byte
M4128Byte
...
?
?
?
?
?
AES
AES
AES
AES
AES
?
C1128Byte
?
C2128Byte
?
C3128Byte
?
C4128Byte
Verschlüsselung
?
...
Abbildung 21: ECB-Mode
58
Nachricht
Chiffretext
Die größten Schwächen dieses Vorgehens lassen sich leicht erkennen: Gleiche Klartextblöcke werden in gleiche Chiffretextblöcke verschlüsselt und entsprechend vorhandene Regelmäßigkeiten im Klartext führen zu Regelmäßigkeiten im Chiffretext. Damit lassen sich
Informationen über die zu verschlüsselnden Daten gewinnen. Darüber hinaus beinhaltet
der ECB-Mode keine Vorkehrung, um eine Änderung der Reihenfolge der Chiffretextblöcke
zu verhindern; vgl. Buchmann (1999). Auch wenn das letzte Problem durch den MIC relativiert wird, bestätigt dies die Schwäche des ECB-Modes. Es zeigt sich also, daß auch die
beste Blockchiffre keinen effektiven Schutz bietet, wenn ein mangelhafter Operationsmodus zum Einsatz kommt. Der Auswahl des verwendeten Modus ist also ebenfalls eine hohe
Aufmerksamkeit zu widmen, um zu einem guten Verschlüsselungsverfahren zu gelangen.
CTR Der Counter (CTR)-Mode erhält seinen Namen von einem zusätzlichen Zähler,
der in die Verschlüsselung mit einfließt. AES wird nicht mehr auf den zu verschlüsselnden
Block angewendet, sondern auf den genannten Zähler. Das Ergebnis dieser Verschlüsselung
wird dann mit dem eigentlichen Teil der Nachricht per XOR verknüpft. Abbildung 22 zeigt
diesen Ablauf wiederum am Beispiel einer Nachricht mit mehr als drei Blöcken; vgl. auch
Edney und Arbaugh (2003, S. 266).
M1128Byte
1
M2128Byte
2
M3128Byte
3
...
M4128Byte
4
5
Zähler (Counter)
?
?
?
?
?
AES
AES
AES
AES
AES
?
?
⊕
?
C1128Byte
?
?
⊕
?
C2128Byte
?
?
⊕
?
C3128Byte
Nachricht
?
?
⊕
?
C4128Byte
Verschlüsselung
?
?
⊕
XOR
?
...
Chiffretext
Abbildung 22: CTR-Mode
Dieses Verfahren hat viele Vorteile, vor allem auch gegenüber dem ECB-Mode:
• Es nicht mehr nötig, Füllits an die Nachricht anzufügen, um die volle Blocklänge zu
erreichen. Der nicht vollständige Block wird einfach mit dem zugehörigen verschlüsselten Zähler per XOR verknüpft.
• Das Problem, daß gleiche Klartextblöcke auch gleiche Chiffretextblöcke ergeben, ist
behoben, da die Chiffretextblöcke auch durch die unterschiedlichen Zähler verändert
werden.
59
• Die Berechnungen können vollständig parallel ausgeführt werden, da die Zähler vorher
bekannt sind.
• Die Entschlüsselung des Chiffretextes kann mit exakt der gleichen Implementation
wie die der Verschlüsselung durchgeführt werden, da ein zweimaliges XOR zum Originalwert zurückführt.
Im Beispiel startet der Zähler bei 1 und wird für jeden Block um 1 erhöht. Er könnte
aber auch mit einem anderen beliebigen Wert initialisiert werden und nach einem ganz
anderen Muster erhöht werden – solange dieses Schema auch beim Empfänger bekannt ist.
Im allgemeinen wird für die Initialisierung des Zählers ein Nonce-Wert verwendet, um dem
Problem zu begegnen, daß bei gleichem Startzähler zwei identische Nachrichten den gleichen
Chiffretext zugeordnet bekommen. Dieser Nonce-Wert wird dabei aus Daten konstruiert,
die dem Empfänger ebenfalls zur Verfügung stehen.
Der CTR-Mode wird bereits seit mehr als 20 Jahren erfolgreich eingesetzt und genießt
deshalb ein hohes Vertrauen; vgl. Edney und Arbaugh (2003, S.267). Dies überzeugte auch
die TGi und der Counter-Mode wurde zur Verwendung mit dem AES ausgewählt. (Es war
genau genommen allerdings die zweite Wahl, denn an erster Stelle stand eigentlich der
OCB-Mode. Aber dazu siehe unten.)
CCM Der CCM-Mode ist eine Entwicklung der TGi für den IEEE 802.11i-Standard.
Der Counter-Mode wurde zwar für die Verschlüsselung der Nachricht ausgewählt, doch
fehlte diesem Modus die Möglichkeit der Integritätssicherung der Nachrichten. Um dies zu
erreichen, wurde dem Counter-Mode ein zweites Verfahren zur Seite gestellt: Der ISO (International Organization for Standardization)-Standard CBC-MAC; vgl. ISO (1999). Das
Cipher Block Chaining (CBC) übernimmt die Aufgabe der Berechnung eines MICs. Daraus folgt die Bezeichnung CBC-MAC. (Im allgemeinen Sprachgebrauch der Kryptographen
wird statt eines MICs eigentlich der Message Authentication Code (MAC) verwendet. Im
Rahmen der IEEE-Standards wurde allerdings die Abkürzung MIC eingeführt, um der Verwechslung mit der Medium Access Control (MAC) zu entgehen; vgl. Edney und Arbaugh
(2003, S. 236).
Den CCM-Mode haben die Autoren auch allgemein formuliert und als RFC veröffentlicht; vgl. Whiting et al. (2003). Und auch die Sicherheit dieses neuen Modus wurde bereits
untersucht: Jonsson (2002) attestiert dem CCM-Mode eine vergleichbare Sicherheit wie
dem OCB-Mode. (Zu diesem siehe den nächsten Abschnitt.)
Zu Beginn der Anwendung des CCM-Modes erfolgt die MIC-Berechnung (CBC-MAC)
mit Hilfe des bereits oben beschriebenen Nonce-Wertes und des CCMP-Headers. (Eine
Beschreibung des Ablaufs dieser Berechnung des CBC-MAC folgt in Abschnitt 4.4.2.) Im
zweiten Schritt werden die Nachricht bzw. das Nachrichtenfragment incl. des angehängten
64 Bits langen MICs mit Hilfe des Counter-Modes und des AES verschlüsselt.
Wie bereits beschrieben, muß der Auswahl des Zählers im Counter-Mode besondere
Aufmerksamkeit gewidmet werden, um hier keine Schwachstelle in die Verschlüsselung einzubauen. Deshalb wird bei der Konstruktion des Zählers unter anderem der Nonce-Wert
verwendet. Abbildung 23 zeigt die genaue Zusammensetzung des Zählers.
Dem Nonce-Wert wird ein Flag vorangestellt. Darin enthalten ist ein fester 8-Bit-Wert
(00000001), der sich aus vier durch unterschiedlich viele Bits des Flags repräsentierten
60
Flag1 Byte Prio.1 Byte
SA6 Byte
PN6 Byte
Ctr.2 Byte
?
Nonce
Abbildung 23: Konstruktion des Zählers für den CCMP-Counter-Mode
Eigenschaften zusammensetzt. Die 1 am Ende des Flags legt beispielsweise eine Länge von
2 Bits für das Ctr.-Feld fest. Da die Werte aber ohnehin beim CCM-Mode für die RSNSicherheitsarchitektur immer gleich sind, werden die einzelnen Bits hier nicht weiter erklärt.
Eine Beschreibung des Flags ist in IEEE (2002b, S. 64) zu finden. Während der NonceWert nur dafür sorgt, daß der Zähler für verschiedene Sender und auch für verschiedene
Pakete eines Senders immer unterschiedlich ist, enthalten die 2 Bytes des Ctr.-Feldes den
eigentlichen aktiven Zähler. Diese 16 Bits werden während der Verschlüsselung nach der
Initialisierung auf 1 für jeden zu verschlüsselnden Block um 1 inkrementiert. Damit wäre es
theoretisch möglich, 216 128-Bit-Blöcke innerhalb einer MPDU zu verschlüsseln, ohne daß
sich der Zähler wiederholt. Das Ctr.-Feld ist damit mehr als ausreichend dimensioniert.
Mit Hilfe des soeben beschriebenen Zählers und des Session Keys erfolgt die Verschlüsselung des Strings bestehend aus dem Nachrichtenfragment und dem MIC nach dem weiter
oben beschriebenen Counter-Mode. Der zu verschlüsselnde String wird in 128-Bit-Blöcke
aufgeteilt, wobei der letzte Block auch weniger als 128 Bits enthalten kann. Daraufhin
werden die Blöcke per XOR mit dem Ergebnis der AES-Verschlüsselung des Zählers (unter Verwendung des Session Keys) verknüpft. Der Zähler wird dabei für jeden folgenden
Block inkrementiert. Ein großer Vorteil dieses Verfahrens liegt darin, daß die Zähler schon
vorverschlüsselt werden können, da dem Sender alle nötigen Informationen, die für die Konstruktion des Zählers verwendet werden, bekannt sind. Und diese Vorberechnung könnte
parallelisiert werden, genauso wie auch die anschließende XOR-Verknüpfung mit den letztlich abzusichernden Klartextblöcken. Nach der Beendigung der Verschlüsselung wird der
Schlüsseltext schließlich an den MAC-Header und den CCMP-Header angefügt und kann
zum Empfänger übertragen werden.
OCB Der OCB-Mode (vgl. Rogaway et al. (2001)) ist hier nur der Vollständigkeit
halber mit aufgeführt, da er als Grundlage für das nicht weiter unterstützte WRAP diente.
Beim OCB-Mode handelt es sich um eine sog. Authenticated Encryption Scheme, was
bedeutet, daß der Modus nicht nur die Verschlüsselung sondern gleichzeitig auch die Authentifizierung einer Nachricht, also ihre Integritätssicherung bietet. Damit ist verständlich,
warum OCB dem Counter-Mode vorgezogen worden wäre.
Der OCB-Mode hat aber noch weitere Vorteile:
• Die hohe Sicherheit des OCB-Modes kann bewiesen werden. Das heißt, der OCBMode ist genauso sicher wie die AES-Blockchiffre, auf der er basiert.
• Der OCB-Mode ist auch parallelisierbar.
61
• Und der OCB-Mode ist ein sehr effizienter Modus, der nur wenig mehr Rechenaufwand benötigt als das theoretisch erforderliche Minimum an Rechenoperationen zur
Verschlüsselung einer Nachricht.
Aufgrund von Bedenken bzgl. der Urheberrechte an diesem Modus und damit evtl.
zu befürchtender Lizenzzahlungen wurde dieser Modus und damit das gesamte WRAPVerschlüsselungsverfahren wieder aus dem Standard entfernt, nachdem es anfangs als primäres Protokoll aufgenommen worden ist; vgl. Edney und Arbaugh (2003, S. 269).
MAC-Frame-Format Nach der Vorstellung aller Elemente der beim CCMP verwendeten MPDU kann das CCMP MPDU-Format vollständig beschrieben werden. Durch das
CCMP wird die Länge der aus dem 802.11-Standard bekannten originalen MPDU (also ohne WEP IV) um 16 Bytes erweitert. 8 Bytes entfallen dabei auf den an die Nachricht (oder
das Nachrichtenfragment) angehängten MIC und 8 Bytes werden für den CCMP-Header
verwendet. Abbildung 24 zeigt den genauen Aufbau des CCMP MAC-Frames.
verschlüsselt
6
MAC-Hd.30 Byte
PN10 Byte
Nachricht (Fragment)≥1 Byte
CCMP-Hd.8 Byte
MIC8 Byte
?
PN11 Byte PAD1 Byte PAD5 Bit EIV1IDBit KID2 Bit
PN12 Byte
?
PN13 Byte
PN14 Byte
PN15 Byte
Abbildung 24: CCMP MAC-Frame (MPDU)
Die 48 Bits lange PN wird nach aufsteigender Signifikanz auf die ersten beiden und die
letzten vier Bytes des CCMP-Headers verteilt und unverschlüsselt übertragen. Am Ende
des ersten Blocks von vier Bytes steht wie gehabt die KID und die EIV ID, die in diesem
Fall ähnlich wie bei TKIP anzeigt, daß ein 8-Byte-CCMP-Header in die MPDU eingefügt
wurde, und für CCMP immer 1 ist. Alle Padding-Bits enthalten den Wert 0.
Entschlüsselung Die Möglichkeiten des Empfängers, die Korrektheit der empfangenen
MPDUs zu verifizieren, sind vergleichbar mit denen bei der Verwendung des TKIPs – mit
dem Unterschied, daß der CCMP MIC nicht so anfällig ist, und somit das Konstrukt der
Gegenmaßnahmen wie beim TKIP MIC (siehe Abschnitt 4.4.1) entfällt.
62
?
Session Key (TK)
MPDU incl. PN
$
'
?
SA PN Nonce-Konstruktion
PNPrüfung
MPDU (Daten) ?
?
?
AES-Verschlüsselung
(CTR)
?
-
PN
korrekt
?
MIC-Berechnung
(CDC-MAC)
?
MAC-Hd.
&
%
MIC
korrekt
MIC
falsch
?
PN
falsch
?
Nachricht (Fragment)
?
MPDU verwerfen
Abbildung 25: CCMP-Entschlüsselung
Den schematischen Ablauf der Entschlüsselung zeigt Abbildung 25.
Nach dem Empfang der verschlüsselten MPDU ist als erstes anhand der im MACHeader zu findenden Adresse des Absenders der entsprechende Session Key, der ja für
jeden Kommunikationspartner – identifizierbar an seiner MAC-Adresse – unterschiedlich
ist, auszuwählen.
Wie schon beim TSC im TKIP wird auch hier die PN, die im Klartext mit dem CCMPHeader übertragen wurde, auf eine aufsteigende Abfolge untersucht, um Replay-Attacken
zu verhindern. Das Verhalten im Bezug auf die Überprüfung der PN entspricht dabei dem
des TKIPs: Wird die Anforderung nicht erfüllt, wird die MPDU einfach verworfen. Fällt
die Prüfung positiv aus, so kann der Nonce-Wert aus der übertragenen Senderadresse und
der Paketnummer erstellt werden. Diese Daten könnten zwar auch von einem Angreifer
aus einer abgefangenen MPDU entnommen werden, doch solange dieser den Session Key
nicht besitzt, sind die Informationen nutzlos. Der Nonce-Wert kann anschließend durch die
Erweiterung mit dem bekannten Flag und einem 16-Bit-Ctr. (der auch hier mit 1 beginnt)
zur Initialisierung des Counters für die AES-Verschlüsselung verwendet werden. Hier zeigt
sich nun der große Vorteil von CCMP: Zur Entschlüsselung der MPDU wird tatsächlich
der gleiche Algorithmus verwendet wie zur Verschlüsselung. Unter Verwendung des Session
63
4.4 INTEGRITÄT
Keys werden wiederum die Zähler verschlüsselt und diesmal mit den Blöcken aus der erhaltenen Nachricht durch XOR verbunden. Dieses XOR mit dem Schlüsseltext macht das
XOR aus der ursprünglichen Verschlüsselung rückgängig und den Klartext wieder sichtbar.
Da durch die Entschlüsselung nun auch der erhaltene MIC und die vollständigen Daten
zur lokalen Erzeugung des MICs zur Verfügung stehen, kann der MIC lokal berechnet und
mit dem übermittelten MIC verglichen werden. Bei einer Übereinstimmung wird die Nachricht (oder das Nachrichtenfragment) an die nächste Schicht weitergereicht. Dort werden
die Fragmente ggf. wieder zu einer MSDU zusammengefügt. Bei einem Fehler der MICÜberprüfung wird die empfangene MPDU verworfen, da sehr wahrscheinlich ein Angriff
vorliegt.
4.4
Integrität
Die Integrität der zu übermittelnden Nachricht wird von den beiden Verschlüsselungsmechanismen jeweils mittels eines MICs (Message Integrity Code) sichergestellt. Jedoch handelt es sich hierbei um zwei verschiedene Checksummen, denn jedes Verschlüsselungsverfahren bedient sich einer eigenen Konstruktionsvorschrift für den MIC. Wie die Checksummen
in den jeweiligen Verfahren berechnet werden und welche Sicherheit sie bieten, beschreiben
die folgenden Abschnitte.
4.4.1
TKIP MIC
Zu den Problemen der WEP-Sicherheitsarchitektur gehört unter anderem eine völlig unsichere Integritätswahrung der Nachricht, was vor allem aktive Angriffe ermöglicht; vgl. Abschnitt 2.3.2. Um das unberechtigte Verändern von Daten zu unterbinden, baut das TKIP
auf das MIC-Verfahren Michael, das auf einer kryptographischen Einweg-Hashfunktion
(vgl. Buchmann (1999, Kapitel 10)) beruht. Im Gegensatz zum ICV aus der WEPSicherheitsarchitektur, der lediglich durch eine (umkehrbare) Berechnung einer Checksumme allein auf der Basis der zu übermittelnden Daten gebildet wurde, wird beim MIC
zusätzlich ein geheimer Schlüssel mit in die Berechnung einbezogen. Diese wird darüber
hinaus mittels einer Einweg-Funktion durchgeführt, damit auch die Umkehrung der Berechnung nicht durchführbar ist. Obwohl Michael trotz dieser Maßnahmen keine extrem
hohe Sicherheit bieten kann, stellt das Verfahren aber unter der Prämisse der Verwendbarkeit auf Altgeräten eine angemessene Lösung dar, die die Integrität signifikant gegenüber
WEP verbessert; vgl. IEEE (2003b, S. 50).
Michael Der große Vorteil von Michael gegenüber der CRC-32 Checksumme von WEP
ist die Eigenschaft, daß der MIC über die ganze Nachricht und nicht über die jeweils
in einem MAC-Frame eingefügten Nachrichten-Fragmente berechnet wird. Der MIC wird
beim Empfänger erst überprüft, wenn er die Nachricht aus den einzelnen Fragmenten wieder
zusammengesetzt hat. Wurde auch nur ein Fragment verändert, so wird die ganze Nachricht
verworfen und es werden Gegenmaßnahmen getroffen. Der WEP ICV sichert darüber hinaus
ab, daß aufgrund von Übertragungsfehlern diese Gegenmaßnahmen nicht unnötig eingeleitet
werden. Zu den Gegenmaßnahmen selbst siehe den nächsten Abschnitt. Die in Abschnitt
2.3.2 beschriebenen, nur auf die einzelnen MAC-Frames (MPDUs) ausgerichteten Angriffe
werden durch den MIC viel leichter erkannt. Darüber hinaus wird durch die Verlagerung
64
4.4 INTEGRITÄT
der Checksumme von der MPDU auf die MSDU erreicht, daß ihre Berechnung nicht in der
MAC-Schicht durchgeführt werden muß, sondern in der Hardware implementiert werden
kann oder sogar im Treiber für die Hardware bzw. in Software auf dem Rechner, bei dem
der WLAN-Adapter installiert ist.
Das Fälschen von Nachrichten kann Michael damit allerdings nicht ganz verhindern, da
es gegen Replay-Attacken ungeschützt ist. Diesen Schutz will TKIP durch die Verwendung
von Sequenznummern (vgl. Abschnitt 4.3.1), der WEP ICV-Validierung und regelmäßiger Schlüsselerneuerung (vgl. Abschnitt 4.2) liefern. Allerdings kann bei Verwendung von
Gruppenschlüsseln (vgl. Abschnitt 4.2.4) eine Station innerhalb der Gruppe die Identität
einer anderen Station fälschen und damit eben auch gefälschte Nachrichten senden. Von
der Verwendung von Gruppenschlüsseln ist darum eher abzuraten; vgl. IEEE (2002b, S.
40).
Als Grundlage für die Berechnung des MICs dient, wie Abbildung 26 zeigt, ein String aus
der Ziel- und der Quelladresse der Nachricht, der Nachrichtenpriorität und der Nachricht
selbst.
DA6 Byte
SA6 Byte
Prio.1 Byte Pad
3 Byte
Nachricht≥1 Byte
MIC
8 Byte
6
Michael
Abbildung 26: Berechnung des TKIP MIC (Michael)
Die Priorität und das 3 Bytes lange Pad-Feld sind für zukünftige Erweiterungen des
802.11-Standards vorgesehen und enthalten derzeit jeweils nur den Wert Null. Diese beiden
Felder und die Adressen werden zwar zu der Berechnung des TKIP MIC herangezogen,
aber letztlich nicht mit zum Empfänger übermittelt. Der berechnete MIC jedoch wird an
die Nachricht angehängt und mit ihr an den 802.11-MAC weitergereicht. Dort wird die um
8 Bytes erweiterte Nachricht ggf. noch fragmentiert, also in mehrere MPDUs aufgeteilt.
Das heißt, daß die Nachricht nebst MIC in einem oder mehreren MAC-Frames übermittelt
wird, von denen jeder einzelne wiederum mit einem eigenen ICV (WEP) abgesichert wird,
wobei der ICV auch hier wieder nur als reine Transportsicherung zur Verhinderung von
zufälligen Übertragungsfehlern dienen kann. Auf der Empfängerseite werden die Nachrichtenfragmente in der MAC-Schicht dann wieder zur Originalnachricht zusammengefügt und
die Richtigkeit des MIC überprüft. Kann er als korrekt verifiziert werden, wird die Nachricht an die nächste Schicht weitergereicht, andernfalls wird die Nachricht verworfen, ein
Fehlerzähler inkrementiert und Gegenmaßnahmen eingeleitet (siehe unten).
Die um DA, SA, Priorität und Pad-Block erweiterte Nachricht wird vor der MICBerechnung durch Michael nochmals um ein Trennungsbyte mit dem Wert 0x5a erweitert
und anschließend mit 4 bis 7 Null-Bytes auf die Länge eines Vielfachen von 8 Bytes aufgefüllt. Dieses Padding dient der einfacheren Anwendung der Michael zugrundeliegenden
Blockchiffre und wird nicht mit der Nachricht und dem MIC übermittelt. Die Berechnungsgrundlage kann daraufhin in n einzelne Bytes m0 bis mn−1 zerlegt werden. Diese werden
65
4.4 INTEGRITÄT
in 32-Bit-Worte M0 bis MN −1 zusammengefaßt, wobei für die Berechnung von N gilt (mit
dae = Aufrunden von a zum nächsten Integer-Wert):
(n + 5)
N=
4
Aus der Konstruktionsregel folgt MN −1 = 0 und MN −2 6= 0. Für die Umwandlung der
Bytes zu 32-Bit-Worten gilt für 802.11, also auch hier, die ”little endian” Konvention in
IEEE (1999a, Abschnitt 7.1.1).
Für die eigentliche Anwendung des Michael-Algorithmus wird noch der Michael Key
benötigt. Dieser wird zusammen mit dem TK aus dem Pairwise Master Key (PMK) oder
Group Master Key (GMK) erzeugt; vgl. Abschnitt 4.2. Er besteht aus 8 Bytes k0 bis k7 ,
die wiederum in zwei 32-Bit-Wörter K0 und K1 umgewandelt werden, bevor sie als Startwerte für l und r zur iterativen Anwendung einer Blockchiffre auf die erweiterte Nachricht
verwendet werden. Es wird eine Schleife N mal durchlaufen, wobei in jeder Iteration l mit
dem nächsten Wort aus der erweiterten Nachricht per XOR verknüpft wird und anschließend die Michael-Blockchiffre BLOCK(l, r) auf l und r angewendet wird. Das Ergebnis, der
MIC, wird schließlich in Form von zwei 32-Bit-Worten V0 und V1 ausgegeben. Abbildung
27 zeigt den prinzipiellen Ablauf der TKIP MIC-Berechnung.
Eingabe: (K0 , K1 )64 Bit , M N·32 Bit
Ausgabe: (V0 , V1 )64 Bit
MICHAEL (K0 , K1 , M0 , ..., MN −1 )
(l, r) ← (K0 , K1 )
for i = 0 to N − 1 do
l ← l ⊕ Mi
(l, r) ← BLOCK(l, r)
end
return (l, r)
Abbildung 27: Michael-Algorithmus
Die bei Michael verwendete Blockchiffre des Feistel-Typs (vgl. Buchmann (1999, Abschnitt 5.1)) besteht aus sich abwechselnden Additionen und XOR-Operationen. Abbildung
28 zeigt die einzelnen Operationen der Blockchiffre. x >>> y steht dabei für das rechtsseitige Rotieren des 32-Bit-Wortes x um y Stellen, x <<< y entsprechend für das linksseitige
Rotieren. XSwap(x) bezeichnet das Austauschen der zwei höherwertigen Bits mit den zwei
niederwertigen Bits eines 32-Bit-Wortes x.
Die zwei 32-Bit-Worte V0 und V1 , die sich als Ergebnis des Michael-Algorithmus ergeben, werden anschließend wieder in 8 Bytes umgewandelt und ergeben somit den MIC, der
an die Nachricht angefügt wird.
Bei den durchgeführten Berechnungen wurden keinerlei Multiplikationen durchgeführt,
sondern nur Bit-Verschiebungen und -Additionen. Dieses Vorgehen ermöglicht den Einsatz
von Michael auf einem AP, ohne dessen Leistung zu erschöpfen. Das wird allerdings durch
66
4.4 INTEGRITÄT
Eingabe: (l, r)64 Bit
Ausgabe: (l, r)64 Bit
BLOCK (l, r)
r ← r ⊕ (l <<< 17)
l ← (l + r) mod 232
r ← r ⊕ XSwap(l)
l ← (l + r) mod 232
r ← r ⊕ (l <<< 3)
l ← (l + r) mod 232
r ← r ⊕ (l >>> 2)
l ← (l + r) mod 232
return (l, r)
Abbildung 28: Michael-Blockchiffre
eine relativ kurze Checksumme erkauft: Das Michael-Verfahren produziert einen 64 Bits
langen MIC, mit dem eine Sicherheit von 20 Bits erreicht wird. Das heißt, daß ein Angriff
im allgemeinen erst nach 220 Versuchen erfolgreich durchgeführt werden kann. Dies würde
bei Brute-Force-Angriffen aber eine Schwachstelle bedeuten. Somit mußte als Ausgleich für
die Schwäche des MIC das Konzept der Gegenmaßnahmen aufgenommen werden, das im
folgenden Abschnitt beschrieben wird.
Gegenmaßnahmen Die Implementierung des TKIPs mußte als primäres Ziel die Kompatibilität zu bestehenden WLAN-Systemen sicherstellen. Die durch das TKIP zu erreichende Sicherheit wurde dadurch eingeschränkt. Dennoch wurde durch das Konzept der
Gegenmaßnahmen ein relativ hohes Maß an Sicherheit erreicht: Das TKIP kann nicht alle
Angriffe verhindern, aber es ist in der Lage, mögliche Angriffe zu entdecken. Und solche
Angriffsversuche quittiert das Verfahren dann mit Gegenmaßnahmen; vgl. IEEE (2003b, S.
52 – 57). Die einfachste Gegenmaßnahme wäre die Abschaltung des Netzes – und in dieser
Form wird gewissermaßen auch im TKIP reagiert. Durch eine solche Maßnahme ist jede
Angriffsmöglichkeit unterbunden, allerdings auch alle legitimen Zugriffe auf das Netz oder
das mobile Gerät. Hier zeigt sich also auch eine Schwachstelle dieses Konzeptes: Es macht
das Netz in gewissem Maße anfälliger für DoS-Attacken. Durch Einspielen von entsprechend
gefälschten Paketen läßt sich das Netz effektiv unbrauchbar machen. Um diese Gefahr so
gering wie möglich zu halten, führen alle anderen möglichen Fehler im Bezug auf eine empfangene MPDU bereits vor der Überprüfung des MICs zu einer Abweisung des Paketes.
Treten also Fehler bei der Verifizierung der FCS, des ICVs oder des TSCs auf, kommt es
erst gar nicht zu der Auslösung der Gegenmaßnahmen. Im übrigen existieren aber ohnehin
wesentlich einfachere Möglichkeiten für DoS-Attacken, so daß die Anfälligkeit von TKIP
gegenüber DoS-Attacken völlig irrelevant ist; vgl. auch Edney und Arbaugh (2003, S. 251
+ 252).
Da bei einem MIC-Fehler mit hoher Wahrscheinlichkeit davon auszugehen ist, daß es
sich um einen Angriff handelt (vgl. IEEE (2003b, S. 52)), wird im Standard dazu geraten,
solch einen Vorfall in einem Log zu verzeichnen und die verantwortlichen Administratoren
67
4.4 INTEGRITÄT
zu informieren. Dies kann allerdings nur ein Vorschlag sein, da es immer von der lokalen
Sicherheitspolitik abhängig ist, ob und inwieweit diese Möglichkeiten genutzt werden. Fest
im Standard verankert ist aber die Vorgabe, die Fehlerrate unter zwei Fehlern pro Minute
zu halten. Dies impliziert, daß die Station für 60 Sekunden die Annahme aller weiteren
Datenpakete verweigert, wenn innerhalb einer Minute zwei MIC-Fehler aufgetreten sind.
Und schließlich wird geraten, darüber hinaus den der aktuellen Session zugrundeliegenden
Session Key zu wechseln, also entsprechend einen neuen PTK oder GTK zu erzeugen; siehe
dazu die Abschnitte 4.2.3 und 4.2.4.
MIC-Fehler sind nach dem Ort des Auftretens zu unterscheiden, denn Angriffe können
sowohl auf einen Authentifizierer (im allgemeinen der AP) als auch auf einen Client gerichtet
sein. Die Fehler sollen aber nicht nur auf der jeweiligen Station erfaßt werden, sondern auch
immer an das authentifizierende System gemeldet werden. (Also im Infrastrukturmodus an
den AP, im IBSS-Modus an die Station, auf der die Anmeldung durchgeführt wurde.)
Client Stellt ein Client einen Fehler bei der Überprüfung einer empfangenen Unicastoder Multicast-MPDU fest, sind die folgenden Schritte auszuführen:
• Das Paket wird verworfen.
• Der Vorfall wird in ein Log geschrieben und Verantwortliche werden informiert.
• Der eigene TKIP MIC-Fehlerzähler wird inkrementiert.
• Eine Nachricht über den Fehler wird an den Authentifizierer gesendet.
• Ist es die erste Fehlernachricht, wird der Fehlertimer aktiviert.
• Wenn weniger als 60 Sekunden seit einem vorausgehenden Fehler vergangen sind, wartet der Client, bis die Fehlernachricht übertragen ist und schließt dann die Verbindung
zum Authentifizierer. Der PTK und der GTK werden verworfen und erst nach frühestens 60 Sekunden wird eine erneute Assoziation durchgeführt, wobei der Client neue
Schlüssel erhält; siehe auch Abschnitt 4.2.3. Alternativ kann sich der Client auch bei
einem anderen AP anmelden – in diesem Fall ist keine Wartezeit nötig. Nach dieser
Prozedur werden sowohl der Fehlerzähler als auch der Fehlertimer zurückgesetzt.
Eine Fehlernachricht an den Authentifizierer wird in Form eines EAPOL-Key-Frames
(siehe Abschnitt 4.5.2) übertragen und vom Client mit einem IEEE 802.1x EAPOL MIC
abgesichert; siehe dazu Abschnitt 4.2.3.
Authentifizierer Wird beim Authentifizierer ein fehlerhafter MIC entdeckt oder eine
Fehlernachricht eines Clients empfangen, werden die folgenden Maßnahmen ergriffen:
• Wenn es sich um einen lokalen MIC-Fehler handelt, wird das Paket verworfen.
• Der Vorfall wird in ein Log geschrieben und Verantwortliche werden informiert.
• Der TKIP MIC-Fehlerzähler wird inkrementiert.
• Ist es die erste Fehlernachricht, wird der Fehlertimer aktiviert.
68
4.4 INTEGRITÄT
• Wenn weniger als 60 Sekunden seit einem vorausgehenden Fehler vergangen sind,
schließt der Authentifizierer alle Verbindungen zu den angeschlossenen Stationen, die
TKIP verwenden, und widerruft alle PTKs und den GTK. (Wird allerdings von einer
Station ein CCMP PTK verwendet, aber daneben ein TKIP GTP, so wird auch der
CCMP-Schlüssel widerrufen.) Eine Generierung von neuen PTKs (siehe 4.2.3) wird
erst nach 60 Sekunden wieder zugelassen. Ein GTK wird neu erzeugt und ebenfalls
erst nach 60 Sekunden aktiviert; (siehe Abschnitt 4.2.4. Fehlerzähler und Fehlertimer
werden schließlich zurückgesetzt.
4.4.2
CCMP MIC
Auch bei der Verwendung der CCMP-Verschlüsselung wird ein MIC berechnet – allerdings
ist hierbei kein zweites Verfahren wie Michael nötig, sondern in diesem Fall kann dafür voll
auf die Verschlüsselungsfähigkeiten des AES zurückgegriffen werden. Beim CCMP kommt
der oben beschriebene CCM-Mode zum Einsatz, der den Counter-Mode für den AES um
den CBC-MAC erweitert; (siehe Abschnitt 4.3.2). Dieser CBC-MAC erlaubt die Berechnung
eines MICs auf der Basis des Cypher Block Chainings. Das Prinzip dieser Technik sieht die
Aufteilung der zu sichernden Datenquelle in Blöcke vor (hier 128 Bits lang), die daraufhin
seriell zuerst verschlüsselt und dann jeweils mit dem darauffolgenden Block mittels XOR
verknüpft werden, worauf dieser Block dann wieder verschlüsselt wird, usw. Abbildung 29
verdeutlicht dieses Vorgehen anhand einer Nachricht, die in n 128-Bit-Blöcke aufteilbar ist.
B1128 Bit
B2128 Bit
?
AES
B3128 Bit
?
-
⊕
...
Bn128 Bit
- AES -
⊕
?
- AES -
⊕
Nachricht
?
Verschlüssel./XOR
?
128 Bit
MIC
MIC
Abbildung 29: CBC-MAC
Das Ergebnis dieses Vorgehens ist dann ein einzelner 128-Bit-Block, der CCMP MIC.
Im folgenden wird beschrieben, wie diese Verkettung genau vorgenommen wird und welche
Schritte darüber hinaus für die Sicherheit des MICs nötig sind.
CBC-MAC Durch das CBC-MAC-Verfahren wird das gesamte Datenpaket, dessen Integrität gesichert werden soll, sukzessive in die Berechnung des MIC einbezogen. Voraussetzung dafür ist aber, daß das Datenpakt aus einem Vielfachen von 128-Bit-Blöcken bestehen
muß, damit die eben beschriebene Verkettung angewendet werden kann.
Im Vergleich zum TKIP wird durch das CCMP aber nicht nur die Integrität des Nachrichtenteils der MPDU gesichert, sondern darüber hinaus auch noch einen Teil des MACHeaders. Dieser Teil wird im aktuellen Draft IEEE (2003b) als AAD (Additional Authen69
4.4 INTEGRITÄT
tication Data) bezeichnet und enthält die Adressfelder aus dem MAC-Header, soweit sie
genutzt wurden. Andere Daten aus dem MAC-Header, die sich bei einer Übertragung ggf.
auch ändern können, werden im AAD auf Null gesetzt. Damit entspricht das Verfahren zur
Konstruktion des MIC auch der in Abschnitt 4.3.2 erwähnten Forderung der Unveränderbarkeit der Adressen. Zur genauen Konstruktion des AAD siehe IEEE (2003b, S. 64 + 65).
Sowohl das Nachrichtenfragment als auch der AAD-Teil entsprechen in ihrer Länge nicht
unbedingt bzw. nie einem Vielfachen von 128 Bits. Deshalb werden vor der Berechnung des
MICs beide Teile mit Nullen zum jeweils nächsten Vielfachen von 128 Bits verlängert. Diese
Füllbits gehen aber ausschließlich in die Berechnung des MICs ein und nicht in die letztlich zu sendende MPDU. Abbildung 30 zeigt die Berechnungsgrundlage für den MIC, der
anschließend an die Nachricht angefügt wird, um mit ihr zusammen verschlüsselt zu werden. Es werden allerdings nur 64 Bits des berechneten MICs im CCMP benötigt, weshalb
die niederwertigen 64 Bits des Ergebnisses vor dem Anfügen an die Nachricht verworfen
werden.
erster Block16 Byte
AAD22-30 Byte Pad2-10 Byte
Nachricht≥1 Byte
Pad≥0 Byte
?
30 Byte
MAC-Hd.
≥1 Byte
8 Byte
CCMP IV
Nachricht
8 Byte
MIC
Abbildung 30: Berechnung des CCMP MIC (CBC-MAC)
Ähnlich wie bei dem Zähler im Counter-Mode muß aber auch bei der Berechnung des
CCMP MIC mit dem CBC-MAC Verfahren garantiert werden, daß keine Wiederholungen
auftreten. Um den relativ unwahrscheinlichen Fall auszuschließen, daß ein MIC ein zweites
Mal über genau denselben Daten berechnet wird, wird der erste Block, der in die Berechnung des MIC eingeht mit Hilfe des oben beschriebenen Nonce-Wertes erzeugt. Damit wird
garantiert, daß jede MIC-Berechnung einzigartig ist. Aber wie auch bereits bei der Konstruktion des Zählers für den CCMP AES-Counter-Mode kommt bei der Konstruktion des
Startblocks für die Berechnung des MICs nicht nur der Nonce-Wert zum Einsatz: Abbildung 31 zeigt, wie auch hier ein Flag und ein zweites Feld DLen angefügt werden, um
zusammen mit dem Nonce-Wert den ersten 128-Bit-Block für die Berechnung des CCMP
MIC zu bilden.
Das Flag-Feld enthält auch hier wieder einen festen 8-Bit-Wert (01011001), der sich
wiederum aus vier durch unterschiedlich viele Bits des Flags repräsentierten Eigenschaften
zusammensetzt. Die zwei auf 1 gesetzten Bits in der Mitte des Flags legen beispielsweise die
Länge von 64 Bits für den letztlich zu verwendenden MIC fest. Da aber auch hier die Werte
für den RSN CCM-Mode immer gleich sind, werden die einzelnen Bits nicht weiter erklärt.
Eine Beschreibung des Flags ist in IEEE (1997, S. 59) zu finden. Das zweite angefügte,
16 Bits lange Feld DLen enthält die Länge des Nachrichtentextes. Alle Felder dieses ersten
Blocks sind wie der AAD und die Nachricht selbst auch beim Empfänger bekannt, nach70
4.5 AUTHENTIFIZIERUNG
Flag1 Byte Prio.1 Byte
SA6 Byte
PN6 Byte
DLen2 Byte
?
Nonce
Abbildung 31: Erster Block zur Berechnung des CCMP MIC
dem die MPDU entschlüsselt wurde. Der Empfänger kann also den ersten Block ebenfalls
erzeugen und den MIC lokal zur Überprüfung des erhaltenen MICs berechnen.
4.5
Authentifizierung
In einem Netzwerk, das keine physischen Zugangsbeschränkungen besitzt, ist eine Netzwerkzugangsauthentifizierung unverzichtbar. Mit dem RSN wird eine solche Zugangsbeschränkung implementiert. Die Authentifizierungsmechanismen in der RSN-Sicherheitsarchitektur
sind mehrschichtig aufgebaut. Um die Abhängigkeit unter den verschiedenen Authentifizierungsmechanismen besser zu verstehen, folgt deshalb vorerst ein kurzer Überblick über die
generelle Aufteilung dieser Sicherheitsschichten im WLAN.
Ein grundlegendes Problem der WEP-Sicherheitsarchitektur bestand darin, keine angemessene Unterscheidung zwischen verschiedenen Sicherheitsmaßnahmen wie z.B. der Verschlüsselung und der Authentifizierung gemacht zu haben. Dieses Problem behebt das RSN
durch die Übernahme von Sicherheitsschichten, wie sie auch in anderen Sicherheitslösungen
beispielsweise im herkömmlichen LAN eingesetzt werden. Die drei Sicherheitsschichten sind
die Wireless-LAN-Schicht, die Zugangskontrollschicht und die Authentifizierungsschicht.
Auf der Wireless-LAN-Schicht wird die eigentliche Arbeit verrichtet – also die Kommunikation abgewickelt, Ver- und Entschlüsselung der Datenpakete vorgenommen. Dies wurde
in den vorangegangenen Abschnitten bereits ausführlich beschrieben. Die Zugangskontrollschicht sorgt dagegen dafür, daß nur authentifizierte Nachrichten diese Schicht passieren.
Hierzu wird für ein ankommendes Paket die darüberliegende Authentifizierungsschicht befragt, ob der Zugang gewährt werden soll. Ein Authentifizierungsprotokoll aus der darüberliegend Schicht (im Standard Upper-Layer-Authentifizierung genannt) nimmt die eigentliche Authentifizierungsprüfung vor und weist die Zugangskontrollschicht entsprechend
an. Ein Problem hierbei ist, dafür zu sorgen, daß die Pakete eines bereits authentifizierten Clients nicht immer wieder auf diese Weise geprüft werden müssen. Ein Protokoll, das
hierfür eine praktikable Lösung anbietet, wurde in dem IEEE 802.1x-Standard gefunden.
Er beinhaltet eine portbasierende Authentifizierung, die im folgenden genauer beschrieben
wird. Für den Austausch von Nachrichten mit der dritten Schicht wird das Extensible Authentication Protocol (EAP) eingesetzt. Die Protokolle der Upper-Layer-Authentifizierung
selbst werden im 802.11i-Standard allerdings nicht mit aufgeführt. Vielmehr bietet der Standard so die Möglichkeit, daß bereits existierende Systeme zur Benutzerauthentifizierung,
die insbesondere in Firmen eingesetzt werden, beibehalten werden können und das WLAN
so einfach in die bestehende Firmeninfrastruktur integriert werden kann; vgl. Edney und
Arbaugh (2003, S. 110 – 113).
In den folgenden Abschnitten wird entsprechend der eben beschriebenen Zweiteilung
71
des Authentifizierungsprozesses vorerst die Rolle des 802.1x-Standards als Zugangskontrollmechanismus erörtert. Eng damit verbunden ist das EAP, dessen Aufgabe als Kommunikationsprotokoll während der Authentifizierung im Anschluß an den 802.1x-Standard
beschrieben wird. Obwohl es nicht direkter Bestandteil des 802.11i-Standards ist, wird das
RADIUS-Protokoll ebenfalls kurz vorgestellt, um einen vollständigen Authentifizierungsablauf darstellen zu können. Abschließend werden einige Protokolle, die in der zweiten
Authentifizierungsschicht – der Upper-Layer-Authentifizierung – eingesetzt werden können, in ihren Grundzügen angesprochen. Hierzu gehören beispielsweise das TLS-Protokoll
oder das Light EAP (LEAP) von Cisco. Aufgrund der Gestaltungsfreiheit im Bezug auf
die Upper-Layer-Authentifizierung sind auf dieser Schicht auch Verbindungen der WLANAuthentifizierung mit Mobilfunk-Funktionen denkbar. Erste Ansätze für ein mögliches Interworking beschließen dieses Kapitel.
4.5.1
802.1x
Bei IEEE 802.1x handelt es sich um einen Standard zur portbasierenden Zugangskontrolle, die ursprünglich für herkömmliche LANs entwickelt wurde (vgl. IEEE (2001c)), aber
als Teil der RSN-Sicherheitsarchitektur ebenso für Wireless-LANs einsetzbar ist. Es wird
durch den 802.1x-Standard eine Authentifizierungsarchitektur bereitgestellt, die drei Rollen
unterscheidet: Den Client, den Authentifizierer und den Authentifizierungsserver. Ein Client ersucht um Zugang zu einem Netzdienst über einen der Authentifizierer. Dieser reicht
die Anfrage an einen (im allgemeinen) zentralen Authentifizierungsserver weiter, der darauf den Authentifizierer anweist, den Netzdienst für den Client freizugeben, wenn dieser
erfolgreich authentifiziert wurde. Abbildung 32 zeigt die Rollenverteilung und den Nachrichtenaustausch bei der Authentifizierung eines Clients am WLAN.
Client (WLAN-Karte)
6
EAPOL-Nachrichten
?
Authentifizierer (AP)
6
RADIUS/EAP-Nachrichten
?
Authentifizierungsserver (AS)
Abbildung 32: 802.1x-Rollen
Die Kommunikation zwischen den drei Systemen geschieht auf der Basis von EAPNachrichten, die zwischen dem Client und dem AP mittels EAPOL-Nachrichten gekapselt
72
werden und zwischen dem AP und dem AS meist durch RADIUS-Nachrichten (beim Einsatz eines RADIUS-Servers als AS). Die Funktion der verwendeten Protokolle wird in den
Abschnitten 4.5.2 und 4.5.3 erläutert.
Bei der Anwendung der 802.1x-Zugangskontrolle im herkömmlichen LAN stehen einem
Client auf der Seite des Authentifizierers tatsächliche Netzwerk-Ports – beispielsweise in
Form eines Switches – gegenüber. Das heißt, ein Client wird einem bestimmten Anschluß
zugeordnet, der wiederum der Kontrolle durch einen bestimmten Authentifizierungsserver
unterliegt. Damit bietet der 802.1x-Standard eine Möglichkeit, dafür zu sorgen, daß ein
Rechner nicht einfach nur per Netzwerkkabel mit dem Switch zu verbinden ist, um Zugriff
auf das Netz zu erhalten, sondern daß vor einem Zugriff auch immer die Identität und die
Rechte des Benutzers zu überprüfen sind.
Dieses Prinzip läßt sich auf die WLAN-Infrastruktur übertragen: Statt der physischen
Ports werden hier die logischen Verbindungen der Clients zum AP als Ports interpretiert.
Der AP erzeugt für jeden anfragenden Client einen eigenen logischen Port, für den jeweils
ein eigener (virtueller) Authentifizierer zuständig ist. Der Authentifizierer unterscheidet
hierbei in kontrollierte und unkontrollierte Ports. Ein Client sendet seine Verbindungsanforderung an einen unkontrollierten Port, über den er ausschließlich Nachrichten mit dem
AS austauschen kann. Erst wenn die Authentifizierung erfolgreich verlaufen ist, erhält der
authentifizierte Client über einen kontrollierten Port Zugriff auf das Netz; vgl. IEEE (2003b,
S. 14 + 15).
Obwohl der 802.1x-Standard in Kombination mit dem offenen Transportprotokoll EAP
eine sehr gut einzusetzende Basis für die Authentifizierung im WLAN darstellt, ist dies doch
nicht ohne Einschränkungen zu betrachten. Die genannte Kombination stellt lediglich ein
Authentifizierungsprotokoll zur Verfügung – nicht aber ein Integritätsprotokoll. Ein ausreichender Schutz der Authentifizierungsnachrichten ist damit also nicht gegeben. Wenngleich
damit zwar kein vollständiger Schutz gegen die von der WEP-Sicherheitsarchitektur bekannten Angriffe möglich wird, so wurde die Sicherheit der Authentifizierung im Vergleich
dazu aber dennoch wesentlich verbessert; vgl. Potter und Fleck (2003, S. 159 + 160).
Die Einbindung des 802.1x-Standards in die Arbeit der TGi wurde von einigen Problemen begleitet: Ein erster Versuch, bei dem der 802.1x-Standard unverändert für den Einsatz
im WLAN verwendet werden sollte, schlug fehl; vgl. Walker (2002a). Ohne Veränderungen
am 802.1x-Standard bietet die Authentifizierungslösung zu viele Möglichkeiten für erfolgreiche Attacken. (Eine Zusammenfassung der Angriffsmöglichkeiten bieten beispielsweise
Mishra und Arbaugh (2002).) Aber auch nach etlichen Änderungen bis zu dem heutigen
Stand der Einbindung des 802.1x-Standards sind nicht alle Probleme behoben; vgl. Walker
(2002a). Derzeit wird deshalb parallel an einer Überarbeitung des 802.1x-Standards selbst
gearbeitet, um diesen für den Einsatz im 802.11i-Standard zu verbessern. Aktuell ist der
Stand der Arbeit bei der Draft Version 7.1 im Oktober 2003 angelangt; vgl. IEEE (2003c).
Für eine Verabschiedung des IEEE 802.11i-Standards ist somit auch eine weitere Abstimmung mit den Verbesserungen im 802.1x-Standard nötig. Bis dahin ist die Sicherheit
der Authentifizierung vor allem von der sinnvollen Auswahl eines geeigneten Upper-LayerAuthentifizierungsprotokolls abhängig. Hier sollten vor allem Protokolle wie das PEAP
(Protected EAP) oder das TTLS (Tunneled TLS) bevorzugt werden, da diese durch eine zweistufige Authentifizierung eine Verschlüsselung der Authentifizierungsnachrichten
ermöglichen und damit die Offenheit des Authentifizierungsmechanismus zumindest ein-
73
schränken. Eine gute Absicherung ist allerdings erst in Verbindung mit einer etablierten
PKI zu erreichen; vgl. Walker (2002a).
In den folgenden Abschnitten werden die Grundfunktionalitäten der involvierten Protokolle bei der Authentifizierung in der RSN-Sicherheitsarchitektur vorgestellt.
4.5.2
EAP
Ursprünglich wurde das Extensible Authentication Protocol für die Verwendung in EinwahlNetzwerken entwickelt. Einwahl-Netzwerke werden beispielweise bei ISPs (Internet Service
Provider) mit Hilfe von Modem-Pools realisiert. Die Verbindung vom Modem des Clients
zum Modem des ISPs wird mit dem Point-to-Point Protocol (PPP) aufgebaut, das ursprünglich nur zwei Authentifizierungsmethoden kannte: Das PAP (Password Authentication Protocol) und das CHAP (Challenge Handshake Authentication Protocol). Während
das PAP den Benutzernamen und das Paßwort im Klartext überträgt, verwendet das CHAP
immerhin einen Challenge-Response-Mechanismus. Dennoch bieten beide Protokolle kaum
einen Schutz der Authentifizierung. Eine Lösung dieses Problems bietet das EAP. Wie
in Blunk und Vollbrecht (1998) beschrieben, wird mit diesem Protokoll der Authentifizierungsmechanismus erweiterbar (extensible) gemacht. Das heißt, statt weitere Authentifizierungsprotokolle in den PPP-Standard einzubauen, bietet das EAP die Möglichkeit, beliebige Authentifizierungsmaßnahmen verwenden zu können, deren Nachrichten dann gekapselt
durch das EAP übertragen werden. (Zu diesen Upper-Layer-Authentifizierungsprotokollen
siehe 4.5.4.) Dies wird dadurch erreicht, daß der Aufbau der PPP-Verbindung erst vollständig durchgeführt wird, bevor die Authentifizierung anschließend über einen zentralen
Authentifizierungsserver des ISPs abgewickelt wird. Die dafür nötige Kommunikation des
letztlich verwendeten Authentifizierungsprotokolls wird mittels des EAPs über die PPPVerbindung gekapselt. Für den Transport der Nachrichten zwischen dem Modem-Pool und
dem Authentifizierungsserver wird meist der RADIUS (siehe Abschnitt 4.5.3) eingesetzt,
mit dem auch EAP-Nachrichten übertragen werden können.
Zur Anwendung kommen für die EAP-Kommunikation lediglich vier verschiedene Nachrichtentypen:
• EAP-Request
Dieser Typ wird verwendet, um Nachrichten vom AS über den Authentifizierer an
den Client zu senden.
• EAP-Response
Entsprechend enthält dieser Typ Nachrichten, die vom Client über den Authentifizierer zurück an den AS gesendet werden.
• EAP-Success
Mit einer EAP-Success-Nachricht wird dem Client über den Authentifizierer vom AS
mitgeteilt, daß die Authentifizierung erfolgreich vorgenommen werden konnte.
• EAP-Failure
Ein negativer Authentifizierungsversuch wird mit einer EAP-Failure-Nachricht an den
Client quittiert.
74
Die EAP-Request- und EAP-Response-Nachrichten werden in weitere Subtypen aufgeteilt. Hierfür kommt das EAP-Type-Feld im Nachrichten-Frame zum Einsatz, das festlegt, welche Informationen durch die EAP-Request- oder Response-Nachricht transportiert
wird. Die ersten sechs Typen werden bereits im Standard festgelegt. Mit Typ 1 werden
beispielsweise die EAP-Request/Identity- und EAP-Response/Identity-Nachrichten belegt,
mit denen der Authentifizierungsserver den Namen des Clients abfragt und der Client entsprechend antwortet.
Für die Identifizierung der möglichen Upper-Layer-Authentifizierungsprotokolle werden die Typ-Nummern größer als 6 eingesetzt. Neu entwickelten Protokollen werden die
Typ-Nummern einheitlich von der IANA (Internet Assigned Numbers Authority) zugewiesen; vgl. IANA (HP). Das TLS-Protokoll beispielsweise besitzt die Typ-Nummer 13 und
das LEAP die 17. Anhand der Typ-Nummer kann ein Client entscheiden, ob er das entsprechende Authentifizierungsprotokoll unterstützt – im negativen Fall sendet der Client
eine EAP-Response des Typs 3. Diese Nachricht wird als ein sog. Negative Acknowledge
(NAK) bezeichnet. Einen besonderen Status besitzen Nachrichten des Typs 2: Sie enthalten Benachrichtigungen (im Klartext) für den Benutzer. Beispielsweise die Aufforderung
zur Eingabe eines Paßwortes oder Ähnliches.
Für eine genaue Beschreibung des Frame-Formats der einzelnen EAP-Nachrichten sei
auf den Standard selbst verwiesen; vgl. Blunk und Vollbrecht (1998).
Der Aufbau eines Einwahl-Netzwerks ist der durch den IEEE 802.1x-Standard entworfenen Struktur sehr ähnlich. Daher läßt sich das EAP entsprechend gut auf diesen
Anwendungsfall übertragen; vgl. Edney und Arbaugh (2003, S. 120 – 122). Statt der PPPVerbindung liegt zwischen dem Client und dem Authentifizierer in diesem Fall eine LANVerbindung vor. Den Transport der EAP-Nachrichten über diese LAN-Verbindung übernimmt das im folgenden beschriebene EAP over LAN.
EAPOL Da das Extensible Authentication Protocol wie oben beschrieben ursprünglich
für die Authentifizierung von Benutzern geplant war, die sich gegenüber einem Einwahlknoten, auf den sie per Modem zugreifen, authentifizieren müssen, enthält das Protokoll keinerlei Vorgaben für den Transport der Nachrichten in einem LAN. Um EAS für den Einsatz im
LAN (und damit auch im WLAN) brauchbar zu machen, wurde im IEEE 802.1x-Standard
die EAPOL (EAP over LAN)-Erweiterung für das EAP definiert; vgl. IEEE (2001c, S. 13 –
21). Es wurden dabei mehrere Typen von Nachrichten vorgesehen, von denen die folgenden
im IEEE 802.11i-WLAN verwendet werden; vgl. auch Edney und Arbaugh (2003, S. 133 +
134):
• EAPOL-Start
Wenn sich ein Client mit einem WLAN verbinden will, muß dieser vorerst die MACAdresse des Authentifizierers (sofern vorhanden) ermitteln. Dafür sendet der Client eine EAPOL-Start-Nachricht an eine reservierte Multicast-Adresse. Dadurch kann von
Seiten des Clients geprüft werden, ob ein Authentifizierer im Netz existiert und diesem ggf. mitgeteilt werden, daß er sich anmelden möchte. Der Authentifizierer sendet
daraufhin eine EAP-Request/Identity-Nachricht (transportiert durch eine EAPOLPacket-Nachricht) zurück an den Client.
75
• EAPOL-Key
Für die Übermittlung der nötigen Schlüssel an den Client verwendet der Authentifizierer die EAPOL-Key-Nachrichten. Der Ablauf der Schlüsselerstellung unter Verwendung der EAPOL-Key-Nachrichten wird in Abschnitt 4.2 beschrieben. Für die
genaue Beschreibung des Aufbaus des EAPOL-Key-Frame-Formats, das beim 4-WayHandshake für die Übermittlung der temporären Schlüssel an die Clients verwendet
wird (und natürlich auch beim Gruppenschlüssel Handshake), siehe IEEE (2003b, S.
89 ff.).
• EAPOL-Packet
Mit Hilfe des EAPOL-Packet-Frames werden die eigentlichen EAP-Nachrichten
übertragen. Diese Containerfunktion entspricht der ursprünglichen Ausrichtung der
EAPOL-Erweiterung zum EAP.
• EAPOL-Logoff
Mit dieser Nachricht wird vom Client an den Authentifizierer gemeldet, daß er das
Netzwerk verlassen will.
Der Einsatz der beschriebenen Nachrichten wird im nächsten Abschnitt am Beispiel
einer vollständigen Authentifizierung unter Verwendung des RADIUS in Abbildung 33 verdeutlicht.
4.5.3
RADIUS
Der Remote Access Dial-In User Service ist nicht explizit als Teil der RSN-Sicherheitsarchitektur in den 802.11i-Standard aufgenommen worden, wird hier aber dennoch in den
relevanten Teilen kurz vorgestellt, da er in vielen WLAN-Implementationen als Kommunikationsprotokoll zwischen AP und Authentifizierungsserver und damit auch als Träger für
die Upper-Layer-Authentifizierungsprotokolle zum Einsatz kommt.
Wie auch das EAP hat der RADIUS seinen Ursprung in den Einwahl-Netzen für die Unterstützung von Modem-Pools. Um eine einheitliche Nomenklatur zu ermöglichen, sei auf
die Trennung der Funktionalität eines RADIUS-Servers und der Bezeichnung des Protokolls
RADIUS hingewiesen; vgl. Edney und Arbaugh (2003, S. 138): Das auf TCP/IP-Netzwerken
basierende Protokoll RADIUS kommt zur Anwendung, um in verteilten Einwahl-Netzen den
ggf. weit verstreuten Modem-Pool-Servern (NAS (Network Access Server)) eine Kommunikationsmöglichkeit mit einem zentralen RADIUS-(Authentifizierungs-)Server zu bieten.
Hierdurch wurde das Problem gelöst, ohne eine zentrale Instanz in jedem NAS eine redundante Benutzerverwaltung vorhalten zu müssen.
Das Protokoll und die Server-Funktionen des RADIUS wurden von der IETF standardisiert und stehen in den RFCs 2865 bis 2868 inklusive einiger Erweiterungen zur Verfügung;
vgl. z.B. Rigney et al. (2000b).
Der beschriebene Einsatzzweck in Einwahl-Netzen zeigt wiederum Parallelen zum
WLAN auf: Der NAS im Einwahl-Netz entspricht einem AP im WLAN. Für den Fall der
Verwendung mehrerer APs in einem größeren WLAN kommt dem Einsatz eines zentralen
Authentifizierungsservers sogar eine noch größere Bedeutung zu, da die APs im allgemeinen
physisch wesentlich zugänglicher sind als ein NAS, womit sich die Vorhaltung von Benutzerdatenbanken in allen APs verbietet. Für die Auswahl des RADIUS als Kommunikationspro76
tokoll im WLAN ist insbesondere die Fähigkeit des Transports von EAP-Nachrichten von
Bedeutung. Diese Erweiterungen des RADIUS um die EAP-over-RADIUS-Funktionalität
wurden in Rigney et al. (2000a) definiert. Aktuell wird daran gearbeitet, diesen Standard so
zu aktualisieren, daß auch der Einsatz in Kombination mit dem 802.1x-Standard abgedeckt
wird; vgl. Aboba und Calhoun (2003).
Wie auch beim EAP bzw. EAPOL beschränkt sich das RADIUS-Protokoll auf wenige
für die Authentifizierung relevante Nachrichten. Da das RADIUS-Protokoll allerdings entwickelt wurde, um die Authentifizierung für PPP-Verbindungen zu gewährleisten, decken
sie damit eigentlich nur die Verfahren PAP und CHAP ab. Für die Verwendung aktueller
Authentifizierungsprotokolle werden die Nachrichten darum teilweise zweckentfremdet. Die
verwendeten Nachrichten sind im einzelnen:
• Access-Request
Die Access-Request-Nachricht ist die einzige Nachrichtenart, die vom Authentifizierer
an den Authentifizierungsserver gesendet wird. Sie leitet die Authentifizierung ein
bzw. wird verwendet, um die Antwort zu der Challenge des Authentifizierungsservers
zu übermitteln.
• Access-Challenge
In der Access-Challenge sendet der Authentifizierungsserver die Information zu der
verwendeten Upper-Layer-Authentifizierungsmethode und die entsprechende Challenge für den Client an den Authentifizierer.
• Access-Accept
Konnte die in Form einer Access-Request-Nachricht erhaltene Antwort auf die
Challenge bestätigt werden, sendet der Authentifizierungsserver eine Access-AcceptNachricht.
• Access-Reject
Fiel die Überprüfung der Antwort des Clients negativ aus, wird die Access-RejectNachricht an den Authentifizierer gesendet.
In den Access-Request- und Access-Challenge-Nachrichten werden jeweils EAPRequest- und EAP-Response-Nachrichten gekapselt – damit wird das RADIUS-Protokoll
in Kombination mit dem 802.1x-Standard und EAP nutzbar.
Abbildung 33 zeigt abschließend den grundsätzlichen Ablauf der Authentifizierung eines
WLAN-Clients an einem RADIUS-Server und gibt an, welche EAP-Nachrichten jeweils
durch EAPOL- bzw. RADIUS-Nachrichten gekapselt werden; vgl. auch Gast (2002, S. 111)
und Funk Software Inc. (2003).
1. Der Client versucht, Zugang zum Netzwerk zu erhalten und sendet eine EAPOL-Start
Nachricht an den AP (Authentifizierer).
2. Kann der Authentifizierer davon ausgehen, daß der Authentifizierungsserver EAPNachrichten versteht, kann er diese Anfrage mit der Gegenfrage nach der Identität des Clients beantworten und sendet dazu eine EAP-Request/Identity-Nachricht
(gekapselt als EAPOL-Packet). Kann sich der AP aber nicht sicher sein, sendet er
eine EAP-Start-Nachricht (eine EAP-Nachricht ohne Datenteil gekapselt in einen
77
1: -Start
-
2: -Packet(EAP-Req./Ident.)
3: -Packet(EAP-Resp./Ident.) -
3: -Access-Req.(EAP-Resp./Ident.)
-
4: -Packet(EAP-Request)
4: -Access-Challenge(EAP-Req.)
5: -Packet(EAP-Response)
5: -Access-Request(EAP-Resp.)-
-
6: -Packet(EAP-Success)
6: -Access-Accept(EAP-Succ.)
7: -Key
7: -A.-Acc.(”MS-MPPE-Recv-Key”)
Client
?
AP
EAPOL-Nachrichten
?
AS
RADIUS-Nachrichten
Abbildung 33: Authentifizierungsverlauf (EAP/EAPOL/RADIUS)
RADIUS-Access-Request) an den AS, die dieser dann im positiven Fall mit einer
EAP-Request/Identity-Nachricht (gekapselt als RADIUS-Access-Challenge) beantwortet, die wieder an den Client in einem EAPOL-Packet weitergereicht wird; vgl.
Edney und Arbaugh (2003, S. 144 – 146).
3. Die Antwort des Clients mit seiner Identität (EAP-Response/Identity als EAPOLPacket) reicht der AP in Form eines RADIUS-Access-Request an den Authentifizierungsserver weiter.
4. Der RADIUS-Server bereitet einen EAP-Request vor, der unter anderem auch den
EAP-Authentifizierungstyp enthält, und sendet ihn als RADIUS-Access-Challenge an
den AP, der den EAP-Request wiederum als EAPOL-Packet dem Client zustellt.
5. Wenn der Client den EAP-Authentifizierungstyp unterstützt, sendet er eine entsprechende EAP-Response (EAPOL-Packet) an den AP. Dieser leitet sie als RADIUSAccess-Request an den AS weiter.
6. Kann der RADIUS-Server die Antwort des Clients akzeptieren, sendet er eine
RADIUS-Access-Accept-Nachricht an den AP, die eine EAP-Success-Nachricht enthält. Sie wird vom AP als EAPOL-Packet an den Client weitergereicht.
7. Darauf sendet der AS den Master Key an den Authentifizierer. (Wie Master Keys erstellt werden, wurde bereits in Abschnitt 4.2 beschrieben.) Für die Übermittlung des
Schlüssels an den Authentifizierer wurde ursprünglich im RADIUS-Protokoll aber
keine Nachrichtenart vorgesehen. Dieses Problem wird durch eine Erweiterung des
78
Standards, die von Microsoft vorgeschlagen wurde, behoben: In Zorn (1999) wird
das sog. MS-MPPE-Recv-Key-Attribut für RADIUS-Access-Accept-Nachrichten eingeführt, das mittels eines Session Keys im Microsoft Point-to-Point Encryption (MPPE)-Protokoll die Übertragung des Schlüssels vom AS zum NAS absichert. Ob Microsofts Vorschlag, dieses Verfahren auch für die Übermittlung der Schlüssel im WLAN
zu übernehmen, angenommen wird, ist noch nicht klar. Seitens des NIST wird eine
Alternative präferiert; vgl. dazu Edney und Arbaugh (2003, S. 147).
Nachdem der Authentifizierer (auf die eine oder andere Weise) mit dem Pairwise Master Key für den Client ausgestattet wurde, können die temporären Schlüssel schließlich in EAPOL-Key-Nachrichten an den Client übermittelt werden.
4.5.4
Upper-Layer-Authentifizierung
Da die durch den IEEE 802.11i-Standard festgelegten Protokolle und Verfahren sich nur
auf die MAC-Schicht (Teil der ISO-OSI-Schicht 2) beziehen, sind die Protokolle der UpperLayer Authentication (ULA) – wie der Name bereits verdeutlicht – nicht im Standard enthalten. Zusammen mit dem EAP als universelles Transportprotokoll für die ULA-Protokolle
ergänzen sie den IEEE 802.1x-Standard zu einer vollständigen Authentifizierungslösung.
Während der 802.1x-Standard und das EAP (ggf. zusammen mit dem RADIUS) im Grunde
nur das korrekte Routing der Nachrichten zwischen Client, Authentifizierer und Authentifizierungsserver gewährleisten, übernehmen die ULA-Protokolle letztendlich die wichtige
Aufgabe der gegenseitigen Authentifizierung von Client und Authentifizierungsserver und
generieren die bereits in Abschnitt 4.2 eingeführten Schlüssel. Durch die gegenseitige Authentifizierung wird mit dieser Authentifizierungsstruktur endlich erreicht, daß auch die
Identität des Netzes, an dem sich der Client authentifiziert, gesichert ist. Gemein ist allen
ULA-Protokollen dabei die Verwendung von Challenge-Response-Verfahren. Wie allerdings
die interne Abwicklung der Aufgaben gestaltet ist, bleibt den Protokollen selbst überlassen.
Derzeit existieren eine ganze Reihe verschiedener Protokolle, die für die Verwendung
mit EAP entwickelt wurden, bzw. sind als Draft bei der IETF in Vorbereitung. Es ist
aber zu erwarten, daß es in diesem Bereich noch weitere Neuentwicklungen geben wird –
insbesondere solange sich noch kein allgemeines Verfahren durchgesetzt hat.
Die ULA-Protokolle sollen in dieser Arbeit zwar nicht intensiv betrachtet werden, der
Vollständigkeit halber werden im folgenden aber einige bekannte Vertreter dieser Protokolle
kurz vorgestellt und Literaturverweise für weitere Informationen gegeben.
TLS Das Transport Layer Security (TLS)-Protokoll basiert auf dem von Netscape entwickelten SSL (Secure Socket Layer)-Protokoll und wurde bei der IETF standardisiert; vgl.
Dierks und Allen (1999). Das zertifikatbasierende Protokoll kann sich dabei durch die intensive Verbreitung des SSL-Protokolls auf eine Vielzahl von etablierten Zertifizierungsstellen
stützen. Durch den Einsatz von Zertifikaten wird eine starke Sicherheit erreicht, doch erfordert dies die recht aufwendige Pflege der Client-Zertifikate. Der Einsatz in Verbindung mit
dem EAP (TLS over EAP) wurde in einem weiteren Standard festgelegt; vgl. Aboba und
Simon (1999). Obwohl auch in diesem Fall die Entwicklung des Protokolls für die Verwendung über PPP-Verbindungen vorgesehen war, läßt sich das TLS-Protokoll auch für das
WLAN nutzen. Das Protokoll gehört als gegenseitiges Authentifizierungsprotokoll zu den
79
am meisten verbreiteten Vertretern der ULA-Protokolle und wird so unter anderem von
Microsoft Windows 2000 und XP direkt unterstützt; vgl. Red-M (2003, S. 5).
Für einen detaillierten Einblick in das TLS-Protokoll und die Möglichkeit des Einsatzes
für das Schlüsselmanagement in Verbindung mit RADIUS vgl. auch Edney und Arbaugh
(2003, S. 155 – 169).
Kerberos Das Kerberos-System bietet Sicherheitsmechanismen für IP-basierende Netzwerke. Die ersten Arbeiten an diesem Protokoll fanden bereits 1980 statt, 1993 wurde
die noch heute aktuelle Version 5 bei der IETF standardisiert; vgl. Kohl und Neumann
(1993). (Anschließend wurden aber auch noch einige weitere Ergänzungen des Standards
vorgenommen.)
Kerberos verwendet ein Ticket-System, in dem ein Client ein zeitlich begrenztes Ticket
für einen bestimmten Dienst erhält. (Für jeden Dienst ist ein eigenes Ticket nötig.) Wie
diese Ticketvergabe und Kerberos allgemein im Rahmen des IEEE 802.11i-Standards eingesetzt werden kann, beschreiben Edney und Arbaugh (2003, S. 169 – 184) sehr ausführlich.
LEAP Das Cisco Light EAP war das erste Protokoll, das mit IEEE 802.1x und dem
EAP zusammen als ULA-Protokoll verwendet wurde. Es bot bereits die gegenseitige Authentifizierung und half schließlich auch bei der Etablierung der temporären Session-Keys;
vgl. Burns und Hill (2003). Das Protokoll war somit auch Wegbereiter für die weitere
Entwicklung, obwohl es nie standardisiert wurde. Auch wurde das Protokoll nie von Cisco veröffentlicht. Allerdings konnte es auf der Basis der Analyse übertragener Datenpakete rekonstruiert werden und wurde so im Internet verfügbar gemacht. Damit konnten
kompatible Protokolle von anderen Herstellern entwickelt werden. Das LEAP verwendet
ein Challenge-Response-Verfahren auf der Basis von MS-CHAPv1, einer Erweiterung des
CHAP-Protokolls durch Microsoft, mit der eine gegenseitige Authentifizierung möglich ist;
vgl. Zorn und Cobb (1998). Eine Beschreibung der Verwendung des LEAP in Kombination
mit dem RADIUS bieten Edney und Arbaugh (2003, S. 184 – 186).
PEAP Mit dem Protected EAP (PEAP) wird eine vollständige Anonymität des Clients
(gegenüber Angreifern von außen) während der Authentifizierung erreicht. PEAP verbindet
das EAP mit dem TLS-Protokoll und behebt damit die Unsicherheit von EAP, die darin
besteht, daß die EAP-Identity- und EAP-Success/Fail-Nachrichten ungeschützt übertragen
werden. Dafür wird ein Ansatz in zwei Schritten verwendet: Im ersten Schritt wird eine
sichere Verbindung mit dem TLS-Protokoll über das EAP aufgebaut, während der nur der
AS authentifiziert wird. In der zweiten Phase wird dann die bestehende sichere Verbindung
genutzt, um eine vollständige EAP-Authentifizierung durchzuführen; vgl. Andresson (2002).
Dabei müßte aber nicht zwingend das TLS-Protokoll in diesem Tunnel eingesetzt werden
– der Einsatz jedes anderen ULA-Protokolls wäre ebenfalls möglich. Eine aktuelle DraftVersion des PEAPs ist bei der IETF einzusehen; vgl. Palekar et al. (2003).
Dem gleichen Prinzip folgt im übrigen auch das Tunneled TLS (TTLS)-Protokoll, das
derzeit als Draft einzusehen ist; vgl. Funk und Blake-Wilson (2003).
EAP-SIM Durch EAP-SIM soll es SIM (Subscriber Identity Module)-Karten (und damit auch Mobiltelefonen) möglich werden, die 802.11-Schnittstellen zu nutzen und sich
80
mittels des 802.1x-Standards zu authentifizieren. Hiermit wird ein besonders interessanter
und sicher zunehmend wichtiger werdender Weg eingeschlagen. Derzeit liegt der ggf. zukünftige EAP-SIM-Standard noch als Draft vor; vgl. Haverinen und Salowey (2003). Er
sieht vor, die im GSM (Global System for Mobile Communications)-Standard eingesetzte
Authentifizierung so weit wie möglich unverändert zu lassen, da einige Elemente fest in
der SIM-Karte verankert sind und auch gar nicht geändert werden könnten. Bei diesem
Vorhaben sind etliche Hürden zu überwinden: So bietet – um nur eine zu nennen – eine
SIM-Karte beispielsweise nur einen 64 Bit langen Master Key, während für eine angemessene Sicherheit mindestens 128 Bit nötig wären. Dies kann ggf. kompensiert werden, wenn
zur Schlüsselerzeugung mehrere Challenge-Response-Durchläufe verknüpft werden.
Für eine kurze Einführung in diesen Versuch der Verknüpfung der GSM- mit der WLANWelt siehe auch Edney und Arbaugh (2003, S. 189 – 196).
81
5
Ausblick
Insbesondere in den letzten Monaten ist auch in Deutschland das Interesse an der WirelessLAN-Technik stark gestiegen – ausgelöst nicht zuletzt durch massive Werbeaktionen der
Internet-Provider, allen voran T-Com (HP). Aber auch von Hardware-Herstellern wird die
WLAN-Technik immer mehr als Zukunftstechnologie vor allem im Bereich des mobilen
Arbeitens erkannt. Intel (HP) beispielsweise setzt mit dem neuen Centrino-Logo für auf
Intel-Komponenten basierende Notebooks auf die Zugkräfte dieses Marktsegments.
Diese Entwicklung geht jedoch nicht einher mit einem entsprechend größeren Interesse an der nötigen Verbesserung der Sicherheitsmechanismen, die im WLAN zur Anwendung kommen. Zu viele Systeme basieren noch immer nur auf der mangelhaften WEPSicherheitsarchitektur. Darüber hinaus treten die Sicherheitsaspekte in der Öffentlichkeitsarbeit der Unternehmen zunehmend in den Hintergrund.
Erschwerend kommt die zum Teil gravierende Unwissenheit auf der Seite der Anwender
hinzu. Wird der Benutzer hier nicht weiter aufgeklärt, wird die WLAN-Technologie von ihm
irrtümlich ähnlich unbedarft eingesetzt wie beispielsweise Mobiltelefone. Niemand käme
beispielsweise auf die Idee, einen Authentifizierungsschlüssel für seinen Provider in sein
Telefon einzutragen, bevor er telefoniert.
Wie eine aktuelle Untersuchung in der Stadt London zeigt, ist bei dem überwiegenden
Teil der in der Innenstadt georteten WLANs die WEP-Sicherheitsarchitektur nicht einmal
aktiviert: Die Datenübertragung geschieht – wenn sie nicht durch VPNs geschützt wird,
was die Autoren des Berichtes allerdings für den Großteil der betroffenen Netze bezweifeln
– also völlig unverschlüsselt; vgl. Accenture (2003, S. 21). Dieses Verhalten zeigt, daß nicht
nur die Möglichkeit, WLAN-Verbindungen ausreichend abzusichern, wichtig ist, sondern
vor allem die automatische Aktivierung dieser Sicherheitsvorkehrungen: Die Absicherung
muß ähnlich wie die Authentifizierung im Mobilfunkbereich für den Benutzer so transparent
wie möglich verlaufen.
Die derzeit eingesetzte WEP-Sicherheitsarchitektur in WLANs läßt sowohl die nötige
Sicherheit als auch die entsprechende Transparenz für den Nutzer vermissen. Ein neuer
allgemeiner Sicherheitsstandard für das stark an Einfluß gewinnende WLAN, der beide
Forderungen erfüllt, ist deshalb schon lange überfällig.
Mit der in dieser Arbeit vorgestellten RSN-Sicherheitsarchitektur des IEEE 802.11iStandards werden entsprechende Schritte unternommen: Durch ein neu eingeführtes
Schlüsselmanagement, das vor allem auch die Möglichkeit besitzt, einen für den Benutzer
transparenten Schlüsselaustausch zu gewährleisten, wird endlich eine große Lücke in der
WEP-Sicherheitsarchitektur geschlossen. Die zwei neuen Verschlüsselungsprotokolle TKIP
und CCMP, die im Fall von TKIP auch eine Abwärtskompatibilität zur WEP-Technologie
bieten, beheben die gravierenden Mängel der WEP-Verschlüsselung. Insbesondere der Einsatz des Advanced Encryption Standards im CCMP erweist sich als enormer Sicherheitszugewinn. Während die Integritätssicherung in der WEP-Architektur diesen Namen kaum
verdiente, verwenden beide neuen Verschlüsselungsverfahren wesentlich sicherere Message
Integrity Codes. Schließlich bietet die RSN-Sicherheitsarchitektur mit der Einführung eines zweischichtigen Authentifizierungsmechanismus unter Verwendung des IEEE 802.1xStandards und des Extensible Authentication Protocols eine flexible Zugangskontrolle für
WLANs, die sich in bereits existierende Authentifizierungslösungen insbesondere von Firmennetzwerken integrieren läßt.
82
5. AUSBLICK
Es steht außer Frage, daß mit der RSN-Sicherheitsarchitektur ein großer Schritt für die
bessere Absicherung von WLANs bevorsteht. Wenngleich einzelne Teile der neuen Sicherheitsarchitektur keine garantierte Sicherheit bieten können, so verdient sie doch als Verbund der verschiedenen Sicherheitsmechanismen die Bezeichnung Robust Security Network;
vgl. auch Eaton (2002). Deshalb ist es richtig und wichtig, die neue Sicherheitsarchitektur
schnellstmöglich umzusetzen, damit nicht nur IT-Profis bzw. große Unternehmen sondern
vor allem auch Privatanwender und Mittelständler von der transparenten Sicherheit, die der
802.11i-Standard gewährt, profitieren. (Wobei allerdings ein sehr wichtiger Faktor für einen
Erfolg des neuen Standards die Aktivierung aller Sicherheitsmaßnahmen im Auslieferungszustand der entsprechenden Hardware ist, aber dabei auch bedacht werden muß, daß eine
große Flexibilität der Authentifizierung leider erneut Raum für mögliche Nachlässigkeiten
bei der Administration läßt.)
Ursprünglich wurde als Fertigstellungstermin des neuen IEEE 802.11i-Standards Ende
2003 angestrebt. Mittlerweile hat sich dies aber immer mehr relativiert und es ist wohl nicht
damit zu rechnen, daß der Standard schon in den nächsten Monaten ratifiziert wird. Dies
ruft erneut die Wi-Fi Alliance auf den Plan, die abermals einen eigenen Standard veröffentlichen will, der diesmal nicht nur die Kompatibilitätsprotokolle des 802.11i-Standards übernehmen soll, sondern auch die auf der Verwendung von AES basierenden Verfahren. Dieser
bereits Wi-Fi Protected Access v2 (WPA2) getaufte Standard (vgl. Wi-Fi Alliance (2003b,
S. 6 + 7)) wird also im Grunde vollständig den Spezifikationen des 802.11i-Standards entsprechen – mit dem Vorteil, daß er den Herstellern neuer WLAN-Hardware bereits viel
früher als der IEEE-Standard zur Verfügung stehen wird; vgl. Burns und Hill (2003).
Hauptgründe für die Verzögerungen bei der Task Group i des IEEE sind neben den
Bestrebungen im Zusammenhang mit der Überarbeitung des IEEE 802.1x-Standards die
Arbeiten an dem geplanten Fast-Roaming, das die Bewegung zwischen verschiedenen Access Points ohne Kommunikationsunterbrechungen oder Verlust an Sicherheit erlauben soll.
Damit bestehen auch Chancen für die WLAN-Technologie, als Motor für die Weiterentwicklung von UMTS zu dienen: Bei weiter steigendem Erfolg des WLANs und steigendem
Bedarf an Mobilität könnte bei entsprechenden Integrationsmöglichkeiten beider Technologien endlich auch der UMTS-Technologie ein Erfolgsschub bevorstehen, wenngleich auch
Analysen existieren, die in dem Aufstreben von WLAN den weiteren Abstieg von UMTS
garantiert sehen; vgl. Soreon Research GmbH (2003).
Ein Erfolg des neuen IEEE-Standards – ggf. vorerst in Form von WPA2 – scheint sicher, zumal derzeit keinerlei Alternativen existieren. Ob die dadurch angestrebte robuste
Sicherheit für WLANs aber auch Bestand haben wird, kann wie bei allen Sicherheitsmechanismen nur der tatsächliche Einsatz zeigen. Ob bereits in den nächsten Monaten, in einigen
Jahren oder sogar nie etwaige Lücken in der Sicherheitsarchitektur entdeckt und Angriffe
ggf. durch Crack-Tools automatisiert werden können, bleibt abzuwarten.
83
Literatur
Aboba, B. und P. Calhoun (2003): RADIUS Support For Extensible Authentication Protocol (EAP). Request for Comments: 2869bis (April 2003).
,→ http://www.icir.org/internet-drafts/draft-aboba-radius-rfc2869bis-12.
txt. 4.5.3
Aboba, B. und D. Simon (1999): PPP EAP TLS Authentication Protocol. Request for
Comments: 2716 (Oktober 1999).
,→ ftp://ftp.isi.edu/in-notes/rfc2716.txt. 4.5.4
Accenture (2003): WLAN: Friend or Foe? – Why we need to secure the next technology
wave.
http://www.red-m.com/pdfs/Accenture%20WLAN%20friend%20or%20foe.pdf.
,→
2.2.2, 2.3.2, 5
Aerosol (PRG): Crack-Tool zum Mitschneiden von Datenpaketen.
,→ http://www.stolenshoes.net/sniph/aerosol.html. 2.3.2
Agere Systems Inc. (2001): ORiNOCO WEPplus Whitepaper . (Oktober 2001).
,→
http://www.integritydata.com.au/WEB/Products.nsf/0/
00723512483be3a869256b280082b260/$FILE/WEPplus%20Whitepaper.pdf. 3.4.1
Agere Systems Inc. (HP): Homepage.
,→ http://www.agere.com. 3
Ahlers, E. (2002): Leinenlos – Leitfaden zum WLAN-Kauf . c’t – Magazin für Computer
Technik 25/2002, S. 200. 2.1.1, 2.1.1
AirSnort (PRG): Crack-Tool zur Ermittlung des WEP Schlüssels.
,→ http://airsnort.shmoo.com. 2.3.2, 3.4.1
Andresson, H. (2002): Wireless LAN upper layer authentication and key negotiation. RSA
Laboratories (17. Januar 2002).
,→ http://www.rsasecurity.com/rsalabs/technotes/wlanweb.doc. 4.5.4
Arbaugh, W. A.; N. Shankar und Y. C. J. Wan (2001): Your 802.11 Wireless Network
has No Clothes. Technischer Bericht, Department of Computer Science, University of
Maryland. 2.3.2
Blunk, L. und J. Vollbrecht (1998): PPP Extensible Authentication Protocol (EAP). Request for Comments: 2284 (März 1998).
Borisov, N.; I. Goldberg und D. Wagner (2001): Intercepting Mobile Communications: The
Insecurity of 802.11 . In Proceedings of the Seventh Annual International Conference on
Mobile Computing And Networkung. ACM Press, New York. 2.3.2, 2.3.2
84
LITERATURVERZEICHNIS
BSI (2002): Sicherheit im Funk-LAN (WLAN, IEEE 802.11). Projektgruppe ”Local Wireless Communication”, Bundesamt für Sicherheit in der Informationstechnik (17. Juli
2002).
,→ http://www.bsi.de/fachthem/funk_lan/wlaninfo.pdf. 1, 2.1.2, 2.2.2, 2.2.2, 2.3.2,
2.3.2
Buchmann, J. (1999): Einführung in die Kryptographie. 1. Auflage, Springer, Berlin u.a.
4.3.2, 4.4.1, 4.4.1
Burns, J. und J. Hill (2003): Evolution of WLAN Security. Meetinghouse Data Communications White Paper (4. Oktober 2003).
,→ http://www.mtghouse.com/MDC_Evolving_Standards.pdf. 3.3, 4.1, 4.5.4, 5
Daemen, J. und V. Rijmen (2001): Rijndael, the advanced encryption standard. Dr. Dobb’s
Journal 26 (3), S. 137 – 139. 4.3.2
Dierks, T. und C. Allen (1999): The TLS Protocol, Version 1.0 . Request for Comments:
2246 (Januar 1999).
Eastlake, D.; S. Crocker und J. Schiller (1994): Randomness Recommendations for Security.
Request for Comments: 1750 (December 1994).
,→ ftp://ftp.isi.edu/in-notes/rfc1750.txt. 4.2.2, 4.2.3
Eaton, D. (2002): Diving into the 802.11i Spec: A Tutorial. CommsDesign, Design Corner
(26. November 2002).
,→ http://www.commsdesign.com/design_corner/OEG20021126S0003. 4.1, 5
Edney, J. und W. A. Arbaugh (2003): Real 802.11 Security: Wi-Fi Protected Access and
802.11i. 1. Auflage, Addison Wesley, Boston u.a. 1, 2.2.2, 2.3.2, 4.2, 4.2.3, 4.3, 4.3.1,
4.3.1, 4.3.1, 4.3.2, 4.3.2, 4.3.2, 4.3.2, 4.3.2, 4.3.2, 4.3.2, 4.4.1, 4.5, 4.5.2, 4.5.2, 4.5.3, 2, 7,
4.5.4, 4.5.4, 4.5.4, 4.5.4
Etheral (PRG): Crack-Tool zur Analyse mitgeschnittener Datenpakete.
,→ http://www.etheral.com. 2.3.2
ETSI (HP): Homepage.
,→ http://www.etsi.org. 2.1
ETSI BRAN Project (1998): HIPERLAN/1 – Technical Overview.
,→
http://www.etsi.org/frameset/home.htm?/technicalactiv/hiperlan/
hiperlan1tech.htm. 2.1
ETSI BRAN Project (2000): HIPERLAN/2 – Technical Overview.
,→
http://www.etsi.org/frameset/home.htm?/technicalactiv/hiperlan/
hiperlan2tech.htm. 2.1
Fluhrer, S.; I. Mantin und A. Shamir (2001): Weaknesses in the Key Scheduling Algorithm
of RC4 . Lecture Notes in Computer Science 2259. 2.3.2, 2.3.2, 4.3.1
85
Freudl, F. (2003): WEP, Sicherheitsanalyse und mögliche Attacken. Seminararbeit am
Fachgebiet für Sicherheit in der Informationstechnik, Technische Universität Darmstadt.
http://www.sec.informatik.tu-darmstadt.de/de/lehre/WS02-03/seminar/
,→
ausarbeitungen/WEP.pdf. 2.3.1, 2.3.1, 2.3.2
Friedrich, A. (2002): Mechanismen zum Schutz von WLANs. Funkschau (21). 2.2.2
Funk, P. und S. Blake-Wilson (2003): EAP Tunneled TLS Authentication Protocol (EAPTTLS). Internet Draft (August 2003).
,→ http://www.ietf.org/internet-drafts/draft-ietf-pppext-eap-ttls-03.txt.
4.5.4
Funk Software Inc. (2003): White Paper: The Role of RADIUS in Securing 802.1x Wireless
LANs – Executive Summary.
,→ http://www.funk.com/radius/Solns/wlan_wp.asp. 4.5.3
Gast, M. S. (2002): 802.11 Wireless Networks: The Definitive Guide. 1. Auflage, O’Reilly,
Köln u.a. 2.2.2, 4.5.3
Haverinen, H. und J. Salowey (2003): EAP SIM Authentication. Internet Draft (Oktober
2003).
,→ http://www.ietf.org/internet-drafts/draft-haverinen-pppext-eap-sim-12.
txt. 4.5.4
HostAP (PRG): Crack-Tool zur Emulation eines APs mittels einer WLAN Netzwerkkarte.
,→ http://hostap.epitest.fi. 2.3.2
IANA (HP): Homepage.
,→ http://www.iana.org. 4.5.2
IEEE (1997): 802.11: Information Technology – Telecommunications and Information
Exchange Between Systems – Local and Metropolitan Area Networks – Specific Requirements, Part 11: Wireless LAN Medium Access Control (MAC) and Physical Layer
(PHY) Specifications. IEEE Standards Board (Juni 1997).
http://standards.ieee.org/reading/ieee/std/lanman/restricted/802.
,→
11-1997.pdf. 1, 2, 2.1, 2.1.1, 4.4.2
IEEE (1998): 802.2: Information Technology – Telecommunications and Information
Exchange Between Systems – Local and Metropolitan Area Networks – Specific Requirements, Part 2: Logical Link Control. IEEE Standards Board (1998).
,→
2-1998.pdf. 2.1.1
IEEE (1999a): 802.11: Information Technology – Telecommunications and Information
Exchange Between Systems – Local and Metropolitan Area Networks – Specific Requirements, Part 11: Wireless LAN Medium Access Control (MAC) and Physical Layer
(PHY) Specifications. IEEE Standards Board (1999 Edition).
,→
11-1999.pdf. 1, 2.1.1, 2.2.2, 2.3.1, 2.3.1, 2.3.1, 2.3.2, 2.3.2, 4.3.1, 4.4.1
86
IEEE (1999b): 802.11a: Supplement to IEEE Standard for Information Technology – Telecommunications and Information Exchange Between Systems – Local and Metropolitan
Area Networks – Specific Requirements, Part 11: Wireless LAN Medium Access Control
(MAC) and Physical Layer (PHY) Specifications, High-speed Physical Layer in the 5
GHz Band . IEEE-SA Standards Board (September 1999).
,→
11a-1999.pdf. 2.1.1
IEEE (1999c): 802.11b: Supplement to IEEE Standard for Information Technology – Telecommunications and Information Exchange Between Systems – Local and Metropolitan
Area Networks – Specific Requirements, Part 11: Wireless LAN Medium Access Control
(MAC) and Physical Layer (PHY) Specifications, Higher-speed Physical Layer Extension
in the 2.4 GHz Band. IEEE-SA Standards Board (September 1999).
,→
11b-1999.pdf. 2.1, 2.1.1
IEEE (2001a): 802.11b: IEEE Standard for Information Technology – Telecommunications
and Information Exchange Between Systems – Local and Metropolitan Area Networks
– Specific Requirements, Part 11: Wireless LAN Medium Access Control (MAC) and
Physical Layer (PHY) Specifications, Amandment 2: Higher-speed Physical Layer (PHY)
Extension in the 2.4 GHz Band – Corrigendum 1 . IEEE Standards Board (November
2001).
,→
11b-1999_Cor1-2001.pdf. 2.1, 2.1.1
IEEE (2001b): 802.11d: IEEE Standard for Information Technology – Telecommunications
– Specific Requirements, Part 11: Wireless LAN Medium Access Control (MAC) and
Physical Layer (PHY) Specifications, Amandment 3: Specification for Operation in
Additional Regulatory Domains. IEEE-SA Standards Board (Juni 2001).
,→
11d-2001.pdf. 2.1.1
IEEE (2001c): 802.1x: IEEE Standard for Local and Metropolitan Area Networks –
Port-Based Network Access Control. IEEE-SA Standards Board (Oktober 2001).
,→
1X-2001.pdf. 2.1.1, 4.2.3, 4.5.1, 4.5.2
IEEE (2002a): 802.11h/D3: Unapproved Draft Supplement to Standard for Telecommunications and Information Exchange Between Systems – LAN/MAN Specific Requirements,
Part 11: Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) Specifications: Spectrum and Transmit Power Management Extensions in the 5 GHz band
in Europe. IEEE Standards Department (September 2002).
,→ http://standards.ieee.org/reading/ieee/std/lanman/drafts/P802.11h.pdf.
2.1.1
IEEE (2002b): 802.11i/D3.0: Unapproved Draft Supplement to Standard for Telecommunications and Information Exchange Between Systems – LAN/MAN Specific Requirements,
87
Part 11: Wireless Medium Access Control (MAC) and Physical Layer (PHY) Specifications: Specification for Enhanced Security. IEEE Standards Department (November 2002).
,→ http://standards.ieee.org/reading/ieee/std/lanman/drafts/P802.11i.pdf.
2.1.1, 4.3, 4.3.2, 4.4.1
IEEE (2003a): 802.11g: IEEE Standard for Information Technology – Telecommunications
– Specific Requirements, Part 11: Wireless LAN Medium Access Control (MAC)
and Physical Layer (PHY) Specifications, Amandment 4: Further Higher Data Rate
Extension in the 2.4 GHz Band. IEEE Standards Board (Juni 2003).
,→
11g-2003.pdf. 2.1.1
IEEE (2003b): 802.11i/D7.0: Unapproved Draft Amendment to Standard for Telecommunications and Information Exchange Between Systems – LAN/MAN Specific Requirements, Part 11: Wireless Medium Access Control (MAC) and Physical Layer (PHY)
Specifications: Medium Access Control (MAC) Security Enhancements. IEEE Standards
Department (Oktober 2003).
,→ http://standards.ieee.org/reading/ieee/std/lanman/drafts/P802.11i.pdf.
1, 2.1.1, 4, 4.2.2, 4.2.2, 4.2.2, 4.2.3, 4.2.3, 4.3, 4.3.1, 4.3.1, 4.3.1, 4.3.1, 4.3.1, 4.3.1, 4.4.1,
4.4.1, 4.4.2, 4.5.1, 4.5.2
IEEE (2003c): 802.1x/D7.1: Unapproved Draft Amendment to Standard for Local and
Metropolitan Area Networks – Port-Based Network Access Control. IEEE-SA Standards
Board (10. Oktober 2003).
http://www.ieee802.org/1/files/private/x-REV-drafts/d7/
,→
802-1X-REV-d7-1.pdf. 4.5.1
IEEE (HP): Homepage.
,→ http://www.ieee.org. 1
IETF (HP): Homepage.
,→ http://www.ietf.org. 3.1
Intel (HP): Homepage.
,→ http://www.intel.de. 5
Intersil (2003): Wireless and related Network Standards and Organizations.
,→ http://www.intersil.com/design/prism/WirelessNetworkStandards.asp. 2.1
Intersil (HP): Homepage.
,→ http://www.intersil.com. 3.3
ISO (1999): ISO/IEC 9797-1: Information Technology – Security Techniques – Data Integrity Mechanism using a cryptographic Check Function employing a Block Cipher Algorithm,
Second Edition. Committee JTC 1 / SC 27. 4.3.2
ISO (HP): Homepage.
,→ http://www.iso.ch. 2.1.1
88
Jonsson, J. (2002): On the security of CTR + CBC-MAC . SAC – Ninth Annual Workshop
on Selected Areas of Cryptography (15. + 16. August 2002).
,→
http://csrc.nist.gov/CryptoToolkit/modes/proposedmodes/ccm/ccm-ad1.
pdf. 4.3.2
Keene, I. (2003): Das ABC der 802.11-Standards. ZDNet – Mobile Business: Wireless
SuperCenter.
http://www.zdnet.de/mobile/supercenter/wireless/knowhow/200303/
,→
80211-abc_01-wc.html. 2.1.1
Kent, S. und R. Atkinson (1998): Security Architecture for the Internet Protocol. Request
for Comments: 2401 (November 1998).
,→ ftp://ftp.isi.edu/in-notes/rfc2401.txt. 3.1
Kohl, J. und C. Neumann (1993): The Kerberos Network Authentication Service (V5).
Request for Comments: 1510 (September 1993).
,→ ftp://ftp.isi.edu/in-notes/rfc1510.txt. 3.4.3, 4.5.4
Krawczyk, H.; M. Bellare und R. Canetti (2001): HMAC: Keyed-Hashing for Message Authentication. Request for Comments: 2104 (November 2001).
Lowery, J. C. und M. Miller (2003): Securing Wireless Networks. Dell Powersolutions
08/2003, S. 114 – 118.
,→ http://ftp.us.dell.com/app/3q03-Loy.pdf. 3.3
Mann, T. (2003): Pertamunentio oder Warum WEP nicht verdreht genug ist. Seminararbeit am Fachgebiet für Sicherheit in der Informationstechnik, Technische Universität
Darmstadt.
,→
ausarbeitungen/RC4.pdf. 2.3.2, 3.4.1
Mishra, A. und W. A. Arbaugh (2002): An Initial Security Analysis of the IEEE 802.1X
Standard . Technischer Bericht, Department of Computer Science, University of Maryland.
,→ http://www.cs.umd.edu/~waa/1x.pdf. 4.5.1
MMAC (HP): Homepage.
,→ http://www.arib.or.jp/mmac/e/. 2.1
Nechvatal, J.; E. Barker; L. Bassham; W. Burr; M. Dworkin; J. Foti und E. Roback (2000):
Report on the Development of the Advanced Encryption Standard (AES). Technischer
Bericht, Computer Security Division, Information Technology Laboratory, National Institute of Standards and Technology, (2. Oktober 2000).
,→ http://csrc.nist.gov/encryption/aes/round2/r2report.pdf. 4.3.2
New Media Institute, University of Georgia (HP): Homepage für Wireless Athens Georgia
Zone (WAGz).
,→ http://www.nmi.uga.edu/research/. 1
89
NIST (1993): Federal Information Processing Standard (FIPS) 180-1, Secure Hash Standard . Technischer Bericht, National Institute of Standards and Technology, (11. Mai
1993).
,→ http://www.itl.nist.gov/fipspubs/fip180-1.htm. 4.2.2
NIST (2001): Federal Information Processing Standard (FIPS) 197, Advanced Encryption
Standard (AES). Technischer Bericht, National Institute of Standards and Technology,
(26. November 2001).
,→ http://csrc.nist.gov/publications/fips/fips197/fips-197.pdf. 4.3.2
NIST (HP): Homepage.
,→ http://www.nist.gov. 4.3.2
Palekar, A.; D. Simon; G. Zorn; J. Salowey; H. Zhou und S. Josefsson (2003): Protected
EAP Protocol (PEAP) Version 2 . Internet Draft (Oktober 2003).
,→ http://www.ietf.org/internet-drafts/draft-josefsson-pppext-eap-tls-eap-07.
txt. 4.5.4
Patel, B.; B.Aboba; W. Dixon; G. Zorn und S. Booth (2001): Securing L2TP using IPsec.
Request for Comments: 3193 (November 2001).
,→ ftp://ftp.isi.edu/in-notes/rfc3193.txt. 3.1
Potter, B. und B. Fleck (2003): 802.11 Security. 1. Auflage, O’Reilly, Köln u.a. 2.3.2, 2.3.2,
3.2, 4.5.1
Red-M (2003): 802.11 Security – What does it mean really? .
,→ http://www.red-m.com/pdfs/802.11%20Security-What%20does%20it%20mean%
20really%20(prod-rp-022d).pdf. 4.5.4
Red-M (HP): Homepage.
,→ http://www.red-m.com. 1
Richter, M. (2003): IPsec – Grundlagen. Seminararbeit am Fachgebiet für Sicherheit in
der Informationstechnik, Technische Universität Darmstadt.
,→
ausarbeitungen/IPSecI.pdf. 3.1
Rigney, C.; W. Willats und P. Calhoun (2000a): RADIUS Extensions. Request for Comments: 2869 (Juni 2000).
Rigney, C.; S. Willens; A. Rubens und W. Simpson (2000b): Remote Authentication Dial
In User Service (RADIUS). Request for Comments: 2865 (Juni 2000).
Rogaway, P.; M. Bellare; J. Black und T. Krovetz (2001): OCB: A Block-Cipher Mode of
Operation for Efficient Authenticated Encryption. Eighth ACM Conference on Computer
and Communications Security (CCS-8) (16. August 2001), S. 196 – 205.
,→ http://www.cs.ucdavis.edu/~rogaway/ocb/ocb-proc.pdf. 4.3.2
90
RSA Security (1999): PKCS #5 v2.0: Password-Based Cryptography Standard. (25. März
1999).
,→ ftp://ftp.rsasecurity.com/pub/pkcs/pkcs-5v2/pkcs5v2-0.pdf. 4.2.3
RSA Security (2001): WEP Fix using RC4 Fast Packet Keying. (17. Dezember 2001).
,→ http://www.rsasecurity.com/rsalabs/technotes/wep-fix.html. 3.2, 3.4.2
RSA Security (HP): Homepage.
,→ http://www.rsasecurity.com. 2.3.1, 3.4.2
Schmidt, M. (2002): Datenpanzer – Alternativen zur Funknetz-Verschlüsselung WEP . c’t
– Magazin für Computer Technik 04/2002, S. 178. 3.4.2, 3.4.3
Schulte, G. (1999): Wellenreiter – Technik und Standardisierung von drahtlosen Netzen.
c’t – Magazin für Computer Technik 6/1999, S. 222. 2.1.2
Soreon Research GmbH (2003): WLAN weiter auf dem Vormarsch.
,→ www.soreon.de/download/SOREON%20Flash%20WLAN%20auf%20dem%20Vormarsch.
pdf. 5
St Denis, T. (2003): Analysis of TKIP Temporal Key Integrity Protocol. (5. Juni 2003).
,→ http://libtomcrypt.org/files/tkip.pdf. 4.3.1, 4.3.1
Stubblefield, A.; J. Ioannidis und A. D. Rubin (2001): Using the Fluhrer, Mantin and
Shamir Attack to Break WEP. Technischer Bericht, AT&T Labs TD-4ZCPZZ, (21.
August 2001).
,→ http://www.cs.rice.edu/~astubble/wep/wep_attack.pdf. 2.3.2
T-Com (HP): Homepage.
,→ http://www.t-com.de. 5
Tanenbaum, A. S. (1996): Computer Networks. 3. Auflage, Prentice Hall, London u.a. 2.1.1,
4.3.2
VPN Consortium (2003): VPN Technologies: Definitions and Requirements. (Januar 2003).
,→ http://www.vpnc.org/vpn-technologies.html. 3.1
VPNC (HP): Homepage.
,→ http://www.vpnc.org/. 3.1
Walker, J. (2002a): 802.11 Security Series Part I: Key Management for WEP and TKIP.
Technischer Bericht, Intel Corporation.
,→ http://cedar.intel.com/media/pdf/wireless/80211_1.pdf. 4.5.1
Walker, J. (2002b): 802.11 Security Series Part II: The Temporal Key Integrity Protocol
(TKIP). Technischer Bericht, Intel Corporation.
,→ http://cedar.intel.com/media/pdf/security/80211_part2.pdf. 4.3.1
Walker, J. (2002c): 802.11 Security Series Part III: AES-based Encapsulations of 802.11
Data. Technischer Bericht, Intel Corporation.
,→ http://cedar.intel.com/media/pdf/security/80211_part3.pdf. 4.3.2, 4.3.2
91
Wardriving.com (HP): Homepage.
,→ http://www.wardriving.com. 2.2.2
Weatherspoon, S. (2000): Overview of IEEE 802.11b Security. Intel Technology Journal 4
(Q2).
,→ http://www.intel.com/technology/itj/q22000/pdf/art_5.pdf. 2.3.1
WEPCrack (PRG): Crack-Tool zur Ermittlung des WEP Schlüssels.
,→ http://sourceforge.net/projects/wepcrack/. 2.3.2
Whiting, D.; R. Housley und N. Ferguson (2003): Counter with CBC-MAC (CCM). Request
for Comments: 3610 (September 2003).
Wi-Fi Alliance (2002): Wi-Fi Protected Access – Overview . (31. Oktober 2002).
,→ http://www.wi-fi.org/OpenSection/pdf/Wi-Fi_Protected_Access_Overview.
pdf. 3.3
Wi-Fi Alliance (2003a): Securing Wi-Fi Wireless Networks with Today’s Technologies. (6.
Februar 2003).
,→ http://www.wi-fi.org/OpenSection/pdf/Whitepaper_Wi-Fi_Networks2-6-03.
pdf. 2.2.2, 3.1
Wi-Fi Alliance (2003b): Wi-Fi Protected Access: Strong, standards-based, interoperable security for today’s Wi-Fi networks. (29. April 2003).
,→ http://www.wi-fi.com/OpenSection/pdf/Whitepaper_Wi-Fi_Security4-29-03.
pdf. 3.3, 5
Wi-Fi Alliance (2003c): Wi-Fi Protected Access (WPA). (Version 2.0, 29. April 2003).
,→ http://www.wi-fi.com/OpenSection/protected_access.asp. 3, 3.3
Wi-Fi Alliance (HP): Homepage.
,→ http://www.wi-fi.org/. 1
Ylonen, T. (2003): SSH Transport Layer Protocol. Internet Draft (Oktober 2003).
,→ http://www.ietf.org/internet-drafts/draft-ietf-secsh-transport-17.txt.
3.2
Zorn, G. (1999): Microsoft Vendor-specific RADIUS Attributes. Request for Comments:
2548 (März 1999).
,→ ftp://ftp.isi.edu/in-notes/rfc2548.txt. 7
Zorn, G. und S. Cobb (1998): Microsoft PPP CHAP Extensions. Request for Comments:
2433 (Oktober 1998).
92

IEEE 802.11i Sicherheit in drahtlosen lokalen Netzen

Transcription

Similar documents

show thesis - Faculty of Computer Science

Wi-Fi-Sicherheit – WEP, WPA und WPA2

Hacking und Hackerabwehr

Beyond WEP - WLAN Security Revisited

style xp 3.0 crack

Organic Data: Ein sicheres, dezentralisiertes Big

Sicherheit in 802.11-Netzwerken - Fakultät für Mathematik und

TM-2009-2 - Parent Directory

Kryptologie und Datensicherheit - Diskrete Mathematik

Datensicherheitstechnik - Arbeitsgruppe Kryptographie und Sicherheit

BENUTZERHANDBUCH

Folien - Freie Universität Berlin