Wireless networking is very popular, and since it is almost impossible to protect the signal physically, the security relies on cryptography. The first standard for wireless encryption was known as WEP ("Wired-equivalent privacy"), and was shown to be breakable. We look at the details of that in this lecture, and briefly look at the newer replacement standard.

Wireless network security

The IEEE has issued a family of standards for wireless networking, called IEEE 802.11. Currently, most hardware is based on 802.11b and 802.11g, which in their original versions could be run in "unsecured" mode, or secured with WEP ("Wired-equivalent privacy"). WEP is based on a key which is shared among all the devices which want to participate in the network. WEP is intended to protect the network from devices which do not know the key.

The stream cipher RC4

WEP employs the stream cipher algorithm RC4, which is a variable-key-size stream cipher developed in 1987 by Ron Rivest. For seven years it was proprietary, but anonymously posted on the internet in 1994. It works by computing a pseudo-random stream of bytes. The keystream is independent of the plaintext which is to be encrypted. The cipher text is obtained by XORing the plaintext with the keystream, bit by bit.

RC4 consists of two parts. The first part called the key scheduling algorithm (KSA) uses a key (which can be of any length) to initialise a vector S[0]...S[255], whose entries are a permutation of the numbers 0...255.

    // initialise S
    for i = 0 ... 255
        S[i] = i
    j = 0
    for i = 0 ... 255 {
        j = (j + S[i] + key[i mod key_length]) mod 256
        swap (S[i],S[j])
        }

The second part of RC4 called the pseudo-random generation algorithm (PRGA) manipulates S at the same time as producing the keystream:

    i = 0
    j = 0
    while (still some bytes left to encrypt/decrypt) {
        i = (i + 1) mod 256
        j = (j + S[i]) mod 256
        swap(S[i],S[j])
        output z = S[(S[i] + S[j]) mod 256]
        }

We write RC4(k) to be the stream produced by RC4, using key k. The first part of the algorithm uses the key to randomise the byte array S. The second part produces the bytes to be XORed with the plain text. Each line has a distinct notional purpose.

```
i = (i + 1) mod 256
```
makes sure every array element is used once each 256 iterations
```
j = (j + S[i]) mod 256
```
makes the output depend non-linearly on the array
```
swap(S[i],S[j])
```
makes sure the array is evolved and modified as the iteration continues
```
k = S[(S[i] + S[j]) mod 256]
```
makes sure the output sequence reveals little about the internal state of the array.

RC4 is optimised to work efficiently in software, and is the basis of several encryption schemes in current use, including WEP (the encryption standard used in wi-fi). Unfortunately, it has been shown that the first few bytes of the RC4 stream produced are significantly non-random. This vulnerability has been exploited to devise an attack on WEP. RC4 is not considered secure. (Throwing away the first few bytes from RC4 may be enough to solve this problem.)

How WEP works

Encryption in WEP uses a secret key, k, shared between an access point and a mobile node. To compute a WEP frame, the plaintext frame data M is first concatenated with its (non-cryptographic) checksum c(M), to produce M · c(M). Then, a per-packet initialization vector (IV) is prepended to the secret key, k, to create the packet key, IV · k. The RC4 stream cipher is then initialized using this packet key, and the output bytes of the cipher are XORed with the checksummed plaintext to generate the ciphertext:

C = (M · c(M)) XOR RC4(IV · k)

The actual WEP data transmitted is IV · C.

The IV is 24 bits, and the key k may be

40 bits (this is sometimes called "64 bits", since 40+24 is 64)
104 bits (sometimes called "128 bits")

Question: why did the designers of WEP decide to use RC4?

Attacking WEP

Several weaknesses were documented for WEP during the period 1999 to 2002. A devastating attack was described and implemented in 2002, by Stubblefield, Ioannidis and Rubin [1], based on results about RC4 by Fluhere, Mantin and Shamir [2]. The attack allows anyone to discover the WEP key, by analysing a few million encrypted packets. Code to do this has been circulated on the internet.

How the attack works

The attack focusses on how the first byte of the plain text is encrypted.

We guess the first byte of the plaintext packet (easy).
We use it to work out the first byte of the RC4 stream (easy).
We read a lot of WEP packets of the form IV · C in order to find an IV which places the key scheduling part of RC4 into a state which leaks information about the first byte of the key. Using that information, we guess the first byte of the key.
We repeat step 3 for the second, third, fourth byte, and so on, until we have the entire key.

Step 3 is based on a result about RC4, discovered by Fluhere, Mantin and Shamir [2]:

the RC4 key is made up on an attacker-visible part (the IV) concatenated with a secret part, and
the same secret part is used with numerous different IVs, and
the attacker can obtain the first byte of the RC4 output corresponding to each IV,

then

The steps of the attack in more detail

We guess the first byte of the plaintext packet
This is easy, because IP and ARP packets are encapsulated with 802.2, and hence have the same first plaintext byte 0xAA.
We use it to work out the first byte of the RC4 stream
This is done by taking the WEP packet IV · C. Since C = (M · c(M)) XOR RC4(IV · k), we can find the first byte of the stream by taking c XOR m, where c and m are the first byte of the ciphertext and the plaintext.

We read a lot of WEP packets of the form ( IV · C) in order to find an IV which places the key scheduling part of RC4 into a state which leaks information about the first byte of the key. Using that information, we guess the first byte of the key.

To see how this works, notice that the first byte of the stream output by RC4 is S[ S[1] + S[S[1]] ]. We know what that byte is. Can we figure out anything about the key from that?

