WEP – Wireless Encryption Protocol A. Gabriel W. Daleson CS 610 – Advanced Security Portland State University

WEP – Wired Equivalent Privacy A. Gabriel W. Daleson CS 610 – Advanced Security Portland State University

WEP: Weak Encryption Protocol A. Gabriel W. Daleson CS 610 – Advanced Security Portland State University

“It seemed like a good idea at the time” Let’s make it at least as difficult to eavesdrop on wireless traffic as wired traffic… …which, by the way, is not that hard to eavesdrop on to begin with.not that hard to eavesdrop on to begin with So, instead, let’s just add some neat encryption to a/b/g.

Ideas, Good and Bad WEP is based on RC4 RC4 is a stream cipher We use an initialization vector (IV)

In the Beginning, there was the Plan (for WEP-PSK) Alice and Bob share a private shared key (PSK) K, and Alice wants to send Bob the message m. 1.Alice calculates m 1, the message m followed by its CRC. 2.Alice takes an IV v and uses the stream RC4( v, K ) to generate a session key k of the same length as m 1.

In the Beginning, there was the Plan (for WEP-PSK) cont. 3.Alice sends Bob the ciphertext ( v, k XOR m 1 ). Alice picks a new IV for each packet.

RC4 RC4 is old. (1987) There are known attacks, including a weak key being generated with probability 1 in 256known attacks RC4 is a stream cipher; we’re probably much better off with a block cipher for this sort of application

Initialization Vectors The only requirement of the IV is that it be 24 bits long. Some Wi-Fi cards start with an IV of 0x when they’re plugged in and just increment the IV with each packet sent. It’s perfectly legal WEP to never change the IV at all!

More Initialization Vectors Even if the IVs are chosen randomly, the Birthday Paradox tells us that the chance of finding two packets with the same IV is 1 in 2 12.

THE 11 TH COMMANDMENT Thou shalt not encrypt two plaintexts with the same key, lest Eve and her Evil Empire crack your code and make a fool of ye. (Shamir 17:29)

Why? Suppose – f’rinstance – Alice used WEP with the same IV on two messages, m and n, and sent Bob (and thus Eve) the ciphertexts M and N.

Why? cont. 1 Eve – thanks to the fact that the IVs are included as plaintext along with the ciphertexts – will detect this awful mistake, and note that M = m XOR k and N = n XOR k. Eve will then calculate M XOR N, and the two k s will cancel out; this is just m XOR n.

Why? cont. 2 If Eve was able to mount a known plaintext attack, she now has the other plaintext. Even if she wasn’t, the plaintexts will be patterned enough that simple frequency analysis can get both.

The IV Dictionary Attack Eve thus sits and sniffs traffic, building a dictionary of ciphertexts, IVs, and keys (once she gets them). Every collision of IVs makes her job easier. She gets matches in virtually every other set of 4096 packets.

Other issues If the AP requires WEP use, Eve can use the keys she finds to encrypt her own messages and thus inject traffic. The PSK is no defense; even if it’s perfectly random and 4096 bits long, there will still only be 2 24 streams in use.

Defenses The problem is that there aren’t enough streams, right? So make some more! Only problem is, now it’s no longer WEP as far as the standard is concerned.

Easy Defense 1 Instead of using a static PSK and only 2 24 IVs, make more of the key vary from packet to packet. This is basically how SSL does it. (There, the whole 128-bit key can be random.)

Easy Defense 2 Get rid of RC4. (Use AES instead.) At least, no stream ciphers. Big benefit! No longer stuck using ECB mode – feedback modes like CBCs are possible.

One Last Note Where is encryption (or security, for that matter) in the OSI stack? To use feedback modes, we need the guarantee of linearity – which TCP promises. So why are we doing this down in the link layer?

The OSI Stack a/b/g + WEP, TCP, and IPSec Which layer(s) of the stack should we include confidentiality? integrity? linearity? Should these be restricted to certain layers?