Knowing the Key

WEP depends on a shared key, known to both the AP and station, but the standard does not define how this key gets distributed. In many 802.11b products, all stations in a BSS are manually configured with the same key. Conceptually, this is similar to hubbed Ethernet.

Some 802.11b products use a mapping table to associate MAC addresses with unique keys. This makes it more difficult for stations in the same BSS to eavesdrop on each other. Conceptually, this is similar to switched Ethernet.

Unfortunately, manual key distribution encourages use of the same key for a long time. Anyone who discovers the key can sniff wireless traffic quite easily, without physical access to cables, ports, hubs, or switches.

A few products use public key crypto to generate session keys. A new key for each session shortens the period of use and eliminates manual key configuration. However, Diffie-Hellman—the handshake commonly used to derive session keys—is vulnerable to man-in-the-middle attack when endpoints have not been properly authenticated. The attacker simply jumps into the handshake by spoofing a legitimate station and AP. Once he grabs the session key, he becomes privy to all data transmitted during that session.

Cracking the code
Another problem is RC4, the encryption algorithm used by WEP. RC4 is a stream cipher, well suited for traffic with reliable delivery—for example, SSL over TCP. But in a wireless network, there is significant packet loss. To avoid desynchronization, WEP reinitializes the RC4 engine on every 802.11b frame. This means that every frame carries an RC4 initialization vector (IV) as plaintext. To keep the frame short, the WEP standard uses a 24-bit IV.

In brief, here's how WEP encryption works. The sender selects a new IV and appends it to the shared key, generating an RC4 keyschedule. Using the keyschedule, RC4 generates a keystream of the same length as the frame payload (the data to be transmitted and a CRC field). The keystream is XORed against the payload to yield ciphertext. The receiver uses the same-shared key and IV to generate the same keystream, which is XORed against the ciphertext to yield the original plaintext.

In stream ciphers, it is unsafe to use the same key twice. But WEP's small IV almost guarantees keystream reuse. Manually-configured LANs cannot to change the key often enough to avoid reuse. Intel researcher Jesse Walker estimated that a single access point, running at 11 Mbps, exhausts the derived key space in about an hour. A larger LAN will exhaust space at a faster rate, inversely proportional to number of access points. When stations have the same-shared key, the probability of IV collision (keystream reuse) among stations reaches 99 percent in less than a minute. NICs that start IV at zero, incrementing sequentially, add insult to injury. A 24-bit IV is just too small to prevent an attacker from collecting more than one frame, encrypted with the same keystream.

Why key reuse matters
An attacker who passively intercepts frames encrypted with same keystream creates a foundation for statistical analysis. The larger the sample, the higher the probability of cracking.

802.11 frames carry IP packets containing a large amount of known plaintext. This lets an attacker recover a partial keystream for every packet. Building up hints, an attacker eventually discovers the entire keystream. Once the plaintext for one frame is recovered, the plaintext for everything else encrypted with that same keystream is known. Attackers can build a dictionary of keystreams to decipher all captured frames, as long as the same shared key remains in use.

When an integrity check isn't
An integrity check field—a CRC32 checksum—is included in each WEP frame, as part of the encrypted payload. In theory, the CRC lets the receiver verify that the frame was not modified in transit. In practice, the CRC is implemented such that it is possible to flip bits in both the payload and checksum, generating a correct checksum for the modified packet.

This weakness facilitates active attacks. For example, an attacker can sniff a valid 802.11b frame, set the destination IP address to his own, adjust the CRC to cover his tracks, and transmit the modified frame to the AP. If the AP operates as an Internet gateway, it will decrypt the packet and deliver the plaintext to the attacker's PC. Could it get any easier?

A better way
In an analysis presented to the IEEE, Intel's Walker recommended that RC4 be replaced with the 128-bit AES block cipher in offset codebook mode (OCB). OCB-AES is a stream cipher that also produces a message authentication code. Furthermore, Walker recommended using session keys, derived by OCB-AES on the SSID, station MAC, and access point MAC. A new WEP encapsulation, designed to reduce the chance of ciphertext cracking and prevent frame modification and replay, was also recommended.

One hopes that future standards like IEEE 802.11a will not only increase wireless throughput but also provide more robust security. In the interim, ISPs deploying 802.11b should realize that wireless is easily tapped, even when using products that support WEP. Use firewalls to restrict the flow of packets from wireless APs to appropriate destinations. Apply strong user-level authentication to reduce theft of service and unauthorized use. Where privacy matters, encourage users to encrypt their own traffic—for example, by using secure email programs, SSL-protected web portals, or VPN tunnels. Finally, avoid misleading subscribers by admitting up front: wireless LANs with WEP is no guarantee against eavesdropping.

—End 

< Back to page 1: Wireless Privacy: An Oxymoron?