Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Predicting and Abusing WPA2/802.11 Group Keys

2,542 views

Published on

We analyze the generation and management of WPA2 group keys. These keys protect broadcast and multicast Wi-Fi traffic. We discovered several issues and illustrate their importance by decrypting all group (and unicast) traffic of a typical Wi-Fi network.

First we show that the 802.11 random number generator is flawed by design, and provides an insufficient amount of entropy. This is confirmed by predicting randomly generated group keys on several platforms. We then examine whether group keys are securely transmitted to clients. Here we discover a downgrade attack that forces usage of RC4 to encrypt the group key when transmitted in the 4-way handshake. The per-message RC4 key is the concatenation of a public 16-byte initialization vector with a secret 16-byte key, and the first 256 keystream bytes are dropped. We study this peculiar usage of RC4, and find that capturing 2 billion handshakes can be sufficient to recover (i.e., decrypt) a 128-bit group key. We also examine whether group traffic is properly isolated from unicast traffic. We find that this is not the case, and show that the group key can be used to inject and decrypt unicast traffic. Finally, we propose and study a new random number generator tailored for 802.11 platforms.

Published in: Science

Predicting and Abusing WPA2/802.11 Group Keys

  1. 1. Predicting and Abusing WPA2/802.11 Group Keys Mathy Vanhoef - imec-DistriNet, KU Leuven @vanhoefm
  2. 2. Observation General Wi-Fi crypto is widely studied 2 Recover pre-shared key(s) protecting all WEP traffic Tornado Attack: Recover WPA-TKIP session keys (theoretic) Rogue AP against enterprise networks to steal credentials Predictable pre-shared key & dictionary attack against handshake  Mainly targets pre-shared and session keys
  3. 3. What about group keys? Group keys protect broadcast and multicast frames:  All clients posses a copy of the group key Security of group keys not yet properly studied!  In contrast with pre-shared & session (=pairwise) keys … 3 We analyze security of group key during its full lifetime!
  4. 4. Background: group key lifetime 4
  5. 5. Background: group key lifetime 5 Group Key Three important stages: 1. Generation (flawed RNG)
  6. 6. Background: group key lifetime 6 Group Key Session Key 1 Encrypted group key sent to client Three important stages: 1. Generation (flawed RNG) 2. Session key agreement and group key transport (force usage of RC4) Group Key Session Key
  7. 7. Background: group key lifetime 7 Group Key Session Key 1 Group Key Session Key Three important stages: 1. Generation (flawed RNG) 2. Session key agreement and group key transport (force usage of RC4) 3. Usage (abuse to decrypt all traffic) Addressing some of these issues:  New RNG for Wi-Fi platforms?
  8. 8. Background: sending group frames 8 Group Key Session Key Group Key Session Key Group Key Session Key A Session Key B Client A Client B
  9. 9. Background: sending group frames 9 1. Client uses pairwise key to send group frame to AP Session Key Session Key A Client A Client B Recv: AP Dest: FF:⋯:FF Src: Client A
  10. 10. Background: sending group frames 10 1. Client uses pairwise key to send group frame to AP 2. AP broadcasts group frame using group key  Only AP sends real group frames Group Key Group Key Group Key Client B Client A Recv: FF:⋯:FF Dest: FF:⋯:FF Src: Client A
  11. 11. Agenda: security of group keys 11 Flawed generation New Wi-Fi tailored RNGForce RC4 in handshake Inject & decrypt all traffic
  12. 12. Agenda: security of group keys 12 Flawed generation New Wi-Fi tailored RNGForce RC4 in handshake Inject & decrypt all traffic
  13. 13. How are group keys generated? Based on a key hierarchy:  AP randomly generates public counter and secret master key  Derives group temporal key (GTK) from these values every hour Entropy only introduced at boot  Bad design: if master key is leaked, all group keys become known! 13 Public counter Private master key +1 SHA-1 Group Temporal Key (GTK) Sampled only at boot!
  14. 14. How are random numbers generated? 802.11 standard has example Random Number Generator  §11.1.6a: the RNG outputs cryptographic-quality randomness 14 “Each STA can generate cryptographic-quality random numbers. This assumption is fundamental, as cryptographic methods require a source of randomness. See M.5 for suggested hardware and software methods to achieve randomness suitable for this purpose.”
  15. 15. How are random numbers generated? 802.11 standard has example Random Number Generator  §11.1.6a: the RNG outputs cryptographic-quality randomness  Annex M.5: proposed RNG is expository only 15 “This clause suggests two sample techniques that can be combined with the other recommendations of IETF RFC 4086 to harvest randomness. [..] These solutions are expository only, to demonstrate that it is feasible to harvest randomness on any IEEE 802.11 platform. [..] they do not preclude the use of other sources of randomness when available [..] ; in this case, the more the merrier. As many sources of randomness as possible should be gathered into a buffer, and then hashed, to obtain a seed for the PRNG.”
  16. 16. How are random numbers generated? 802.11 standard has example Random Number Generator  §11.1.6a: the RNG outputs cryptographic-quality randomness  Annex M.5: proposed RNG is expository only 16 Inconsistent description of RNG’s security guarantees!  How secure is the 802.11 RNG?  How many platforms implement this RNG?
  17. 17. 802.11 RNG: main design The 802.11 RNG is a stateless function returning 32 bytes  Vague description, even if only expository solution 17
  18. 18. 802.11 RNG: main design The 802.11 RNG is a stateless function returning 32 bytes  Vague description, even if only expository solution  Collects entropy on demand 18 Deviates from traditional RNG design:  No entropy pools being maintained  Entropy is only collected when the RNG is being invoked
  19. 19. 802.11 RNG: main design The 802.11 RNG is a stateless function returning 32 bytes  Vague description, even if only expository solution  Collects entropy on demand  Based on frame arrival timestamps and clock jitter 19
  20. 20. 802.11 RNG: entropy sources Frame arrival times:  Collected by starting & aborting handshakes  Problem: AP will be blacklisted by clients Clock jitter and drift:  No minimum time resolution  small clock jitter  Hence contains only low amount of randomness 20 ¯_(ツ)_/¯
  21. 21. Surely no one implemented this…? 21 Depends on OS Custom RNG Open Firmware Hostapd: /dev/random Estimated ~22% of Wi-Fi networks Weakened 802.11 RNG
  22. 22. Surely no one implemented this…? 22 Weakened 802.11 RNG Depends on OS Custom RNG Open Firmware Hostapd: /dev/random Estimated ~22% of Wi-Fi networks
  23. 23. MediaTek RNG: overview Uses custom Linux drivers:  Implements 802.11’s group key hierarchy  But GNONCE “counter” is randomly refreshed on GTK rekey  Based on the 802.11 RNG using only clock jitter  Uses jiffies for current time: equals uptime of the AP  Predict both GMK and GNONCE to determine group key! 23 Counter (GNONCE) Group master key (GMK) Group Temporal Key (GTK) SHA-1 RNG At boot
  24. 24. MediaTek RNG: key search  Jiffies have at best millisecond accuracy  GMK: generated at boot  limited set of possible values  GNONCE: depends on uptime of router (and clock skew)  Uptime is leaked in beacons  Capture encrypted broadcast packet and search for key  24 OpenCL ~3 mins GMK & GTKRT-AC51U
  25. 25. MediaTek: predicting the GTK DEMO 25
  26. 26. Surely no one implemented this…? 26 Weakened 802.11 RNG Depends on OS Custom RNG Open Firmware Estimated ~22% of Wi-Fi networks Hostapd: /dev/random
  27. 27. Broadcom: Linux When running on a Linux kernel:  Implements 802.11’s group key hierarchy  Randomness from /dev/urandom “Mining your Ps and Qs” by Heninger et al.:  /dev/urandom might be predictable at boot  All group keys might be predictable on old kernels 27
  28. 28. Broadcom: VxWorks and eCos 28 Open SourceProprietary
  29. 29. Broadcom: VxWorks and eCos  Implements 802.11’s group key hierarchy  Random numbers: MD5(time in microseconds) 29 Counter (GNONCE) Group master key (GMK) Group Temporal Key (GTK) SHA-1RNG
  30. 30. Broadcom: VxWorks and eCos  Implements 802.11’s group key hierarchy  Random numbers: MD5(time in microseconds)  GNONCE counter is leaked during handshake  Attacker only has to predict master group key (GMK) 30 Counter (GNONCE) Group master key (GMK) Group Temporal Key (GTK) SHA-1RNG At boot
  31. 31. Broadcom: VxWorks and eCos  Implements 802.11’s group key hierarchy  Random numbers: MD5(time in microseconds)  GNONCE counter is leaked during handshake  Attacker only has to predict master group key (GMK) OpenCL ~4 mins GMK & GTKWRT54Gv5 31
  32. 32. Surely no one implemented this…? 32 Weakened 802.11 RNG Depends on OS Custom RNG Open Firmware Estimated ~22% of Wi-Fi networks Hostapd: /dev/random
  33. 33. Open Firmware Open Firmware:  An open source BIOS  Supports client Wi-Fi functionality in BIOS (!)  Randomness from boot time & linear congruential generator Hostapd:  Based on 802.11 group key hierarchy  Also injects new entropy on group rekeys!  Reads from /dev/random on boot & when clients join  If not enough entropy available, connections are rejected 33
  34. 34. Agenda: security of group keys 34 Flawed generation New Wi-Fi tailored RNGForce RC4 in handshake Inject & decrypt all traffic
  35. 35. Injecting unicast packets?  Put unicast IP packet in a broadcast frame? 35 Hole 196 check done at network-layer … … but an AP works at link-layer! Flags Receiver to client FF:⋯:FF Source IP Destination IP Data 802.11 specific  Detected by “Hole 196” check
  36. 36. Forging unicast frames using group key Abuse AP to bypass Hole 196 check: 36 AP Victim Attacker Sender Destination Data
  37. 37. Forging unicast frames using group key Abuse AP to bypass Hole 196 check: 1. Inject as group frame to AP 37 AP Victim Attacker Flags Receiver Final dest. To AP FF:⋯:FF Victim Sender Destination Data 802.11 specific Encrypted using group key
  38. 38. Forging unicast frames using group key Abuse AP to bypass Hole 196 check: 1. Inject as group frame to AP 2. AP processes and routes frame 38 AP Victim Attacker Flags Receiver Final dest. To AP FF:⋯:FF Victim Sender Destination Data 802.11 specific Decrypted using group key
  39. 39. Forging unicast frames using group key Abuse AP to bypass Hole 196 check: 1. Inject as group frame to AP 2. AP processes and routes frame 3. AP transmits it to destination 39 Victim Attacker AP Flags Receiver Final dest. To STA Victim Victim Sender Destination Data 802.11 specific Encrypted using session (pairwise) key
  40. 40. Forging unicast frames using group key Abuse AP to bypass Hole 196 check: 1. Inject as group frame to AP 2. AP processes and routes frame 3. AP transmits it to destination 4. Victim sees normal unicast frame 40 Victim Attacker AP Flags Receiver Final dest. To STA Victim Victim Sender Destination Data 802.11 specific Decrypted using session (pairwise) key
  41. 41. Decrypting all traffic ARP poison to broadcast MAC address  Poison both router and clients  Can decrypt network-layer protocols: IPv4, IPv6, … Countermeasure:  Don’t forward broadcast frames to a unicast destination  Even better: AP should simply ignore frames received on broadcast or multicast MAC address. 41
  42. 42. Agenda: security of group keys 42 Flawed generation New Wi-Fi tailored RNGForce RC4 in handshake Inject & decrypt all traffic
  43. 43. The 4-way handshake 43
  44. 44. The 4-way handshake 44 Group key encrypted and transmitted … … before downgrade attack detection!
  45. 45. The 4-way handshake 45 Group key encrypted and transmitted … … before downgrade attack detection! Session cipher GTK encryption WPA-TKIP RC4 AES-CCMP AES key wrap
  46. 46. Attacking RC4 encryption of GTK  RC4 Key: 16-byte IV ||16-byte secret key  First 256 keystream bytes are dropped 46
  47. 47. Attacking RC4 encryption of GTK  RC4 Key: 16-byte IV ||16-byte secret key  First 256 keystream bytes are dropped Recover repeated encryptions of GTK:  Similar in spirit to RC4 NOMORE attack  Requires ~231 handshakes: takes >50 years Countermeasures:  Disable WPA-TKIP & RC4  Send GTK after handshake 47
  48. 48. Agenda: security of group keys 48 Flawed generation New Wi-Fi tailored RNGForce RC4 in handshake Inject & decrypt all traffic
  49. 49. An improved 802.11 RNG Entropy present on al Wi-Fi chips?  Wi-Fi signals & background noise Spectral scan feature in commodity chips:  Can generate 3 million samples / second  First XOR samples in firmware  Extract & manage resulting entropy using known approaches Additional research needed: performance under jamming? 49
  50. 50. Conclusion Lessons learned: 1. Always check quality of RNG 2. Let AP ignore group-addressed frames 3. Don’t put “expository” security algo’s in a specification 4. Don’t transmit sensitive data before downgrade detection 50
  51. 51. Predicting and Abusing WPA2/802.11 Group Keys Mathy Vanhoef - @vanhoefm Questions?

×