Wired Equivalent Privacy (WEP)

WEP became the encryption standard for the 802.11, but by no means is it a powerhouse in security. It has many known weaknesses in how the encryption is implemented. The basic problem with WEP is that it uses a cipher not suitable for the environment it operates in. WEP uses a stream-cipher known as RC4 in synchronous mode for encrypting data packets. Using the synchronous stream ciphers, the loss of a single bit of a data stream causes the loss of all data following the lost bit, including data in the following packets. This is because data loss de-synchronizes the keystream generators at the two end points. Since data loss is widespread in the wireless medium, it is impossible to use a synchronous stream cipher across 802.11 frame boundaries. The problem however, is not in the RC4 algorithm, but in the fact that the stream cipher is not suitable for wireless medium where placket loss is widespread.

Instead of selecting a block ciphers suitable for wireless medium, 802.11 tries to solve the synchronization problem of stream ciphers by shifting synchronization requirements from a session to a packet. Secure Socket Layer (SSL) uses RC4 at the application layer successfully because SSL operates over a consistent data channel that does not lose any data packets, guaranteeing perfect synchronization between the two end points. SSL uses only one key per session. The key does not need to be replaced every packet since the end points are synchronized and RC4 can produce the same keystream at both ends using the session key. In contrast to the wireless medium, 802.11 changes keys for every packet because the synchronization between the end-points is not perfect and is subject to packet loss. This way each packet can be encrypted and decrypted disregarding the previous packets loss. The same key is used to encrypt and decrypt the data. The WEP encryption algorithm works the following way:

WEP Encryption

Two processes are applied to the plaintext data. One encrypts the plaintext; the other protects the data from being modified by unauthorized personnel. The 40-bit secret key is connected with a 24-bit Initialization Vector (IV) resulting in a 64-bit total key size. The resulting key is input into the Pseudo-random Number Generator (PRNG ). The PRNG ( RC4 ) outputs a pseudorandom key sequence based on the input key. The resulting sequence is used to encrypt the data by doing a bitwise XOR. The result is encrypted bytes equal in length to the number of data bytes that are to be transmitted in the expanded data plus four bytes. This is because the key sequence is used to protect the 32-bit Integrity Check Value(ICV) as well as the data. The picture below illustrates how the WEP is encrypted.

To prevent unauthorized data modification, an integrity algorithm , CRC-32 operates on the plaintext to produce the ICV. The ciphertext is obtained by computing the ICV using CRC-32 over the message plaintext à connecting the ICV to the plaintext à choosing a random initialization vector (IV) and connecting this to the secret key à inputting the secret key + IV into the RC4 algorithm to produce pseudorandom key sequence à encrypting the plaintext + ICV by doing a bitwise XOR with the pseudorandom key sequence under RC4 to produce the ciphertext à communicating the IV to the peer by placing it in front of the ciphertext. The IV, plaintext, and ICV triplet forms the actual data sent in the data frame.

 

WEP Decryption

The IV of the incoming message is used to generate the key sequence necessary to decrypt the incoming message. Combining the ciphertext with the proper key sequence will give the original plaintext and ICV. The decryption is verified by performing the Integrity check algorithm on the recovered plaintext and comparing the output of the ICV' to the ICV submitted with the message.
If the ICV' is not equal to the ICV, the received message is in error, and an error indication is sent to the MAC management and back to the sending station. The following diagram exhibits how WEP is decrypted.

 

Authentication

The same, shared key used to encrypt and decrypt the data frames is also used to authenticate the station. There are two types of 802.11b authentication. One is called the Open System authentication, which is the default authentication service that doesn't have authentication. This may sounds contradicting, but you will see what it does later in the page. The other is called the shared key authentication. The shared key authentication involves a shared key to authenticate the station to the access point, as the name states. It is considered a security hazard to have both the encryption key and authentication key be the same. There is also a method where stations and access points can utilize the WEP alone without shared key authentication, by using WEP merely as an encryption engine, which can be done in open system mode.

The open system authentication is a void authentication. The station can associate with any access points and listen to all the data that are sent in plaintext. This authentication is not secure, but is implemented for its ease of use. This authentication is not recommended, and is only used when the network administrator does not want to deal with security.

The Shared key authentication is a better authentication than the open system authentication. For a station to use the shared key authentication, it must implement WEP. The secret shared key resides in each station's MIB in a write-only form and is therefore only available to the MAC coordinator. The picture below shows how the key is distributed to each station.

First a requesting station sends an Authentication frame to the access point. When the access point receives the initial authentication frame, the access point will reply with an authentication frame containing 128 bytes of random challenge text generated by the WEP engine in standard form. The requesting station will then copy that text into the authentication frame, encrypt it with a shared key, and then send the frame to the responding station. The receiving access point will decrypt the value of the challenging text using the same shared key and compare it to the challenging text sent earlier. If a match occurs, the responding station will reply with an authentication indicating a successful authentication. If there isn't a match, the responding access point will send back a negative authentication.