WEP Cryptographic Operations

Communications security has three major objectives. Any protocol that attempts to secure data as it travels across a network must help network managers to achieve these goals. Confidentiality is the term used to describe data that is protected against interception by unauthorized parties. Integrity means that the data has not been modified. Authentication underpins any security strategy because part of the reliability of data is based on its origin. Users must ensure that data comes from the source it purports to come from. Systems must use authentication to protect data appropriately. Authorization and access control are both implemented on top of authentication. Before granting access to a piece of data, systems must find out who the user is (authentication) and whether the access operation is allowed (authorization).

WEP provides operations that attempt to meet these objectives, though they often fail under serious scrutiny or attack. Frame body encryption supports confidentiality. An integrity check sequence protects data in transit and allows receivers to validate that the received data was not altered in transit. In practice, the operations offered by WEP are not strong and require additional strengthening measures, as discussed in the next two chapters.

WEP Data Processing

Confidentiality and integrity are handled simultaneously, as illustrated in Figure 5-3. Before encryption, the frame is run through an integrity check algorithm, generating a hash called an integrity check value (ICV). The ICV protects the contents against tampering by ensuring that the frame has not changed in transit. The frame and the ICV are both encrypted, so the ICV is not available to casual attackers.

Figure 5-3. WEP operations

As input, WEP requires three items:

• The payload to be protected, which comes from the upper layer protocol stack.
• A secret key, used in frame encryption. Depending on implementation, keys may be specified as a string of key bits, or by key number. WEP allows four keys to be stored simultaneously.
• An initialization vector, used along with the secret key in frame transmission.

After processing, WEP has a single output:

• An encrypted frame, ready for transmission over an untrusted network with enough information to enable decryption at the remote end.

WEP data transmission

Driver software and the interface hardware are responsible for processing the data and sending out the encrypted packet, using the following sequence:

1. The 802.11 frame is queued for transmission. It consists of a frame header and the payload. WEP protects only the payload of the 802.11 MAC, and leaves the 802.11 frame header, as well as any lower-layer headers, intact.
2. An integrity check value (ICV) is calculated over the payload of the 802.11 MAC frame. It is calculated over the frame payload, so it starts at the first bit of the SNAP header, and goes up to the last data bit in the body. The 802.11 frame check sequence has not yet been calculated, so it is not included in the ICV calculation. The ICV used by WEP is a Cyclic Redundancy Check (CRC), a point that will be expanded on later.
3. The frame encryption key, or WEP seed, is assembled. WEP keys come in two parts: the secret key, and the initialization vector (IV). Stream ciphers will produce the same key stream from the same key, so an initialization vector is used to produce different stream ciphers for each transmitted frame. To reduce the occurrence of encryption with the same key stream, the sending station prepends the IV to the secret key. 802.11 does not place any constraints on the algorithm used to choose IVs; some products assign IVs sequentially, while others use a pseudorandom hashing algorithm. IV selection has some security implications because poor IV selection can compromise keys.
4. The frame encryption key is used as the RC4 key to encrypt the 802.11 MAC payload from step 1 and the ICV from step 2. The encryption process is often assisted with dedicated RC4 circuitry on the card.
5. With the encrypted payload in hand, the station assembles the final frame for transmission. The 802.11 header is retained intact. Between the 802.11 MAC header and the encrypted payload, a WEP header is inserted. In addition to the IV, the WEP header includes a key number. WEP allows up to four keys to be defined, so the sender must identify which key is in use. Once the final header is assembled, the 802.11 FCS value can be calculated over the entire MAC frame from the start of the header to the end of the (encrypted) ICV.

Decryption happens in the reverse order. As with any other transmission on the wireless network, the FCS is validated to ensure that the frame received was not corrupted in transit. To decrypt the protected part of the frame, the receiver will take its secret key, prepend the IV, and generate the key stream. With the decrypted data, it can then validate the ICV. Once the ICV is successfully validated, the packet data can be passed to the appropriate upper-layer protocol depending on the content of the SNAP header.

