May 2001 doc IEEE 802 11 01230 An

May 2001 doc. : IEEE 802. 11 -01/230 An Inductive Chosen Plaintext Attack against WEP/WEP 2 William A. Arbaugh University of Maryland, College Park waa@cs. umd. edu Submission 1 William Arbaugh, University of Maryland

May 2001 doc. : IEEE 802. 11 -01/230 Talk Outline • Introduction – WEP/WEP 2 – IP – Walker/Berkeley Attacks • Attack Overview • Attack Details • Conclusions Submission 2 William Arbaugh, University of Maryland

May 2001 doc. : IEEE 802. 11 -01/230 WEP/WEP 2 802. 11 Hdr Data Encapsulate 802. 11 Hdr Decapsulate IV Data ICV • Encryption Algorithm = RC 4 • Per-packet encryption key = IV concatenated to a pre-shared key • WEP: 24 bit IV • WEP 2: 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 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 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. Submission 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 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 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), destination (255. 255), header info • Allows the recovery of 24 bytes of pseudo random stream: Let n = 24 Submission 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 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 ICV-1 Data byte n+1 Submission 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 11 William Arbaugh, University of Maryland

May 2001 doc. : IEEE 802. 11 -01/230 After Response n-3 3 Data n+1 byte plaintext byte ICV Pseudo Random Steam n+1 byte ciphertext byte Encrypted Data n+1 byte pseudo byte 802. 11 Hdr IV Data ICV-1 byte n+1 Submission 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 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 (~35 GB) • But, the attack is embarrassingly parallel. – Four attacking hosts: 11. 5 hours – Eight attacking hosts: 5. 75 hours Submission 14 William Arbaugh, University of Maryland

May 2001 doc. : IEEE 802. 11 -01/230 WEP 2 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 attack a vulnerable host on the LAN and recover key actively, e. g. blind scans and blind attacks. Submission 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 16 William Arbaugh, University of Maryland

May 2001 doc. : IEEE 802. 11 -01/230 Stopping the Attack 1. Add a keyed MIC, or possibly 2. Adding a replay window 3. Modifying the CRC such that it can’t be: a. Easily determined by an attacker b. Not linear (bit flipping attack) Submission 17 William Arbaugh, University of Maryland

May 2001 doc. : IEEE 802. 11 -01/230 Conclusions • Fundamental problem is that both WEP and WEP 2 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 18 William Arbaugh, University of Maryland