Encryption in the 802.11 Standard

The 802.11 specification provides data privacy with the WEP algorithm. WEP is based on the
RC4 symmetric stream cipher. The symmetric nature of RC4 requires that matching WEP keys, either 40 or 104 bits in length, must be statically configured on client devices and access points (APs). WEP was chosen primarily because of its low computational overhead. Although 802.11-enabled PCs are common today, this situation was not the case back in 1997. The majority of WLAN devices were application-specific devices (ASDs). Examples of ASDs include barcode scanners, tablet PCs, and 802.11-based phones. The applications that run on ASDs generally do not require much computational power, so as a result, ASDs have meager CPUs. WEP is a simple-to-implement algorithm that you can write in as few as 30 lines of code, in some cases. The low overhead incurred by WEP made it an ideal encryption algorithm to use on ASDs.

To avoid the ECB mode of encryption, WEP uses a 24-bit IV, which is concatenated to the key
before being processed by the RC4 cipher. Figure 4-5 shows a WEP-encrypted frame, including the IV.

The IV must change on a per-frame basis to avoid IV collisions. IV collisions occur when the same IV and WEP key are used, resulting in the same key stream being used to encrypt a
frame. This collision gives attackers a better opportunity to guess the plaintext data by
seeing similarities in the ciphertext. The point of using an IV is to prevent this scenario, so it is important to change the IV often. Most vendors offer per-frame IVs on their WLAN devices.


The 802.11 specification requires that matching WEP keys be statically configured on both
client and infrastructure devices. You can define up to four keys on a device, but you can use only one at a time for encrypting outbound frames. Figure 4-6 shows a Cisco Aironet client configuration screen for WEP configuration.



In addition to data encryption, the 802.11 specification provides for a 32-bit value that functions as an integrity check for the frame. This check tells the receiver that the frame has arrived without being corrupted during transmission. It augments the Layer 1 and Layer 2 frame check sequences (FCSs), which are designed to check for transmission-related errors.

The ICV is calculated against all fields in the frame using a cyclic redundancy check (CRC)-32 polynomial function. The sender calculates the values and places the result in the ICV field. The ICV is included in the WEP-encrypted portion of the frame, so it is not plainly visible to eavesdroppers. The frame receiver decrypts the frame, calculates an ICV value, and compares what it calculates against what has arrived in the ICV field. If the values match, the frame is considered to be genuine and untampered with. If they don't match, the frame is discarded. Figure 4-8 diagrams the ICV operation.