May 2001
doc.: IEEE 802.11-01/230
An Inductive Chosen Plaintext
Attack against WEP/WEP2
William A. Arbaugh
University of Maryland, College Park
waa@cs.umd.edu
Submission
Slide 1
William Arbaugh, University of Maryland
May 2001
doc.: IEEE 802.11-01/230
Talk Outline
• Introduction
– WEP/WEP2
– IP
– Walker/Berkeley Attacks
• Attack Overview
• Attack Details
• Conclusions
Submission
Slide 2
William Arbaugh, University of Maryland
May 2001
doc.: IEEE 802.11-01/230
WEP/WEP2
802.11 Hdr
Data
Encapsulate
802.11 Hdr
Decapsulate
IV
Data
ICV
• Encryption Algorithm = RC4
• Per-packet encryption key = IV concatenated to a pre-shared key
•WEP: 24 bit IV
•WEP2: 128 bit IV
• WEP allows IV to be reused with any frame
• Data integrity provided by CRC-32 of the plaintext data (the “ICV”)
• Data and ICV are encrypted under the per-packet encryption key
Submission
Slide 3
William Arbaugh, University of Maryland
May 2001
doc.: IEEE 802.11-01/230
How to Read WEP Encrypted
Traffic (1)
802.11 Hdr
IV
24 luxurious bits
Data
ICV
Encrypted under Key +IV using a
Vernam Cipher
•50% chance of a collision exists already after only 4823 packets!!!
• Pattern recognition can disentangle the XOR’d recovered plaintext.
• Recovered ICV can tell you when you’ve disentangled plaintext correctly.
• After only a few hours of observation, you can recover all 224 key streams.
Submission
Slide 4
William Arbaugh, University of Maryland
May 2001
doc.: IEEE 802.11-01/230
How to Read WEP Encrypted
Traffic (2)
• Ways to accelerate the process:
– Send spam into the network: no pattern recognition
required!
– Get the victim to send e-mail to you
• The AP creates the plaintext for you!
– Decrypt packets from one Station to another via an
Access Point
• If you know the plaintext on one leg of the journey, you can
recover the key stream immediately on the other
– Etc., etc., etc.
Submission
Slide 5
William Arbaugh, University of Maryland
May 2001
doc.: IEEE 802.11-01/230
Observations
• Walker/Berkeley attacks require either:
– Depth and post analysis
– Cooperating agent for known plain text
• Can we do better?
Submission
Slide 6
William Arbaugh, University of Maryland
May 2001
doc.: IEEE 802.11-01/230
Inductive Chosen Plain Text
• Base Case: Recover an initial pseudo
random stream of length n from known
plain text.
• Inductive step: Extend size of known
pseudo random to n+1 by leveraging the
redundant information in the CRC.
Submission
Slide 7
William Arbaugh, University of Maryland
May 2001
doc.: IEEE 802.11-01/230
Base Case
• Find initial pseudo random stream of size n.
– Identify DHCP Discover messages from
externals, e.g. size, and broadcast MAC
address.
• Known source (0.0.0.0), destination
(255.255.255.255), header info
• Allows the recovery of 24 bytes of pseudo random
stream: Let n = 24
Submission
Slide 8
William Arbaugh, University of Maryland
May 2001
doc.: IEEE 802.11-01/230
Inductive Step
1. Create a datagram of size n-3 representing
an ARP request, UDP open, ICMP etc.
2. Compute ICV and append only the first
three bytes.
3. XOR with n bytes of pseudo random
stream.
4. Append last byte as the n+1 byte
Submission
Slide 9
William Arbaugh, University of Maryland
May 2001
doc.: IEEE 802.11-01/230
Inductive Step

n-3
3
Data
ICV
Pseudo Random Steam
byte
Encrypted Data
Iterate over
the 255
possibilities
802.11
Hdr
IV
Data
ICV-1
byte
n+1
Submission
Slide 10
William Arbaugh, University of Maryland
May 2001
doc.: IEEE 802.11-01/230
Inductive Step
5. Now send datagram and wait for a response.
6. If no response, try another of the 254 remaining
possibilities.
7. If there is a response, then we know:
The n+1 byte was the last byte of the ICV, thus
we have matching plaintext and ciphertext
which gives us the n+1 byte of the
pseudorandom stream.
Submission
Slide 11
William Arbaugh, University of Maryland
May 2001
doc.: IEEE 802.11-01/230
After Response
n-3
3
Data

ICV
byte
n+1
plaintext
byte
byte
n+1
ciphertext
byte
byte
n+1
pseudo
byte
Pseudo Random Steam

Encrypted Data
802.11
Hdr
IV
Data
ICV-1
byte
n+1
Submission
Slide 12
William Arbaugh, University of Maryland
May 2001
doc.: IEEE 802.11-01/230
Attack Cost
• Assume moderately aggressive attacker:
– ~100 attacker transmissions per second
– NOTE: ICV failures will not be passed to OS
and thus the attack is difficult to observe (failed
ICV counter not withstanding)
• 1.6 hours to recover 2300 byte MTU
regardless of IV and key size in worst case
• ~40 minutes in average case
Submission
Slide 13
William Arbaugh, University of Maryland
May 2001
doc.: IEEE 802.11-01/230
WEP Costs
• 46 hours to build full dictionary of
<IV,
pseudorandom> with one attacking host
(~35GB)
• But, the attack is embarrassingly parallel.
– Four attacking hosts: 11.5 hours
– Eight attacking hosts: 5.75 hours
Submission
Slide 14
William Arbaugh, University of Maryland
May 2001
doc.: IEEE 802.11-01/230
WEP2 Costs
• Prohibitive to build entire dictionary in
terms of space and time, but we don’t need
to do so.
• Because, we can still find enough
<IV,pseudorandom> pairs to find and attack
a vulnerable host on the LAN and recover
key actively, e.g. blind scans and blind
attacks.
Submission
Slide 15
William Arbaugh, University of Maryland
May 2001
doc.: IEEE 802.11-01/230
This Attack Works
1. Because of the redundant information
provided by the CRC, and
2. Because of the lack of a keyed MIC
Submission
Slide 16
William Arbaugh, University of Maryland
May 2001
doc.: IEEE 802.11-01/230
Stopping/Mitigating the Attack
1. Add a keyed MIC (stops attack)
2. Adding a replay window (mitigates attack)
3. Modifying the CRC such that it can’t be:
a. Easily determined by an attacker
b. Not linear (bit flipping attack)
(mitigates attack)
Submission
Slide 17
William Arbaugh, University of Maryland
May 2001
doc.: IEEE 802.11-01/230
Conclusions
• Fundamental problem is that both WEP and
WEP2 vulnerable to packet forgery.
• It’s easy to dismiss this attack (and the
Walker/Berkeley attacks) as “academic”.
However, it’s only a matter of time before
the attacks are implemented/scripted and
released …What then?
Submission
Slide 18
William Arbaugh, University of Maryland