WEP key length

In theory, WEP can be used with keys of any length because RC4 does not require the use of any particular key size. Most products implement one of two key lengths, though. The only key length present in the standard is a 64-bit WEP seed, of which 40 bits are shared as a secret between the two communicating stations. Vendors have used a variety of names for the standard WEP mode: "standard WEP," "802.11-compliant WEP," "40-bit WEP," "40+24-bit WEP," or even "64-bit WEP." I personally feel that the last term is a stretch, based on hoodwinking the consumer with the length of the shared key and not the size of the shared secret, but it has become somewhat standard throughout the industry.

It is also common to implement a longer key length, typically with a 128-bit WEP seed, of which 104 bits are a kept secret. This is referred to as "WEP-104" by many documents, though it is almost always called "128-bit WEP" by sales literature. It is rare, though not unheard of, to use a third key length of 128 secret bits, which results in a 152-bit WEP seed. Confusingly, this rare implementation is often also called "128-bit WEP," although the differing key lengths makes it incompatible with WEP-104. One vendor even offers the option of using 256-bit secret keys with WEP, although the incremental security from such a long key is dubious.

In a well-designed cryptographic system, additional security can be obtained by using a longer key. Each additional bit doubles the number of potential keys and, in theory, doubles the amount of time required for a successful attack. WEP, however, is not a well-designed cryptographic system, and the extra bits in the key buy you very little. The best publicly disclosed attack against static WEP can recover the key in seconds, no matter what its length is.

Types of WEP keys

WEP can employ two different types of keys. Mapped keys protect traffic between a particular source and receiver. Mapped keys are sometimes referred to as unicast keys or station keys because they are well-suited to protect unicast traffic. In an infrastructure network, data is always transferred between a station and the access point serving it. 802.11 frames have both a receiver address and a destination address. Unicast traffic may have many different destination addresses, but every unicast frame transmitted in an infrastructure network will use the MAC address of the AP as its receiver address. All unicast traffic to or from a particular station can be encrypted by a single mapping key. Default keys, which are also referred to as broadcast keys, are used when no mapping relationship exists between two 802.11 stations. Default keys are a natural fit for broadcast and multicast frames because group addresses represent multiple stations and therefore cannot support key mapping relationships.

Manual (static) versus automatic (dynamic) WEP

802.11 does not specify any particular key distribution mechanism for use with WEP. As far as WEP is concerned, keys magically appear. Early WEP implementations relied on manual key distribution. Administrators were responsible for distributing a single default key to all stations in the network, usually manually. Key updates were also manual. In practice, most network deployments wound up using the same key for a very long time due to the high management overhead in changing the key. For this reason, WEP without any key distribution mechanism is often called manual WEP or static WEP.

Manual keys are an awful idea. Managing key distribution across a whole network of access points is very difficult. Keys protect data, and should therefore be changed whenever somebody with knowledge of the key leaves the organization. In theory, a well designed cryptographic system tries to limit the use of a key to as narrow a purpose as possible just in case a key is compromised. Static WEP used the same key for all frames transmitted by every station, which worsens the consequences of a key compromise.

Static WEP should not be used without a clear reason to do so. Static WEP is better than nothing, but little more can be said in its favor. It is effective for deterring casual attacks, but will not withstand determined assault. Many low-power devices such as 802.11 phones, handheld bar code scanners, and even some PDAs may not support anything better than static WEP. Until they can be replaced, static WEP offers the only possible link layer security for these devices.

Better solutions are based on dynamic WEP. Rather than a single key distributed to all stations, each station uses two keys. One is a key mapping key, shared between the station and access point, used to protect unicast frames. The second key is a default key, shared by all stations in the same service set, that protects broadcast and multicast frames. The encryption keys used by the clients are distributed using key encryption keys derived from strong authentication protocols that will be discussed in the next chapter.

