How To Not Make a Secure Protocol WEP Dan Petro

What is WEP? Wired Equivalent Privacy Wireless LAN security protocol  Uses IEEE a,b,g, and n Provides certain security services Originally 64 bits, but has been extended to 128 bits and even 256 bits Easily broken Why? And How?  Fundamentally poor design choices

How does WEP work? It works like a One Time Pad Keystream is pseudorandom XOR'd with plaintext Perfectly secret ciphertext Right? What's the worst that could happen?

Design Goals of WEP Confidentiality  RC4 cipher and XOR operation Integrity  CRC of message inside plaintext Authentication?!* Availability?!

Keys Not one, but two keys.  Primary Master Key or just “key” (Secret)  Initialization Vector (Well known) Key = 40 bits IV = 24 bits  Total = 64 bits

Failure #1 ONE TIME Pad  You must never use the same key(stream) twice. In WEP, Key = PMK + IV  IV changes for each message  If an IV is ever used twice, the same keystream will be used twice IV is only 24 bits  Birthday Attack = collision every 5,000 frames.

Failure #1 What's the harm?  Cipher1 = Plaintext1 ⊕ Keystream  Cipher2 = Plaintext2 ⊕ Keystream You now know Plaintext1 ⊕ Plaintext2  If you happen to know one of the plaintexts, then you can decrypt any new ciphertext that uses the same Keystream  Full and partial knowledge No diffusion! Even worse: WEP does not specify how to select IV's.

Failure #1 Example Capture multiple Ciphertexts with the same IV Obtain a (partial) Known Plaintext Decrypt corresponding bits in the other messages.

Failure #2 Integrity Failure  Linear CRC is used for Integrity.  Not a Cryptographically Secure Hash Function Linear means distributive  CRC(a) xor CRC(b) Equals  CRC(a xor b)

Failure #2 Arbitrary packet forgery!  Even with partial knowledge. If you know the plaintext of any part of a message, you can change it. WEP sends DST IP in plaintext

Failure #2.5 IP Redirection Attack – Change every IP address to that of the attacker outside the network.

Failure #3 Authentication Fail 1) Client Hello 2) Server Plaintext Challenge (128 Bytes) 3) Client Sends Encrypted Challenge back

Failure #3 But we can change the contents of any message, remember? Observe one valid authentication.

Failure #3 Now just change the contents of this captured response to be the challenge you need!

Failure #4 Getting a “Known Plaintext Attack”  WEP does not mask the size of frames  You can see exactly how long each message is. Mix that with TCP/IP, and you get a known plaintext attack ARP messages are very short, and of known length. (28 ARP bytes + 14 Layer 1 Bytes= 42 Bytes Total)  Lots of routers automatically send tons of ARP messages constantly

Failure #4.5 ARP Replay Attack  ARP is stateless  One ARP request packet can be replayed over and over  Hosts will respond with fresh traffic as responses  Allows for an arbitrary amount of traffic to be generated in use with other attacks.  Upgrade the attack to “Chosen Plaintext”

Failure #5 No Server Authentication Rouge AP's Attacker makes another AP with the same SSID Victim connects to the wrong AP Now you have a Man- in-the-Middle

Failure #6 The Cafe Latte Attack  No authentication Clients keep a list of favorite AP's  One's they've used before When powering on, they try to connect to those AP's Stimulate traffic from client, crack key

Failure #7 If the PMK is known, all bets are off  WEP does not specify how PMKs are chosen or exchanged. It's a standard “Shared Secret” problem!  Social Engineering Use a Rouge AP  Dictionary attacks  Out of Band attacks Does your company have a piece of paper with the key laying around? It probably does.

Failure #8 Denial of Service Firstly, it is legal to jam 2.4GHz signals  Just not cell phones!  Wifi is naturally vulnerable to this But not Bluetooth! Associate / Disassociate Packets are unencrypted If there is a single malicious user on your network, he can bring the whole thing down  ARP Cache Poisoning  DOSS (Denial of Service... with Style)

Failure #9 No Session Keys! How the network's perimeters should look: How it does look:

Failure #9 Airpwn  First “displayed” at Defcon 12 Intercepts data just like with a Rouge AP Responds to HTTP traffic before the real web server can Result?  Anything you want!

The Breaks Key recovery attacks due to RC4 Fluhrer, Mantin and Shamir attack  Discovered that the first few bytes produced is highly non-random Andreas Klein  Even more correlations between key and keystream found Tews, Weinmann, and Pyshkin. (PTW)  Built upon Klein's analysis and built Aircrack- ptw  (Now Aircrack-ng)

References and links Intercepting Mobile Communications: The Insecurity of  Wikipedia  Weaknesses in the Key Scheduling Algorithm of RC4  CC-BY-SA