RMLL 2003 - Wi-Fi Security: What's Next?

Transcript

1. Wi-Fi security: What’s next? Laurent Butti laurent.butti@rd.francetelecom.com France Telecom R&D Wi-Fi security: What’s next? – p.1
2. Introduction • IEEE 802.11 legacy security mechanisms • Workarounds? • Standardization efforts and status • Open Source software status w/ new standards • Consider this presentation as a light (?) tutorial! Wi-Fi security: What’s next? – p.2
3. Legacy security mechanisms • Confidentiality • WEP (Wired Equivalent Privacy) • Based on RC4 • Integrity • CRC32 (Cyclic Redundancy Check) • Authentication • 40/104-bit Shared Secret between devices (NICs / APs) Wi-Fi security: What’s next? – p.3
4. Legacy security issues (1/2) • Confidentiality is broken • Fluhrer, Mantin and Shamir paper (August 2001): attack on RC4’s implementation in IEEE 802.11 specification • Integrity is not efficient • Shared Secret independent • No key management • No dynamic key distribution • Shared Secret distribution issues, one loss is sufficient! Wi-Fi security: What’s next? – p.4
5. Legacy security issues (2/2) • Authorization (Access Control) is based on ACLs • MAC addresses are spoofable, should be only used for identification, not for authentication • Group authentication • Difficult to accept, especially in corporate environment • Management frames are not authenticated • Layer 2 DoS attacks Wi-Fi security: What’s next? – p.5
6. Security issues history • October 2000: first publication • "Unsafe at any key size; An Analysis of the WEP encapsulation"; Jesse Walker • January 2001 - July 2001: several publications • "Security of the WEP algorithm"; University of California at Berkeley • "Your 802.11 Wireless Networks has No Clothes"; University of Maryland • August 2001: major publication • "Weaknesses in the Key Scheduling Algorithm of RC4"; Fluhrer, Mantin and Shamir Wi-Fi security: What’s next? – p.6
7. Workarounds? (1/2) • "Weak" IV filtering • Avoid particular IVs defined in Fluhrer, Mantin and Shamir paper • Goal: Fool Airsnort • But: With bsd-airtools, retreiving WEP Shared Secret is possible, but it’s longer... • "Hidden" SSID • Don’t advertise the SSID • Client’s Probe Request contains the SSID: passive eavesdrop is sufficient Wi-Fi security: What’s next? – p.7
8. Workarounds? (2/2) • Reject first 256-bytes of RC4’s output (Shamir’s recommendation) • Performance loss • Breaks Wi-Fi interoperability • Implement specific crypto-protocol for data-link privacy / integrity • Could be worse than WEP • Breaks Wi-Fi interoperability Wi-Fi security: What’s next? – p.8
9. Transient solutions? • Why?: Need of a wireless access, now! • Access was "cool & smooth"... Before all publications! • New security mechanisms are currently being drafted • These solutions should migitate security risks • Confidentiality / Integrity / Access Control: use of layer >2 secure procotols (IPsec) • Access Control: use of captive portal Wi-Fi security: What’s next? – p.9
10. Captive portal? (1/2) • Access control • Filtering engine with dynamic rules (@IP and @MAC) • All first requests are re-directed to a captive portal • Authentication / Authorization • Authentication tokens: username / password • Backend authentication server: RADIUS • Confidentiality / Integrity • No data-link privacy / integrity • Authentication tokens can (must) be protected within a SSL tunnel Wi-Fi security: What’s next? – p.10
11. Captive portal? (2/2) • Open Source solution: NoCat • First version based on Perl • First release: mid-2001 • Current release: 0.82 (May 2003) • OS: Linux, *BSD Serveur Auth Serveur Auth AP Gateway BDD Auth Internet Internet SSL Wi-Fi security: What’s next? – p.11
12. Standardization status • IEEE 802.11 TGi • Confidentiality / Integrity • Access Control: IEEE 802.1X • Authentication: IETF EAP • Key Hierarchy • Key Handshakes • WPA: A subset of IEEE 802.11 TGi Wi-Fi security: What’s next? – p.12
13. IEEE 802.11 TGi (1/2) • Specification for Robust Security • Born on March 2001 from TGe (QoS and security) • Currently draft 4.1 (June 2003) • Very active! • More than 10 drafts during last year • Intended to be ratified Q4 ’03 • Susceptible to modifications • Important: WRAP is deprecated, CCMP is mandatory • Light: Typographic changes Wi-Fi security: What’s next? – p.13
14. IEEE 802.11 TGi (2/2) • One reason to support it: • Conceptually, layer 2 security should be better than upper layer secure solutions • Goals: • New authentication and access control framework, with high flexibility • New confidentiality and integrity protocols • Access control must be performed at edge (APs) upon authentication result • Authentication methods are independent from IEEE 802.11 TGi Wi-Fi security: What’s next? – p.14
15. Confidentiality / Integrity • TKIP: Temporal Key Integrity Protocol • Short-medium term solution • Should only requires a firmware upgrade, theory! • Must migitate all know WEP security issues • Internal aspects • Based on RC4 • 48-bit IV (TKIP Sequence Counter) • Mixing function before injection in RC4 • Enhanced integrity check (keyed-MIC) Wi-Fi security: What’s next? – p.15
16. Confidentiality / Integrity • CCMP: Counter-Mode/CBC-MAC Protocol • Long term solution • Should require a hardware upgrade • Internal aspects • Based on AES • 48-bit IV (44-bit used as counter) Wi-Fi security: What’s next? – p.16
17. IEEE 802.1X (1/3) • Port Based Network Access Control • IEEE 802.1X-2001 (June 2001) • Authentication is based on EAP • Access control is upon authentication • Runs over all 802 LANs (originally intended to 802.3) • Controlled / Uncontrolled Port • Controlled: Allows data to go through if authentication is successfull • Uncontrolled: Allows authentication data to go through Wi-Fi security: What’s next? – p.17
18. IEEE 802.1X (2/3) • IEEE 802.1aa Draft 6 (June 2003) • Amendement to IEEE 802.1X-2001 • Modifications on key management frames (EAPOL-Key) • IEEE 802.1X key management was designed for wired communications • IEEE 802.11 TGi uses 802.1aa EAPOL-Key frames format • IEEE 802.1X EAPOL-Key frames format can be used for dynamic WEP-(re)keying Wi-Fi security: What’s next? – p.18
19. IEEE 802.1X (3/3) • Supplicant: 802.1X/EAP, EAP methods • Authenticator: 802.1X/EAP, RADIUS extensions • Authentication Server: EAP, EAP methods, RADIUS extensions Wi-Fi security: What’s next? – p.19
20. IETF EAP (1/2) • Extensible Authentication Protocol • RFC 2284 (March 1998) • Intended initially for PPP, but 802.1X uses it also • Goals: • Flexible authentication framework, only carries an authentication method • Authenticator is transparent, upgrades are not necessary • Authentication relies more on EAP method than EAP itself Wi-Fi security: What’s next? – p.20
21. IETF EAP (2/2) • New EAP IETF Working Group • Some specification issues • Being revised under RFC 2284bis-04 (June 2003) • Issues: • No EAP state machine • Extend type space (was 1 byte) • http://www.drizzle.com/ aboba/EAP/eapissues.html Wi-Fi security: What’s next? – p.21
22. EAP methods (1/4) • EAP-MD5: RFC 2284 (March 1998) • MD5(Identity+Challenge+Secret) • No network authentication • No dynamic keying • Not really secure • EAP-TLS: RFC 2716 (October 1999) • Strong client and/or network authentication with certificates • Dynamic keying • High level of security Wi-Fi security: What’s next? – p.22
23. EAP methods (2/4) • EAP-{SIM|AKA}: draft-11/10 (June 2003) • Strong client and network authentication for GSM/UMTS-based networks • Dynamic keying • Good level of security • Standardized by Nokia / Ericsson / Cisco Wi-Fi security: What’s next? – p.23
24. EAP methods (3/4) • EAP-TLS-EAP (PEAP): draft-06 (March 2003) • Uses TLS, then uses another EAP method, encapsulated (secured) in TLS tunnel • Could "secure" insecure methods • Asymetric authentication • Standardized by Microsoft / Cisco • EAP-TTLS: draft-02 (November 2002) • Nearly equivalent as PEAP • Was the first tunnelled authentication method available • Standardized by Funk Software Wi-Fi security: What’s next? – p.24
25. EAP methods (4/4) EAP EAP Layer Layer EAP EAP EAP TLS TLS TLS Media Media Layer Layer Driver Driver APIs APIs EAP EAP APIs APIs PPP PPP 802.3 802.3 802.5 802.5 802.11 802.11 Protection Layer Protection Layer Protection Layer MD5 MD5 MD5 AKA/SIM AKA/SIM AKA/SIM MS-CHAPv2 MS MS- -CHAPv2 CHAPv2 Wi-Fi security: What’s next? – p.25
26. Key Hierarchy (1/3) • EAP method must provide keying material • New keys are derived from EAP master key • Protect unicast and multicast traffic • MK: Master Key • Directly from a successfull EAP authentication • PMK: Pairwise Master Key • Derived from MK • Must be 256-bit Wi-Fi security: What’s next? – p.26
27. Key Hierarchy (2/3) • PTK: Pairwise Transient Key • Derived from PMK • 384/512-bit depending on cipher selection • Used to protect unicast traffic • GTK: Groupwise Transient Key • Equivalent to a random number • 40/104/128/256-bit depending on cipher selection • Used to protect multicast traffic Wi-Fi security: What’s next? – p.27
28. Key Hierarchy (3/3) Wi-Fi security: What’s next? – p.28
29. Key Handshakes • Two Key handshakes are defined: • 4-way handshake • Group key handshake • Goals: • Establish a fresh key between AP and STA • Liveness of peers • No man in the middle • Synchronizes pairwise key use Wi-Fi security: What’s next? – p.29
30. Discovery / Association Client AP Probe Request Probe Response + RSN IE (AP supports MCast /Ucast: WEP, TKIP and Auth: Dynamic Keys with 802.1X) 802.11 Open Authentication 802.11 Open Auth (success) Association Req + RSN IE (Client requests TKIP and dynamic keys with 802.1X) Association Response (success) 802.1X controlled port blocked for client Source : IEEE Wi-Fi security: What’s next? – p.30
31. Authentication 802.1X/EAP -Request Identity Client AP AAA 802.1X/EAP -Response Identity (EAP type specific) RADIUS Access Request/Identity EAP type specific mutual authentication Derive Pairwise Master Key (PMK) RADIUS ACCEPT (with PMK via MS -MPPE) 802.1X/EAP -SUCCESS Derive Pairwise Master Key (PMK) 802.1X controlled port still blocked for client Source : IEEE Wi-Fi security: What’s next? – p.31
32. 4-way Handshake Client AP EAPoL-Key(Reply Required, Unicast, ANonce ) PMK PMK Derive ANonce Derive SNonce EAPoL-Key(Unicast, SNonce, MIC, STA SSN IE) EAPoL-Key(Reply Required, Install PTK, Unicast, ANonce , MIC, AP SSN IE) Derive PTK Derive PTK EAPoL -Key(Unicast, ANonce, MIC) Install Keys Install Keys 802.1X controlled port still blocked for client Source : IEEE Wi-Fi security: What’s next? – p.32
33. Group Handshake Client AP EAPoL-Key(All Keys Installed, Reply Required, Group Rx, Key Index, Group, GNonce , MIC, GTK) GMK Derive GNonce EAPoL -Key(Group, MIC) Derive GTK Encrypt GTK field Decrypt GTK field 802.1X controlled port unblocked for client Source : IEEE Wi-Fi security: What’s next? – p.33
34. WPA (1/4) • WPA stands for Wi-Fi Protected Access • ”Standard” from Wi-Fi Alliance • IEEE 802.11 TGi Draft 3.0 (November 2002) subset • Lastest official revision 1.2 (December 2002) • What’s this? • Stable security features from IEEE 802.11 TGi D3.0 • A certification Wi-Fi security: What’s next? – p.34
35. WPA (2/4) • Goals • Have a secure solution, now! • Should avoid hardware upgrades (NICs and APs) • Must be "backward-compatible" • Provide a flexible, convenient and secure solution in all contexts (Corporate, Residential, Hot Spot) • Make business! Wi-Fi security: What’s next? – p.35
36. WPA (3/4) • Authentication • EAP methods • PSK (Pre-Shared Key): 256-bytes random number • Key distribution • IEEE 802.1X, from IEEE 802.1X-2001 specification • IEEE 802.1X, from IEEE 802.11 TGi specification • Confidentiality / Integrity • WEP, mandatory to implement • TKIP, mandatory to implement • CCMP, optional Wi-Fi security: What’s next? – p.36
37. WPA (4/4) • Roadmap • February ’03: WPA early certification began • August, 31st ’03: Mandatory WPA certification • Q3 ’04: WPA 2.0 certification? (should include ratified IEEE 802.11 TGi) • Current support • http://www.weca.net/ Wi-Fi security: What’s next? – p.37
38. Standardization conclusions • All security concerns are adressed • But management frames are not authenticated • IEEE 802.11 TGi is not ratified • But a lot work is stable • Efforts are now focused on pre-authentication • WPA is here! • Good solution, perhaps WPA will be sufficient... Wi-Fi security: What’s next? – p.38
39. Open Source solution • Supplicant / Authenticator / Authentication Server • Open Source components: • Supplicant: XSupplicant • Authenticator: Host AP • Authentication Server: FreeRADIUS Wi-Fi security: What’s next? – p.39
40. XSupplicant (1/2) • Last release 0.7 (June 2003) under GPL • Developpers: Bryan D. Payne, Chris Hessing, Terry Simons, Nick L. Petroni • Status • OS: Linux, *BSD (not yet complete), Mac OS X (not yet complete) • EAP: MD5, TLS, EAP-MS-CHAPv2, TTLS w/ PAP|CHAP|MS-CHAPv2, PEAP (in CVS) • Dynamic WEP-(re)keying Wi-Fi security: What’s next? – p.40
41. XSupplicant (2/2) • Future support • Currently testing new methods in CVS • WPA-compliant • Contact • http://www.open1x.org/ Wi-Fi security: What’s next? – p.41
42. Host AP driver (1/2) • Last release 0.0.3 (May 2003) under GPL • Developper: Jouni Malinen • Status • OS: Linux • Dynamic WEP-(re)keying Wi-Fi security: What’s next? – p.42
43. Host AP driver (2/2) • Future support • Nothing planned about security aspects • Other non Open Source driver from Jouni • WPA support • Available using other (not open source) type of licensing • Current strategy of the company Jouni work for • Difficult to predict if code will be publicly available • Contact • http://hostap.epitest.fi/ Wi-Fi security: What’s next? – p.43
44. FreeRADIUS (1/2) • Last release 0.9 (July 2003) under GPL • Developpers: Alan DeKok (main), and about 10 active developpers • Status • OS: Unixes • EAP: MD5, TLS • Cisco’s LEAP in CVS Wi-Fi security: What’s next? – p.44
45. FreeRADIUS (2/2) • Future support • PEAP and TTLS: lot of people are working on it, but Alan didn’t see any code yet (1 or 2 months to see it in CVS) • Contact • http://www.freeradius.org/ Wi-Fi security: What’s next? – p.45
46. Conclusions (1/2) • Since mid-2002: Secure deployment based on Open Source software is possible • First step: With a full PKI • EAP-TLS authentication method • Supported in XSupplicant / FreeRADIUS • Dynamic WEP-(re)keying • Second step: With a light PKI • EAP-TTLS or EAP-TLS-EAP methods • Supported in XSupplicant / FreeRADIUS (close!) • Dynamic WEP-(re)keying Wi-Fi security: What’s next? – p.46
47. Conclusions (2/2) • Next: WPA support is medium term • Supported in NIC firmwares • Perhaps authenticator WPA code will be publicly available • Support planned in XSupplicant • Idea: Support these people! • Send bug reports / feature requests Wi-Fi security: What’s next? – p.47
48. Thanks! • For you attention ;) • Feel free to contact me mailto:laurent.butti@rd.francetelecom.com Wi-Fi security: What’s next? – p.48