1 / 75

802.11i Overview

802.11i Overview. Jesse Walker Intel Corporation jesse.walker@intel.com. Presentation Objectives. Outline security problems in 802.11-1999 Communicate what IEEE 802.11i is and how it works. Agenda. What’s Wrong with WEP? Architecture Data Transfer Key Management Authentication

rtonya
Download Presentation

802.11i Overview

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. 802.11i Overview Jesse Walker Intel Corporation jesse.walker@intel.com

  2. Presentation Objectives • Outline security problems in 802.11-1999 • Communicate what IEEE 802.11i is and how it works

  3. Agenda • What’s Wrong with WEP? • Architecture • Data Transfer • Key Management • Authentication • Security Capabilities Discovery • Other Features

  4. What’s wrong with WEP? What is it? • IEEE Std 802.11-1999 defines Wireless Equivalent Privacy (WEP) • Protocol intended to effect “privacy”… • …because anyone with a radio receiver can eavesdrop! • WEP’s Goals: • Create the “privacy achieved by a wired network” • Not a well-defined, testable goal • WEP vulnerabilities discovered; WEP broken! • Walker (Oct 2000), Borisov et. al. (Jan 2001), Fluhrer-Mantin-Shamir (Aug 2001)

  5. What’s wrong with WEP? 802.11 Hdr Data 0xaa 0xaa 0x00 0x00 0x00 0x00 0x80 0x00 802.11 Hdr 802.11 Hdr IV Append ICV = CRC32(Data) Check ICV = CRC32(Data) Select and insert IV Per-packet Key = IV || RC4 Base Key RC4 Encrypt Data || ICV Remove IV from packet Per-packet Key = IV || RC4 Base Key RC4 Decrypt Data || ICV ICV Data ICV Data 24 bits How does WEP “work”?

  6. What’s wrong with WEP? Pseudo-random number generator “key stream” byte b Ciphertext data bytec = p b  Review of the cipher RC4 Plaintext data byte p Decryption works the same way: p = c b Thought experiment: what happens when p1 and p2 are encrypted under the same “key stream” byte b? c1 = p1 bc2 = p2 b Then: c1c2= (p1 b)(p2 b) = p1 p2

  7. What’s wrong with WEP? ICV Encrypted with per-packet key = IV || RC4 24 luxurious bits 802.11 Hdr IV Data Collision attacks • WEP expands each RC4 key into 224 per-packet keys  data can be recovered if IV is ever repeated with same key RC4 key must be changed at least every 224 packets or data is exposed through IV collisions! • Some implemented IV selection strategies: • Random: Collision probability Pn two packets will share same IV after n packets is P2 = 1/224 for n = 2 and Pn = Pn–1+(n–1)(1–Pn–1)/ 224 for n> 2. • 50% chance of a collision exists already after only 4823 packets!!! • Increment from 0: Collision probability = 100% after two devices transmit

  8. What’s wrong with WEP? 0xaa 0xaa 0x00 0x00 0x00 0x00 0x80 0x00 8 bytes known plaintext…  0xc0 0x15 0x7e 0xa5 0x3f 0x22 0xea 0xa1 ICV exposes 1st 8 bytes of keystream 802.11 Hdr IV Per-packet key = IV || base key: 1st 3 bytes of per-packet key exposed Data Weak key attacks • Class of RC4 weak keys exists where patterns in the 1st 3 bytes of key causes corresponding patterns in 1st few bytes of the generated RC4 key stream. • For each packet, use IV and exposed key stream to identify potential weak keys • Iterate over potential weak keys from a sequence of packets until the RC4 base key is found

  9. What’s wrong with WEP? Good guy STA Authorized WEP communications Eavesdrop and record Good guy AP Play back selections Bad guy (STA or AP) Replay attacks

  10. What’s wrong with WEP? ICV     Recv-Addr, Src-Addr, Dest-Addr 802.11 Hdr IV Data Forgery attacks 0 … … 0 1 New ICV • Sample Attack 1: • Recv-Addr, Src-Addr, Dest-Addr are all unprotected • On packets from a STA to the AP, corrupt the Dest-Addr • The AP will decrypt data and send it to the forged destination • Sample Attack 2: • create a blank message with same number of data bytes • Flip some bits and compute the ICV • XOR resulting bit-flipped message + ICV into captured message

  11. What’s wrong with WEP? Weak Keys IV Collisions Message Forgery Replay Ill-defined goals = attacker success • Aims must be translated into measurable technical objectives • Doesn’t solve the right problems to achieve goals • Securing a WLAN is like securing a submarine: closing only a few of the hatches doesn’t help • If you’re not a professional, don’t indulge in crypto design S.S. WEP

  12. Architecture Architectural Components • Goals • EAP/802.1X/RADIUS • Operational Phases • Discovery, Authentication, Key Management, Data transfer

  13. Architecture Goals • Replace WEP by protocol that properly uses encryption • Add data authenticity and integrity • Decrypted data doesn’t mean anything if you don’t know who sent it • Add proper authentication • Manufacture “fresh” keys • Can’t efficiently defeat replay without fresh keys • Encryption harder to get right without fresh keys • Tie data link keys to the authentication • Must prove each packet received is authorized

  14. Architecture Authentication Server Out of scope of 802.11i standard Wireless Station Access Point EAP-TLS EAP RADIUS UDP/IP Authentication and Key Management Architecture 802.1X (EAPoL) 802.11

  15. Architecture Authentication Server Station Access Point 802.1X authentication Security capabilities discovery RADIUS-based key distribution 802.1X key management Data protection 802.11 Operational Phases

  16. Architecture Purpose of each phase (1) • Discovery • Determine promising parties with whom to communicate • AP advertises network security capabilities to STAs • 802.1X authentication • Centralize network admission policy decisions at the AS • STA determines whether it does indeed want to communicate • Mutually authenticate STA and AS • Generate Master Key as a side effect of authentication • Use master key to generate session keys = authorization token

  17. Architecture Purpose of each phase (2) • RADIUS-based key distribution • AS moves (not copies) session key (PMK) to STA’s AP • 802.1X key management • Bind PMK to STA and AP • Confirm both AP and STA possess PMK • Generate fresh operational key (PTK) • Prove each peer is live • Synchronize PTK use

  18. Data Transfer Data Transfer Overview • 802.11i defines 2 protocols to protect data transfer • TKIP – for legacy devices only • CCMP – better security for new devices • Two protocols instead of one due to politics

  19. Data Transfer Data Transfer Requirements • Never send or receive unprotected packets • Message origin authenticity — prevent forgeries • Sequence packets — detect replays • Avoid rekeying — 48 bit packet sequence number • Eliminate per-packet key – don’t misuse encryption • Protect source and destination addresses • Use one strong cryptographic primitive for both confidentiality and integrity • Interoperate with proposed quality of service (QoS) enhancements (IEEE 802.11 TGe)

  20. Data Transfer STA AP Association Request 4-Way Handshake EAP type specific mutual authentication Allow data MPDUs protected by pairwise, group keys Allow data MPDUs protected by pairwise, group keys Group Key Handshake Association Response Filtering Begin filtering non-802.1X data MPDUs Begin filtering non-802.1X data MPDUs

  21. Data Transfer Replay Mechanisms • 48-bit IV used for replay detection • First four bits of IV indicate QoS traffic class • Remaining 44 bits used as counter • Decryption/integrity check fail if traffic class bits are altered • Sender uses single counter space, but receiver needs one for each traffic class • AES with CCM or OCB authenticated encryption • CCM is mandatory, and OCB is optional • Header authentication • Payload authentication and confidentiality

  22. Data Transfer TKIP Summary • TKIP: Temporal Key Integrity Protocol • Designed as a wrapper around WEP • Can be implemented in software • Reuses existing WEP hardware • Runs WEP as a sub-component • Meets criteria for a good standard: everyone unhappy with it

  23. Data Transfer TKIP design challenges • Mask WEP’s weaknesses… • Prevent data forgery • Prevent replay attacks • Prevent encryption misuse • Prevent key reuse • … On existing AP hardware • 33 or 25 MHz ARM7 or i486 already running at 90% CPU utilization before TKIP • Utilize existing WEP off-load hardware • Software/firmware upgrade only • Don’t unduly degrade performance

  24. Data Transfer TKIP MPDU Format

  25. Data Transfer TKIP Keys • TKIP Keys • 1 128 bit encryption key • AP and STA use the same key • TKIP’s per-packet key construction makes this kosher • 2 64-bit data integrity keys • AP, STA use different keys for transmit

  26. Data Transfer DA SA Payload 8 byte MIC Michael Authentication Key TKIP Design (1) -- Michael • Protect against forgeries • Must be cheap: CPU budget  5 instructions/byte • Unfortunately is weak: a 229 message attack exists • Computed over MSDUs, while WEP is over MPDUs • Uses two 64-bit keys, one in each link direction • Requires countermeasures: rekey on active attack, rate limit rekeying

  27. Data Transfer TKIP Countermeasures • Check CRC, ICV, and IV before verifying MIC • Minimizes chances of false positives • If MIC failure, almost certain active attack underway • If an active attack is detected: • Stop using keys • Rate limit key generation to 1 per minute

  28. Data Transfer Wireless Station Access Point Hdr Hdr Hdr Packet n Packet n + 1 Packet n TKIP Design (3) • Protect against replay • reset packet sequence # to 0 on rekey • increment sequence # by 1 on each packet • drop any packet received out of sequence

  29. Data Transfer Intermediate key Base key Transmit Address: 00-A0-C9-BA-4D-5F Per-packet key 4 msb 2 lsb Packet Sequence # TKIP Design (4) • Stop WEP’s encryption abuse • Build a better per-packet encryption key… • … by preventing weak-key attacks and decorrelating WEP IV and per-packet key • must be efficient on existing hardware Phase 1 Mixer Phase 2 Mixer

  30. Data Transfer CCMP • Mandatory to implement: the long-term solution • Based on AES in CCM mode • CCM = Counter Mode Encryption with CBC-MAC Data Origin Authenticity • AES overhead requires new AP hardware • AES overhead may require new STA hardware for hand-held devices, but not PCs • An all new protocol with few concessions to WEP • Protects MPDUs = fragments of 802.2 frames

  31. Data Transfer Counter Mode with CBC-MAC • Authenticated Encryption combining Counter (CTR) mode and CBC-MAC, using a single key • Assumes 128 bit block cipher – IEEE 802.11i uses AES • Designed for IEEE 802.11i • By D. Whiting, N. Ferguson, and R. Housley • Intended only for packet environment • No attempt to accommodate streams

  32. Data Transfer CCM Mode Overview • Use CBC-MAC to compute a MIC on the plaintext header, length of the plaintext header, and the payload • Use CTR mode to encrypt the payload • Counter values 1, 2, 3, … • Use CTR mode to encrypt the MIC • Counter value 0 Encrypted MIC Header Payload Authenticated

  33. Data Transfer ... ... E E E padding padding B1 ... Bk Bk+1 ... Br 0 0 B0 MIC Header Payload S1 ... Sm Sm S0 Sm ... A1 E Am E A0 E

  34. Data Transfer CCM Properties • CTR + CBC-MAC (CCM) based on a block cipher • CCM provides authenticity and privacy • A CBC-MAC of the plaintext is appended to the plaintext to form an encoded plaintext • The encoded plaintext is encrypted in CTR mode • CCM is packet oriented • CCM can leave any number of initial blocks of the plaintext unencrypted • CCM has a security level as good as other proposed combined modes of operation, including OCB • In particular, CCM is provably secure

  35. Data Transfer CCM Usage by CCMP • Needs one fresh 128-bit key • Same 128-bit Temporal key used by both AP and STA • CBC-MAC IV, CTR constructions make this kosher • Key configured by 802.1X • CCMP uses CCM to • Encrypt packet data payload • Protect packet selected header fields from modification

  36. Data Transfer CCMP MPDU Format

  37. Data Transfer Long-term Solution Summary • Builds on the lessons learned from IEEE 802.10 and IPsec packet protocol designs • Relies on proper use of strong cryptographic primitives • Strong security against all known attacks • Requires new hardware

  38. Data Transfer Data Transfer Summary WEPTKIP CCMP Cipher RC4 RC4 AES Key Size 40 or 104 bits 128 bits 128 bits encryption, 64 bit auth Key Life 24-bit IV, wrap 48-bit IV 48-bit IV Packet Key Concat. Mixing Fnc Not Needed IntegrityData CRC-32 Michael CCMHeader None Michael CCM Replay None Use IV Use IV Key Mgmt. None EAP-based EAP-based

  39. Key Management 802.1X Key Management • 802.11i data protocols fail without “fresh” keys • Want to use 802.1X framework • Original 802.1X key management hopelessly broken, so redesigned by 802.11i • New model: • Derive a Pairwise Master Key (PMK) • AP and STA use PMK to derive Pairwise Transient Key (PTK) • Use PTK to protect the link • Limitations: • No explicit binding to earlier association, authentication • Relies on temporality, PMK freshness for security • Keys are only as good as back-end allows

  40. Key Management Master Key (MK) Pairwise Master Key (PMK) = TLS-PRF(MasterKey, “client EAP encryption” | clientHello.random | serverHello.random) Pairwise Transient Key (PTK) = EAPoL-PRF(PMK, AP Nonce | STA Nonce | AP MAC Addr | STA MAC Addr) Analog of the WEP key Key Confirmation Key (KCK) – PTK bits 0–127 Key Encryption Key (KEK) – PTK bits 128–255 Temporal Key – PTK bits 256–n – can have cipher suite specific structure Pairwise Key Hierarchy

  41. Key Management STA AP AS Step 1: Use RADIUS to push PMK from AS to AP Step 2: Use PMK and 4-Way Handshake to derive, bind, and verify PTK Step 3: Use Group Key Handshake to send GTK from AP to STA Key Management Overview

  42. Key Management Step 1: Push PMK to AP • RADIUS: not worth talking about…

  43. Key Management Descriptor Type – 1 octet Key Information – 2 octets Key Length – 2 octets Replay Counter – 8 octets Nonce – 32 octets IV – 16 octets RSC – 8 octets Key ID – 8 octets MIC – 16 octets Data Length – 2 octets Data – n octets EAPoL Key Message

  44. Key Management STA PMK PMK EAPoL-Key(Reply Required, Unicast, ANonce) EAPoL-Key(Unicast, SNonce, MIC, STA RSN IE) EAPoL-Key(Reply Required, Install PTK, Unicast, ANonce, MIC, AP RSN IE) Install TK Install TK EAPoL-Key(Unicast, MIC) Step 2: 4-Way Handshake AP Pick Random ANonce Pick Random SNonce, Derive PTK = EAPoL-PRF(PMK, ANonce | SNonce | AP MAC Addr | STA MAC Addr) Derive PTK

  45. Key Management EAPoL-Key(All Keys Installed, ACK, Group Rx, Key Id, Group , RSC, GNonce, MIC, GTK) EAPoL-Key(Group, MIC) unblocked data traffic unblocked data traffic Step3: Group Key Handshake AP STA PTK PTK Pick Random GNonce, Pick Random GTK Encrypt GTK with KEK Decrypt GTK

  46. Key Management One Last Detail EAPoL-PRF(K, A, B, Len) R “” fori 0 to (Len+159)/160 do RR | HMAC-SHA1(K, A | B | i) return Truncate-to-len(R, Len) Example for CCMP: PTK  EAPoL-PRF(PMK, “Pairwise key expansion”, AP-Addr | STA-Addr | ANonce | SNonce, 384) Why HMAC-SHA1? • Because we couldn’t think of anything better • Because that’s what IKE and Son-of-IKE use

  47. Key Management Key Management Summary • 4-Way Handshake • Establishes a fresh pairwise key bound to STA and AP for this session • Proves liveness of peers • Demonstrates there is no man-in-the-middle between PTK holders if there was no man-in-the-middle holding the PMK • Synchronizes pairwise key use • Group Key Handshake provisions group key to all STAs

  48. Authentication Authentication Requirements • Want key tied back to authorization decision • Establish a session between AS and STA • Establish a mutually authenticated session key shared by AS and STA • Session  key is fresh • Mutually authenticated bound only to AS and STA • Defend against eavesdropping, man-in-the-middle attacks, forgeries, replay, dictionary attacks against either party • Cannot expose non-public portions of credentials • Identity protection not a goal • Can’t hide the MAC address

  49. Authentication Authentication Server Wireless Station Access Point EAP-TLS EAP RADIUS UDP/IP Authentication Components 802.1X (EAPoL) 802.11

  50. Authentication AS STA 802.1X blocks port for data traffic AP 802.1X blocks port for data traffic 802.1X/EAP-Request Identity 802.1X/EAP-Response Identity (EAP type specific) RADIUS Access Request/Identity EAP type specific mutual authentication Derive Pairwise Master Key (PMK) Derive Pairwise Master Key (PMK) RADIUS Accept (with PMK) 802.1X/EAP-SUCCESS Authentication Overview STA AP 802.1X RADIUS

More Related