Figure 2. The 802.11 frame body always begins with a SNAP header (for example, AA).

specification.

Generally, WEP works like this. The RC4 algorithm uses the pseudoran-dom generation algorithm (PRGA) to produce a key-stream of bits that are XORed with the plaintext to create the ciphertext. Key-change is accomplished by adding an Initialization Vector (IV) that makes each packet key unique. The IV is concatenated with the WEP key to form the WEP seed.

The properties of the IV are interesting:

1. The IV is only 24 bits long;

2. The IV is always prepended to the WEP key;

3. The IV is always transmitted in cleartext (see Figure 1);

4. Some IVs are “weak” in the sense that they suggest information about the key—the first bytes of a typical WEP packet are typically the snap header 0xAA (see Figure 2);

5. The IEEE standards were so ambiguous that many vendors used sequential IV generators that begin with 00:00:00 and wrap with FF:FF:FF; and

6. The key-generation algorithm itself is hobbled because the most significant bit of each key is always 0; thus it only produces unique keys for seeds 00:00:00:00 through 00:7F:7F:7F.

The community of FMS (after Fluher, Mantin, and Shamir) attack analysts reacted immediately. In short order a flurry of successful WEP-cracking tools were developed (WEPAttack, WepCrack, Aircrack, WepLab, WEPWedgie) all made possible by the faulty implementation of RC4. A virtual cottage industry was made possible because the original WEP security standard followed the STO model. We will put the WEP vulnerability into our new STO Category II: botched implementations.

One might think the frailty of WEP would have triggered a total rethinking of WiFi security. Such is not the case. While WEP’s successor, Wireless Protected Access (WPA), did strengthen the integrity-checking algorithm and key management, it basically just added another layer of obscurity over the sloppily designed WEP in the form of a shell over the RC4 algorithm. Deployed by the Wi-Fi Alliance in 2002, WPA didn’t really eliminate the key-manage-ment problem inherent in WEP,

but rather proliferated the
number of keys involved.
WPA uses a pairwise mas-
ter key (PMK) to generate
additional keys that are
combined with sender
MAC address, packet
sequence number, the
wireless Service Set ID,
and SSID length as grist
for the hashing mill
(PKCS #5 v. 2.0). Let’s
think about this. If an
underlying procedure is
faulty, does it become less faulty if
we use it over and over and over
again? WPA relied on STO, just
like its predecessor. Predictably,
within a year of release, a success-
ful WPA attack was discovered.
Shortly therafter, the WPA-crack-
ing utility co WPAtty was released
that reverse engineers the PMK
from the SSID, SSID length, and
sequence number MAC address,
and WiFi security was back at the
starting block.

Neither was the Extensible Authentication Protocol immune. Cisco’s version of EAP, LEAP, deserved the term lightweight. LEAP’s major fault was that it relied on the MS- CHAPv2 hashing algorithm for authentication. MS-CHAPv2 does not use “salt,” so the same plaintext value will always produce the same hashed value. This makes EAP-LEAP vulnerable to dictionary and replay attacks. Once again, the defense of EAP-LEAP ultimately relied on no one finding out how the system works. Auguste Kerckhoffs could