WEP Privacy Mechanics

Let's look at WEP mechanics in more detail. This section looks at the various aspects of WEP, including the encryption exchanges and mechanics, RC4, how an initialization vector (IV) is generated and handled, and finally, how keys are generated and distributed.

WEP mechanisms (the encapsulation of data frames to attempt to provide message confidentiality and message integrity) are aimed at achieving wired characteristics on the wireless connection.


The main difference between the wired world and the wireless world?besides the lack of wires?is the signals being transmitted in the air. All the assumptions made in the wired world (resilience against casual eavesdropping, the signals being confined to a wire, and the ability to curtail LAN connections to a physical jack in the wall) are invalid. In the wired world, a connection can be detected, but in the wireless world, anyone can listen and capture packets (actually not anybody, but clients in the coverage area) without a trace?in other words, undetectable passive sniffing.

In WEP, the packets are encrypted so that listeners cannot make sense of the garbled bits; this achieves the confidentiality equivalent of the wired environment. Moreover, entities are authenticated before they are allowed to join the network and get the keys to decrypt the information. In a way, this gives the equivalency of a "wall jack."


The first version of WEP is the mobility-as-an-exception-to-static-networks view. Actually, as you will see in Chapter 7, "EAP Authentication Protocols for WLANs," and Chapter 8, "WLAN Encryption and Data Integrity Protocols," by applying 802.11i and 802.1x paradigms, the standards consider the mobility natively by treating wireless in its own right and enhance the security, management, and control. Also note that the standardization work is still in progress and has a long way to go before becoming truly mobile.

WEP Processing Model

The 802.11 specification details the WEP processing model, as shown in Figure 5-4. The following sections look at each part of the diagram.

Figure 5-4. WEP Processing Model

RC4 Algorithm

The encryption algorithm used by WEP is the RC4. RC4 is a symmetric algorithm (it uses the same key for encryption and decryption) and is a stream cipher. (The key is a stream that is operated against the plaintext to produce the cipher text.)


A stream cipher can encipher various sizes of data, as opposed to a block cipher, which is constrained to a fixed block size.

RC4 has two phases: key stream generation and encryption. Key stream generation is a set of state machine and mixing operations that result in a pseudorandom stream of bits. The key setup takes a seed, which is the key as referred to outside the RC4 machine. After the state table is initialized, the values are used to generate a key stream. The fundamental encryption operation really is an XOR of the plaintext with the generated key stream.


RC4 has an interesting history. It was invented in 1987 by Ron Rivest of RSA Security Inc. and was never published. It was a trade secret until 1994, when a program to encrypt and decrypt using RC4 was anonymously published in the cyberpunks mailer?the only public documentation. RSA still holds the trademark on the name RC4 (not on the algorithm), so one needs to license it to use the name RC4 in products. Some people call it ARCFOUR and try to circumvent this, but the legality is questionable.

RC4 is used in many products, including Lotus Notes, and is indicated in many specifications, including the cellular digital packet data (CDPD) specification for wireless packet data access over cellular networks.

Data and Integrity

WEP includes the data and the integrity as plaintext to the RC4 engine #3 in Figure 5-4. The CRC-32 algorithm is employed to generate an integrity check value (ICV) 4 bytes long, and the ICV is concatenated to the data. The CRC-32 algorithm is specified in RFC 3309.

Seed and Keylength

The RC4 engine takes the data (#2 in Figure 5-4, the plaintext + ICV) and the seed (#4 in Figure 5-4, essentially the "key"). The seed is generated using a 24-bit initialization vector (IV) and a 40-bit key, which essentially gives the 64-bit key length. Implementations improved on this and have added a 104-bit key, thus achieving a 128-bit key length.


RC4 can use key lengths of 1 to 256 bytes (for example, 1 to 2048 bits). Initially, 802.11 chose the 40-bit key because of export restrictions.

IV Generation

The IV is usually generated starting at 0 and incrementing by one. Some implementations might start at a random number and count forward. In any case, because the IV is only 24 bits, it has a finite value and needs to be reset. The IV is sent, in clear, as a part of the data frame.


You might ask the significance of an IV. An IV adds the randomness to the encryption. Without the IV, the same plaintext and key would result in the same cipher text, which can result in some interesting forms of data leakage (called the residual effect). The IV essentially alters the key stream even when used with the same key.

The importance of the IV in this instance is to prevent collisions; therefore, the randomness of the IVs themselves is not a requirement. The IV can indeed be a counter. One of the problems with WEP is that the industry failed to define this requirement; therefore, implementations exist that enable the IV to wrap or remain static. This has been fixed, but there are still a few legacy systems that do not adhere to IV generation to avoid collisions.

Key Generation and Selection

WEP uses static preshared keys. There are many mechanisms to share keys. WEP defines a key vector that can hold four keys, distributed out of band. The key ID used in each communication is sent as part of the data frame. As previously discussed, it also has facilities to have a key mapped to arbitrary pairs of communicating entities. The key can be 40 bits or 104 bits in length and can be generated by a paraphrase in some installations. In most installations, the key is entered as a set of hexadecimal digits.


The use of the four keys is independent of WEP. 802.11i and WPA make use of these four key IDs for temporal key integrity protocol (TKIP) and cyberblock-chaining message-authentication-code (CCMP).

It is important to note that WEP lacks key management mechanisms. Thus, these static keys are used to perpetually improve the adversary's chance of discovering the keys over a period of time.


The data frame consists of the IV, the key ID, and the encrypted data resulting from the RC4 engine. The header and FCS are always there as part of the standard frame. From #9 in Figure 5-4, you can see that the frame, IV, and FCS are all clear, whereas the data and ICV (CRC-32) are encrypted as a result of a cryptographic operation.


The decryption process is almost the reverse of the encryption process. The receiver is able to resolve the key (either by the key number or, if it is null, the first key, key0) and the IV. Using those two inputs, the RC4 engine can decrypt the data stream. The receiver then extracts the last 4 bytes, calculates the ICV of the remaining stream using the CRC-32 algorithm, and verifies the integrity.


The advantage of the stream cipher is implementation optimization. That is, only the encipher logic (such as the keystream generation) is required because the XOR is a symmetric operation.


WEP, as defined in the 802.11 specification, was deemed unsecure by the community for a variety of reasons (which Chapter 6 describes in detail). The choice of IV, the transmission of the IV, the ICV mechanisms, weak IVs and RC4 weak keys, and the nonscalability of key distribution all came under close scrutiny and were found to be less secure. (The IV can be predicted, and IVs can be reused, leading to cryptographic insecurities because the strength of the key is diminished, the IV is transmitted in cleartext, and moreover, 802.11 does not specify how IVs are selected.) There are well-documented vulnerabilities with WEP that could allow a passive attacker to actually devise the key. WEP also does not provide suitable message integrity, because CRC32 is a checksum mechanism and not a message integrity mechanism. Above all, WEP lacks strong mutual authentication, which is a requirement for establishing a secure channel. To provide a secure WLAN, various mechanisms are being developed by extending and augmenting the WEP security to true mobility (including guest access), still maintaining the administrative control in the wired world. The following chapters exhibit many aspects of this.