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.

• So, instead, let’s just add some neat encryption to 802.11 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 m1, 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 m1.

In the Beginning, there was the Plan (for WEP-PSK) cont.

3. Alice sends Bob the ciphertext (v,k XOR m1).

• 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 256

• 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 0x000000 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 212.

THE 11TH 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 ks 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 224 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 224 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

• 802.11 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?