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

Observation
General Wi-Fi crypto is widely studied
Recover pre-sharedkey(s) protecting all
WEP traffic

Predictable pre-shared
key & dictionary attack
against handshake

Rogue AP against
enterprise networks
to steal credentials

Tornado Attack:
Recover WPA-TKIP
session keys (theoretic)

 Mainly targets pre-shared and session keys
2

What about group keys?
Group keys protect broadcast and multicast frames: All clients posses a copy of the group keySecurity of group keys not yet properly studied!
 In contrast with pre-shared & session (=pairwise) keys …
We analyze security of group
key during its full lifetime!
3

Background: group key lifetime

4

Background: group key lifetime
Group KeyThree important stages:

1. Generation (flawed RNG)

5

Background: group key lifetime
Group Key
Session Key 1

Three important stages:

1. Generation (flawed RNG)
2. Session key agreement and group
key transport (force usage of RC4)

Encrypted group
key sent to clientGroup Key
Session Key6

Background: group key lifetime
Group Key
Session Key 1

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)

Group Key
Session Key

Addressing some of these issues:
 New RNG for Wi-Fi platforms?
7

Background: sending group frames
Client A
Group Key
Session Key

Group Key
Session Key A
Session Key B
Group Key
Session Key

Client B

8

Background: sending group frames
1. Client uses pairwise key to send group frame to AP
Client A
Recv:
AP
Dest: FF:⋯:FF

Session Key A

Src:

Session Key

Client A

Client B9Background: sending group frames
1. Client uses pairwise key to send group frame to AP
2. AP broadcasts group frame using group key
Client A Only AP sends real group framesGroup KeyGroup Key

Recv: FF:⋯:FF
Dest: FF:⋯:FF
Src:
Client A
Group Key

Client B

10

Agenda: security of group keys

Flawed generation

Inject & decrypt all traffic

Force RC4 in handshake

New Wi-Fi tailored RNG
11Agenda: security of group keys

Flawed generation

Inject & decrypt all traffic

Force RC4 in handshake

New Wi-Fi tailored RNG
12How are group keys generated?
Based on a key hierarchy:
 AP randomly generates publiccounter 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!

Sampled only at boot!

PubliccounterPrivatemaster key

+1

SHA-1
Group Temporal
Key (GTK)
13

How are random numbers generated?
802.11 standard has example Random Number Generator §11.1.6a: the RNG outputs cryptographic-quality randomness“Each STA can generate cryptographic-quality random numbers. This
assumption is fundamental, as cryptographic methods require a sourceof randomness. See M.5 for suggested hardware and software methods
to achieve randomness suitable for this purpose.”14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“This clause suggests two sample techniques that can be combined withthe other recommendations of IETF RFC 4086 to harvest randomness. [..]
These solutions are expository only, to demonstrate that it is feasible toharvest randomness on any IEEE 802.11 platform. [..] they do not preclude
the use of other sources of randomness when available [..] ; in this case, themore 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.”
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 onlyInconsistent description of RNG’s security guarantees!
 How secure is the 802.11 RNG?
 How many platforms implement this RNG?

16

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

17

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
Deviates from traditional RNG design: No entropy pools being maintained
 Entropy is only collected when the RNG
is being invoked18

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 jitter19

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

Weakened 802.11 RNG

Depends on OS

Estimated ~22% of Wi-Fi networks

Open
Firmware
Custom RNG

Hostapd: /dev/random

21Surely no one implemented this…?

Weakened 802.11 RNG

Depends on OS

Estimated ~22% of Wi-Fi networks

Open
Firmware
Custom RNG

Hostapd: /dev/random

22

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!
At boot

Group master key (GMK)

SHA-1
RNG

Counter (GNONCE)

Group Temporal
Key (GTK)23

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 RT-AC51U

OpenCL~3 mins

GMK & GTK24

MediaTek: predicting the GTKDEMO25

Surely no one implemented this…?

Weakened 802.11 RNG

Depends on OS

Estimated ~22% of Wi-Fi networks

OpenFirmware
Custom RNG

Hostapd: /dev/random

26

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

Broadcom: VxWorks and eCos
Proprietary

Open Source

28

Broadcom: VxWorks and eCos Implements 802.11’s group key hierarchy Random numbers: MD5(time in microseconds)

Group master key (GMK)

RNG

SHA-1
Counter (GNONCE)

Group Temporal
Key (GTK)29

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)At boot

Group master key (GMK)

RNG

SHA-1
Counter (GNONCE)

Group Temporal
Key (GTK)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)

WRT54Gv5

OpenCL~4 mins

GMK & GTK31

Surely no one implemented this…?

Weakened 802.11 RNG

Depends on OS

Estimated ~22% of Wi-Fi networks

Open
Firmware
Custom RNG

Hostapd: /dev/random

32

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 rejected33

Agenda: security of group keys

Flawed generation

Inject & decrypt all traffic

Force RC4 in handshake

New Wi-Fi tailored RNG
34

Injecting unicast packets?
 Put unicast IP packet in a broadcast frame?
FlagsReceiverto clientFF:⋯:FF

Source IP

Destination IPData

802.11 specific Detected by “Hole 196” check
Hole 196 check done at network-layer …
… but an AP works at link-layer!
35Forging unicast frames using group key
Abuse AP to bypass Hole 196 check:
VictimAttacker

APSenderDestination

Data36

Forging unicast frames using group key
Abuse AP to bypass Hole 196 check:
1. Inject as group frame to AP
VictimAttackerAP
Flags

ReceiverFinal dest.

To APFF:⋯:FF

Victim802.11 specificSenderDestination

Data

Encrypted using group key37

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

VictimAttacker

APFlags

ReceiverFinal dest.

To APFF:⋯:FF

Victim802.11 specificSenderDestination

Data

Decrypted using group key38

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

VictimAttackerAP
Flags

ReceiverFinal dest.

To STA

VictimVictim802.11 specificSenderDestination

Data

Encrypted using session (pairwise) key39

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

VictimAttacker

APFlags

ReceiverFinal dest.

To STA

VictimVictim802.11 specificSenderDestination

Data

Decrypted using session (pairwise) key40

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 onbroadcast or multicast MAC address.

41

Agenda: security of group keys

Flawed generation

Inject & decrypt all traffic

Force RC4 in handshake

New Wi-Fi tailored RNG
42

The 4-way handshake

43

The 4-way handshake

Group key encrypted
and transmitted …
… before downgrade
attack detection!
44

The 4-way handshake

Session cipher
WPA-TKIPAES-CCMPGTK encryption
RC4AES key wrap

Group key encrypted
and transmitted …

… before downgrade
attack detection!
45

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 handshake47

Agenda: security of group keys

Flawed generation

Inject & decrypt all traffic

Force RC4 in handshake

New Wi-Fi tailored RNG
48

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 detection50

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

Questions?