Notes

Outline

An Inductive Chosen Plaintext Attack against WEP/WEP2 William A. Arbaugh University of Maryland, College Park waa@cs.umd.edu

Talk Outline Introduction WEP/WEP2 IP Walker/Berkeley Attacks Attack Overview Attack Details Conclusions

WEP/WEP2

How to Read WEP Encrypted Traffic (1)

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.

Observations Walker/Berkeley attacks require either: Depth and post analysis Cooperating agent for known plain text Can we do better?

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.

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

Inductive Step Create a datagram of size n-3 representing an ARP request, UDP open, ICMP etc. Compute ICV and append only the first three bytes. XOR with n bytes of pseudo random stream. Append last byte as the n+1 byte

Inductive Step

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.

After Response

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

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

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.

This Attack Works Because of the redundant information provided by the CRC, and Because of the lack of a keyed MIC

Stopping/Mitigating the Attack Add a keyed MIC (stops attack) Adding a replay window (mitigates attack) Modifying the CRC such that it can’t be: Easily determined by an attacker Not linear (bit flipping attack) (mitigates attack)

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?