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.)
Note
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.
Note
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.
Note
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.
Note
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.
Note
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.
Packaging
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.
Decryption
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.
Note
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.
Vulnerabilities
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.