Consider the case that the IV is of the form (3,255,X) for some byte X. (Recall that the IV is always three bytes, since that's 24 bits.) Suppose the secret part of the key starts with an unknown byte k. In that case, the RC4 key looks like this:

255

...

We can simulate the algorithm to see what we get.

Step 0

S

...

.....

Step 1

i = 0
j = 0+0+3 = 3

S

...

.....

Step 2

i = 1
j = 3+1+255 = 3 (mod 256)

S

...

.....

Step 3

i = 2
j = 3+2+X = X+5

S

X+5

...

.....

Step 4

i = 3
j = (X+5) + 1 + k = X+k+6

S

X+5

X+k+6

...

.....

Now it's pretty hard to calculate the further evolution of S. But what we have is enough to let us guess the output with non-negligible probability.

We know that the first byte of the stream will be S[ S[1] + S[S[1]] ], for the final version of S after 256 steps. After the 4th step, S[1]=0 and S[S[1]]=3, so S[ S[1] + S[S[1]] ] is X+k+6. But further steps of the algorithm might mess up S[0], S[1] and S[3]. Whether that happens or not is pseudo-random, so we can model it as genuinely random:

With probability ((255/256)²⁵²)³ = 0.05, the remaining 252 steps will not mess up these values, and the output will be X+k+6. Since we know the output and we know X, this will allow us to calculate k.
With the remaining probability of 0.95, the remaining steps will mess up those values, and the output will be essentially random, and we would not get the right value of k. But the value we do get will be essentially random.

So by choosing lots of different values of X and calculating k, we will see one particular value of k coming up with probability 0.05, and the other values coming up with probability 0.95/256 = 0.003. This will enable us to guess k.

We repeat step 3 for the second, third, fourth byte, and so on, until we have the entire key.
The calculation is essentially the same. If we know A bytes of the key so far, we can simulate the steps exactly up to step A+3, and then do a similar probabilistic analysis. The details are in [2].

The detail given above was for the 3-byte IV having the form (3,255,X). But [2] shows that many other IVs will also yield information about k. In [1], the authors show other optimisations of the attack.

Conclusion

Inspection of about 6 million packets (which can be done in a few hours on a partly-loaded network) is enough to reveal the WEP key. No specialised hardware is required (just standard network cards), and the attack is entirely passive. Script-kiddie software implementing the attack is downloadable. This is the "ultimate" attack on WEP which should now be considered completely broken.

Successors to WEP: IEEE 802.11i

Two successors to WEP have been specified.

An interim solution called WPA (wireless protected access) or WEP2 was devised, before the full version of the IEEE 802.11i specification was finished. WPA is designed to work with legacy hardware designed for WEP. Therefore, it still uses RC4, but includes a key maintainance part which periodically changes the key.
The standard IEEE 802.11i, also called WAP2, uses AES instead of RC4 and is considered fully secure. It doesn't work with older hardware.

	WEP	WPA	802.11i
Cipher Key size	RC4 40- or 104- bit encryption	RC4 128-bit encryption 64-bit authentication	AES 128-bit
Per packet key	24-bit IV concatenated with base key	48-bit IV, joined with base key by TKIP	48-bit IV
Integrity packet header	None	Source and destination addresses protected with "Michael"	CCM
Packet Data Replay detection	CRC-32 None	Michael Enforce IV sequencing	CCM Enforce IV sequencing
Key management	None

WPA interim solution

WPA is based on a key management protocol called TKIP (Temporal Key Integrity Protocol). WPA is constrained to offer compatibility with WEP-designed hardware. TKIP wraps WEP in three new elements:

A message integrity code (MIC) called "Michael", to defeat forgeries. (A MIC is just a MAC (message authentication code), but IEEE uses the acronym MIC to avoid conflict with networking MAC (media access control) as in "MAC address". Instead of using the computationally expensive MICs like HMAC-SHA1, WPA designed its own one called "Michael".)
A packet sequencing discipline, to defeat replay attacks. WEP did not specify how the 24-bit IV should be chosen, and some implementations made up a random one for each packet, while others cycled through all the possible values in order. WPA specifies that the 48-bit IV should be chosen as a sequence, to allow replay attacks to be detected.
A per-packet key mixing function, to prevent the kind of attack described above which exploits how the IV is concatenated with the base key. The mixing function takes the base key, the transmitter MAC address, and the packet sequence number as inputs, and noutputs a new per-packet RC4 key.

The following diagram, from [3], is probably copyrighted.

802.11i long-term solution

Unencumbered by legacy hardware requirements, the long-term solution uses AES (advanced encryption standard, the current standard for symmetric encryption) instead of the (now considered broken) RC4. IEEE 802.11i defines a new mode for using AES, called CCM (Counter-mode-CBC-MAC), which attempts to trade efficiency and throughput with specific features needed for wireless security, while avoiding patent or pending patents. It uses a 128-bit base key, a 64-bit MIC called CBC-MAC, and a 48-bit IV to prevent replay (just like WPA).

The process of encypting a plaintext packet and a packet sequence number works like this:

Use the packet sequence number to construct IV (used for integrity) and CTR (used for encryption)
Merge the plaintext and the packet sequence number, and compute a MIC using the base key and the IV.
Encrypt the plaintext and the MIC, using the base key and the CTR

The following diagram, from [3], is probably copyrighted.

IEEE 802.1X

WPA and WPA2 are desogmed for use with an IEEE 802.1X authentication server, which distributes different keys to each user -- this offers even greater security than the pre-shared key mode described above. The pre-shared key mode is intended for small offices and homes which do not want the cost and complexity of an 802.1X server.

References

[1] A. Stubblefield, J. Ioannidis and A. Rubin, "Using the Fluhrer, Mantin, and Shamir attack to break WEP".
[2] S. Fluhrer, I. Mantin, and A. Shamir,"Weakness in the key schedule algorithm of RC4". Proc. 4th Annual Workshop on Selected Areas in Cryptography, 2001.
[3] Jesse Walker, A History of 802.11 Security.