• No results found

MOBILE AD HOC NETWORKS SECURITY AND KEY MANAGEMENT

2.4 Wireless Protocols

2.5.2 Standards Based Security Solutions

2.5.2.2 Weaknesses in WEP

Many flaws have been discovered in WEP framework. Notably, a paper published in 2001 (Borisov, Goldberg and Wagner 2001) described several serious weaknesses that could lead to key discovery, and these weaknesses are discussed below. WEP relies on a

secret key k shared between the communicating parties to protect the body of the

transmitted frame of data. The process of encryption is described as follows:

• Checksumming: An integrity checksum is computed on the message, c(M). The

two are concatenated to obtain a plaintext P = (M, c(M)). Note that c(M) and

therefore P do not depend on the key k.

• Encryption: The plaintext P is then encrypted using the RC4 algorithm. First, an

Initialisation Vector (IV), v, is chosen automatically. The RC4 algorithm

generates a keystream, a long series of pseudorandom bytes, as a function of the

IV and k. This keystream is denoted by RC4(v,k). Then the plaintext is exclusive

ored (XOR) denoted by with the keystream to produce the ciphertext. C = P RC4(v,k)

The receiver of the frame decrypts the message in the reverse of this process. The checksum is then checked against the decrypted plaintext by splitting it into the form (M’,c’) recomputing the checksum c(M’) and checking that it matches the received checksum ‘c’. This ensures that only frames with a valid checksum will be accepted by the receiver.

The WEP protocol was designed with three main security goals in mind.

1. Confidentiality.

2. Access control.

In all three of these cases, the security of the protocol relies on the difficulty of discovering the secret key through a brute-force attack. There are two different versions of WEP. That stated in the IEEE 802.11 standard which specified a 40 bit key, and the optional version left to individual vendors which can have a 104 bit key. The reason for the standard specifying a 40 bit key was to comply with US government regulations which only allowed the export of encryption with a maximum key size of 40 bits. This however changed in January 2000, and longer keys are now permitted. A 40 bit key is not secure against a brute-force attack with the power of today’s computers, but a 104 bit key is and will remain so for many years. However, as shall be described, an attacker would not need to mount a brute-force attack to discover the secret key, and therefore the length of the key makes no difference to the time taken to discover the key.

A well-known weakness of stream ciphers is that encrypting two messages with the same IV and key can reveal information about both messages (Borisov, Goldberg and Wagner 2001).

For example:

In other words, XORing the two ciphertexts that have been encrypted with the same IV and key together causes the keystream to cancel out and the result is the XOR of the two plaintexts. This can lead to a number of different attacks. Firstly, if the plaintext of one of the messages is already known (known plaintext attack) the plaintext of the other can be easily discovered. Secondly, even if neither plaintext is known, an attacker can

If C1 = P1 RC4(v,k)

And C2 = P2 RC4(v,k)

Then

C1 C2 = (P1 RC4(v,k)) (P2 RC4(v,k))

done by looking for two English plaintexts that XOR to the given value. Thirdly, if

there are n ciphertexts that all reuse the same keystream, then there is a problem known

as depth n. Reading traffic in depth becomes easier as n increases.

To prevent these types of attack, WEP uses per-packet IVs to vary the keystream generation process for each packet that is transmitted. However, the IV is sent in each packet unencrypted, so an attacker easily knows if an IV and therefore the key is being reused. Unfortunately, key management is not specified in the 802.11 standard, and different vendors compute the IV for the packet in different ways. Some alternate between two IVs for every packet, some randomly choose an IV for every packet, but most set the IV to zero when the WLAN card is initialised, and increment the IV by one for every packet that is sent. If the card is removed and reinserted, or the computer is rebooted, the IV is set to zero again. Even if this third method is used, a busy WLAN operating at 11 Mbps and sending 1500 byte packets at an average of 5 Mbps, will exhaust all available IVs in about half a day, and the IVs and therefore keys will begin to be reused. Worse, an implementation that randomly selects IVs will on average incur a collision of IVs every 5000 packets, which is only a few minutes worth of transmission.

Another area that WEP promises to secure is that of message authentication. Unfortunately, this implementation also suffers from a bad design and therefore fails to achieve its promise. WEP uses a CRC-32 checksum which is included as part of the encrypted payload of the packet. Cyclic Redundancy Checksums (CRCs) are designed to detect random errors in the message, but they are not and were never designed to be resilient against a malicious attacker. This weakness is exacerbated by the fact that the message payload is encrypted using a stream cipher.

Further problems with the WEP algorithm are summarised below:

• The IV is part of the key. The input for the WEP PRNG is the WEP key

concatenated with the IV, which is not a suitable way to use it.

• Small IV. The IV is given by only 24 bits, which implies a relatively small IV

space, thus causing a high probability of key stream reusing in networks with high amount of traffic.

• Small WEP key. The 40 bits WEP key is too small, since it corresponds to only

five characters. Considering that passwords are usually chosen as ASCII strings, dictionary attacks have high probability of success.

• No actual integrity protection. The ICV used in WEP is a simple CRC-32, which

is not keyed and can thus be obtained by anyone.

• No replay protection.

• The used stream cipher and the CRC are linear.

This last point means that an attacker can alter the destination IP address to his own, thus causing the reply to the message to be sent to the attacker, where it can be read. Further, there is no mutual authentication defined in the standard. This could be done, with the challenge-response procedure being repeated in the other direction, but as it was not written into the standard, it is not implemented.

It was discovered that for a baseline attack against a 128 bit WEP key, between

4000 000 and 6000 000 packets were required to discover the key (Stubblefield, Ioannidis and Rubin 2002). This represents just a few hours of traffic on a busy network.

This was something of a disaster for wireless networking as security concerns had plagued the adoption of the IEEE 802.11 standards from the beginning. Security

concerns are seen as one of the main reasons for the slow adoption of wireless networks in organisations, and consistently rank as a major concern amongst organisations who have installed wireless technology.

With the practical implementation of the FMS (Fluhrer, Mantin and Shamir) attack on a wireless network, there was now proof that WEP was not secure, and there was no secondary security standard available that could be used. This led to a flurry of activity by vendors who tried to design their own propriety security implementations. The difficulty with vendors own standards is that they will only work with equipment from the particular vendor using that technique, and they are generally not thoroughly tested before being released. This further caused concern amongst potential users of wireless networks, and so a thoroughly tested and official standard was needed quickly. What followed was the design of a new security protocol called Wi-Fi Protected Access 2 (WPA 2). This protocol was seen as being a very secure protocol, and thorough testing was planned before it would be released. However, The FMS attack was publicised in 2002, and WPA 2 was not planned for official release until 2004. There was clearly a need for an interim security protocol that would be available as a software or firmware upgrade to all Wi-Fi vendors. In conjunction with many of the vendors, the Wi-Fi Alliance developed a scaled down version of the proposed new protocol that was introduced in October 2003. It was dubbed Wi-Fi Protected Access (WPA).