Dynamic WEP offers significant advantages over static WEP solutions. At the highest level, the scope of each key is limited. Keys are used less often, and the result of compromising a key is lessened by using it to protect less traffic. Attackers can still mount assaults on the keys, but they have much less data to work for each key, making attacks more time-consuming. Nearly as important, dynamic keys can, as the name implies, change. At periodic intervals, the keys can be refreshed by the access point, which requires attackers to throw out accumulated data and start the assault on a key over again. By configuring short rekeying intervals, significant mitigation against attacks on keys is possible. Dynamic WEP solutions will be discussed later in this chapter.

WEP key numbering and storage

WEP keys have an associated number so that up to four keys may be defined on an 802.11 station. In the beginning, the WEP key number was meant to help facilitate changing the key across the network. Rather than switch every station to a new key simultaneously, the new key could be defined across the network and stations could be gradually switched. If, for example, an organization used key number 0 and wished to change it, key number 1 could be defined on the network. Rather than change all stations at the same time to the new key, stations could be configured to start using key number 1 during a defined transition period. At the end of the transition period, key number 0 would be disabled.

Key numbering takes on a slightly different role in dynamic WEP solutions. Each station receives two keys from the access point: a mapping key, typically stored as key number 0, and a default key, typically stored as key number 1. Stations use key 0 for protection of unicast traffic, and key 1 for protection of broadcast traffic. When frames are queued by the driver for transmission, the driver software will label unicast frames as requiring encryption with key 0, and broadcast frames as requiring encryption with key 1.

When 802.11 was new, many cards did not support WEP, or performed the RC4 encryption on the host CPU, limiting performance. RC4 is very easy to implement in hardware, and virtually every wireless LAN interface sold since 1999 has provided hardware-based RC4 encryption in the interface card itself to reduce the performance hit from encryption. (This includes most 802.11b cards and everything that has come later.) Some older cards also used firmware to limit key length to 40-bit keys rather than 104-bit keys, such as the Orinoco Silver and Gold cards. Key length restrictions were lifted in later firmware releases.

To efficiently encrypt frames, many 802.11 chipsets include a data structure called the key cache. Key caches consist of mappings between tuples of the destination address, the key identifier number, and the bits of the key itself. Most chipsets intended for use in station interface cards have four key slots. Static WEP uses one key slot; dynamic WEP solutions use two. When frames are queued for transmission, the destination address is looked up in the key cache and the resulting key is used to encrypt the frame. Dynamic keying solutions function identically to static WEP solutions, except that the contents of the key cache may be overwritten by key management software.

One of the ways in which chipsets intended for use in cards differ from chipsets intended for use in access points is that the AP chipsets have much larger key caches, often capable of 256 or more key entries. Even with two entries required (one mapped key and one default key) for a station, such a data structure can handle keying for more than 100 stations. Given the limited capacity of most wireless link technologies, such a large data will handle any reasonable traffic load with room to spare. However, some early APs capable of dynamic keying were unable to maintain large key data structures, and had to share keys among multiple stations. To cut costs, some vendors used card chipsets rather than AP chipsets in the AP radio. As a result, they only had four key slots and needed to share a single unicast key among all stations attached to an AP.

WEP Encapsulation

When WEP is in use, the frame body expands by eight bytes. Four bytes are used for a frame body IV header, and four are used for the ICV trailer. See Figure 5-4.

Figure 5-4. WEP frame extensions

The IV header uses 3 bytes for the 24-bit IV, with the fourth byte used for padding and key identification. When a default key is used, the Key ID subfield identifies the default key that was used to encrypt the frame. If a key mapping relationship is used, the Key ID subfield is 0. The 6 padding bits of the last byte must be 0. The integrity check is a 32-bit CRC of the data frame; it is appended to the frame body and protected by RC4. The frame check sequence protects the encrypted data.