Predicting and Abusing WPA2/802.11 Group Keys

Predicting and Abusing WPA2/802.11
Group Keys
Mathy Vanhoef - imec-DistriNet, KU Leuven
@vanhoefm

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

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!

Background: group key lifetime
4

5
Group Key Three important stages:
1. Generation (flawed RNG)

6
Group Key
Session Key 1
Encrypted group
key sent to client
Three important stages:
2. Session key agreement and group
key transport (force usage of RC4)
Group Key
Session Key

7
Group Key
Session Key 1
Group Key
Session Key
Three important stages:
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?

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
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
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

Agenda: security of group keys
11
Flawed generation
New Wi-Fi tailored RNGForce RC4 in handshake
Inject & decrypt all traffic

12
Flawed generation

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!

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.”

 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.”

 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?

802.11 RNG: main design
The 802.11 RNG is a stateless function returning 32 bytes
 Vague description, even if only expository solution
17

 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

 Collects entropy on demand
 Based on frame arrival timestamps and clock jitter
19

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
¯_(ツ)_/¯

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
Weakened 802.11 RNG Depends on OS
Custom RNG
Open
Firmware

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

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

MediaTek: predicting the GTK
DEMO
25

26
Custom RNG
Open
Firmware

Broadcom: Linux
When running on a Linux kernel:
 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

Broadcom: VxWorks and eCos
28
Open SourceProprietary

 Random numbers: MD5(time in microseconds)
29
Counter (GNONCE)
Group Temporal
Key (GTK)
SHA-1RNG

 GNONCE counter is leaked during handshake
 Attacker only has to predict master group key (GMK)
30
Counter (GNONCE)
Group Temporal
Key (GTK)
SHA-1RNG
At boot

 GNONCE counter is leaked during handshake
 Attacker only has to predict master group key (GMK)
OpenCL ~4 mins GMK & GTKWRT54Gv5
31

32
Custom RNG
Open
Firmware

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
Flawed generation

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

Forging unicast frames using group key
Abuse AP to bypass Hole 196 check:
36
AP
Victim Attacker
Sender Destination Data

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

2. AP processes and routes frame
38
AP
Victim Attacker
To AP FF:⋯:FF Victim Sender Destination Data
802.11 specific Decrypted using group key

3. AP transmits it to destination
39
Victim Attacker
AP
To STA Victim Victim Sender Destination Data
802.11 specific Encrypted using session (pairwise) key

3. AP transmits it to destination
4. Victim sees normal unicast frame
40
Victim Attacker
AP
To STA Victim Victim Sender Destination Data
802.11 specific Decrypted using session (pairwise) key

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
Flawed generation

The 4-way handshake
44
Group key encrypted
and transmitted …
… before downgrade
attack detection!

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

Attacking RC4 encryption of GTK
 RC4 Key: 16-byte IV ||16-byte secret key
 First 256 keystream bytes are dropped
46

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
Flawed generation

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

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

Predicting and Abusing
WPA2/802.11 Group Keys
Mathy Vanhoef - @vanhoefm
Questions?

Predicting and Abusing WPA2/802.11 Group Keys

More Related Content

What's hot

Viewers also liked

Similar to Predicting and Abusing WPA2/802.11 Group Keys

More from vanhoefm

Recently uploaded

Predicting and Abusing WPA2/802.11 Group Keys