Upgrade to Pro — share decks privately, control downloads, hide ads and more …

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

Laurent Butti
September 15, 2003

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

Laurent Butti

September 15, 2003
Tweet

More Decks by Laurent Butti

Other Decks in Technology

Transcript

  1. Wi-Fi security: What’s next? September 2003 Laurent Butti & Franck

    Veysset [laurent.butti,franck.veysset]@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 • Current 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 WEP 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. 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/Association Request contains the SSID: passive eavesdrop is sufficient Wi-Fi security: What’s next? – p.6
  7. 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.7
  8. 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 mitigate 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.8
  9. 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.9
  10. IEEE 802.11 TGi (1/2) • Specification for Robust Security •

    Born on March 2001 from TGe (QoS and security) • Currently draft 5.0 (August 2003) • Very active! • More than 10 drafts during last year • Intended to be ratified Q2 ’04 • Susceptible to modifications • Important: WRAP is deprecated, CCMP is mandatory • Light: Typographic changes Wi-Fi security: What’s next? – p.10
  11. IEEE 802.11 TGi (2/2) • One reason to support it:

    • Standardized 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.11
  12. Confidentiality / Integrity • TKIP: Temporal Key Integrity Protocol •

    Short-medium term solution • Should only requires a firmware upgrade, theory! • Must mitigate all known WEP security issues • (Short) 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.12
  13. Confidentiality / Integrity • CCMP: Counter-Mode/CBC-MAC Protocol • Long term

    solution • Should require a hardware upgrade • (Short) internal aspects • Based on AES • 48-bit PN (Packet Number) Wi-Fi security: What’s next? – p.13
  14. 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.14
  15. IEEE 802.1X (2/3) • IEEE 802.1aa Draft 6.1 (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.15
  16. 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.16
  17. 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.17
  18. IETF EAP (2/2) • New EAP IETF Working Group •

    Some specification issues • Being revised under RFC 2284bis-05 (September 2003) • Some 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.18
  19. 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 w/ certificates • Dynamic keying • High level of security Wi-Fi security: What’s next? – p.19
  20. 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.20
  21. 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.21
  22. 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.22
  23. Key Hierarchy (1/3) • EAP method must provide keying material

    • New keys are derived from EAP master key • Protect both unicast and multicast traffic • MSK: Master Session Key • Directly from a successfull EAP authentication • PMK: Pairwise Master Key • Derived from MSK • Must be 256-bit Wi-Fi security: What’s next? – p.23
  24. 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.24
  25. 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.26
  26. 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.27
  27. 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.28
  28. 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.29
  29. Group Key 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.30
  30. 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 • Latest 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.31
  31. 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.32
  32. WPA (3/4) • Authentication • EAP methods • PSK (Pre-Shared

    Key): 256-bit 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.33
  33. 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.wi-fi.org/ Wi-Fi security: What’s next? – p.34
  34. Standardization conclusions • All known 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 PMK-caching • EAP methods standardization is critical! • Wireless security relies on EAP • WPA is here! • Good solution, perhaps WPA should be sufficient... Wi-Fi security: What’s next? – p.35
  35. WPA support status • Hardware status (NICs and APs): •

    WPA should be a software solution, but hardware upgrade is sometimes necessary • Supplicant status: • XP support by Microsoft • XP/2000/98/Me support by Funk Software • *nix support with XSupplicant (WPA is planned) • Authenticator status: • Host AP driver supports 802.1X-2001 • Hope that WPA authenticator will be publicly available Wi-Fi security: What’s next? – p.36
  36. EAP methods support Name TLS TTLS PEAP XSupplicant (CVS) Y

    Y Y MS XP Y N N MS XP SP1 Y N Y Odyssey v2.2 Y Y Y FreeRADIUS (CVS) Y Y close MS W2003 IAS Y N Y Steel Belted v4.5 Y Y Y Cisco ACS v3.1 Y N Y Tunnelled authentication methods can be various (PAP, CHAP, EAP...) Wi-Fi security: What’s next? – p.37
  37. Deployment? • Q3 ’02: dynamic WEP-(re)keying • TLS support in

    MS XP and XSupplicant • TTLS / TLS support in Funk Software supplicant for XP/2000/Me/98 • 802.1X support in several APs • Full PKI deployment • Q3 ’03: WPA and new EAP methods • TTLS / PEAP support • WPA hardware is available (APs and NICs) • Full or light PKI deployments Wi-Fi security: What’s next? – p.38
  38. Conclusions • WPA deployment is now possible • Supported in

    NIC firmwares • Supported in commercial supplicants • Support planned in XSupplicant • But: • EAP method choice is critical • Legacy 802.1X clients are still vulnerable, because they use dynamic WEP-(re)keying • WPA only network should mitigate this! Wi-Fi security: What’s next? – p.39