CNS - 04 - User Authentication (802.11 WEP)

To check if this approach is valid we can check the menezes book, and in particular to chapter 10, page 16 which takes care of the identification and user authentication. Since in that chapter we see the protocol, as long as the challenge is random and never repats, then the protocol is valid.

Things however turned out pretty bad: indeed, even if the protocol itself was secure, in the specific way it was designed in WEP it allowed the creation of two big vulnerabilities.

---

In the previous lecture we saw that to break WEP encryption you needed to build a dictionary with \((\text{IV}, \text{RC4}(\text{IV}, k))\) couples. Well, the user authentication helps in this.

Thats because anytime a user connects, he receives a challenge from the AP, and he replies with that challenge with the encrypted version of that challenge using the secret key as well as an initalization vector. This means that considering the challenge as a plaintext, we have a known plaintext attack thanks to which we can simply extract the \(\text{RC4}(\text{IV}, k)\) that can be used to build our dictionary and break the system.

IMPORTANT: This vulnerability comes from the fact that user authentication uses the same cryptographic key which is then used later in encryption. The menezes book only tells you about specific algorithmis, not in how to build a system. Whenever you build a system, you should never ever use the same key for different services.

This gives us a good way to attack the crypto: simply use a fake AP that sends multiple challenges to each client it encounters in order to gather IV pairs. This works because the authentication is unilateral, i.e. the client does not check if the AP is a valid one or a fake one.

---

WEP Authentication is actually broken. Just by watching a valid user authenticate, a potential attacker can sniff the two packets and can compute \(\text{RC4}(\text{IV}, k)\) and \(\text{IV}\) which can be use to authenticate itself whathever challenge is given by the AP.

The vulnerability here comes from the fact that its the user who can select the \(\text{IV}\), which means that the attack can first snoop on another authentication and can then select the \(\text{IV}\) used by the other user.

This means that WEP is completely broken.

Observation: What the standardizers forgot to notice is that there are two critical aspects which had to be taken care of: who selects the challenges (which was rightly choosen), and who selects the initialization vectors (which was badly choosen). The fix would've been to let the AP choose both the challenges and the IVs.

IMPORTANT: In general in a challenge/response situation you have to make sure that the client is only able to respond and does not have any degree of freedom to select things.

---

Suppose I have a plaintext in which I want to flip certain bits.

To do this we generate our \(\text{IV}\) and we encrypt our message as well as the CRC bits with the relative keystream.

Consider now a different message, in which you have all \(0\) bits and \(1\) bits in the positions of interest of the original message (those I want to flip) and once again I generate the CRC value of such message. Then, I take the previously obtained ciphertext, and I XOR it together with the newly created message

Notice that like this I'm able to obtain a new message \(M \mathbin{\oplus} \delta\) encrypted with a correct CRC value.

---

Formally, let

\[\text{IV}, C = [M \,\, | \,\, C(M)] \mathbin{\oplus} \text{RC4}(\text{IV}, k)\]

be the encrypted message sent by the valid user to the AP. Then an attacker by doing a man in the middle attack (MITM) can choose a new message \(\delta\) as long as message \(M\), can compute \(c(\delta)\) and finally can compute

\[\begin{split} C' &= C \mathbin{\oplus} \{\delta, c(\delta)\} \\ &= \Big[\text{RC4}(\text{IV}, k) \mathbin{\oplus} \{M, c(M)\} \Big] \mathbin{\oplus} \{\delta, c(\delta)\} \\ &= \text{RC4}(\text{IV}, k) \mathbin{\oplus} \{M \mathbin{\oplus} \delta, c(M) \mathbin{\oplus} c(\delta)\} \\ &= \text{RC4}(\text{IV}, k) \mathbin{\oplus} \{M', c(M \mathbin{\oplus} \delta)\} \\ &= \text{RC4}(\text{IV}, k) \mathbin{\oplus} \{M', c(M')\} \\ \end{split}\]

at the end \(C'\) is an encrypted message with a valid CRC32 value. Since \(\delta\) can be choosen so as to flip specific bits, integrity is completely broken.

---

As long as I have one pair \((\text{IV}, \text{RC4}(\text{IV}, k)\) I can inject any message \(M\) so that it is authenticated and encrypted by simply computing \(c(M)\) and by injecting the pair to obtain

\[\text{IV}, \text{RC4}(\text{IV}, k) \mathbin{\oplus} \Big[M | c(M) \Big]\]

---

The takeways as far as integrity goes are:

1. Integrity checks must always be non linear.

2. Integrity checks must explictly include a key, since external encryption may not provide any guarantee.