WiFi Security

Wired Equivalent Privacy (WEP) was introduced in 1997 as part of the original IEEE 802.11 wireless networking standard. Its name reveals its ambition: to provide wireless networks with security equivalent to that of a wired Ethernet connection. In wired networks, physical access to the cable is required to eavesdrop—WEP aimed to create a similar barrier for wireless communications.

Today, WEP stands as one of the most famous examples of failed security design in computing history. Understanding why WEP failed is not merely historical curiosity—it provides fundamental lessons in cryptographic protocol design that remain relevant for understanding modern security mechanisms.

WEP was designed to achieve three primary security objectives:

1. Confidentiality Preventing unauthorized parties from reading transmitted data. Even if attackers capture wireless packets (trivial with the right equipment), the encrypted content should be indecipherable without the secret key.

2. Data Integrity Ensuring that data is not modified in transit. Recipients should be able to verify that received packets are identical to what was sent, detecting any tampering.

3. Access Control Preventing unauthorized stations from connecting to and using the wireless network. Only clients with the correct key should be able to authenticate and communicate.

These goals are sound—the failure lay entirely in how WEP attempted to achieve them.

The WEP Encryption Process:

1. Compute ICV = CRC-32(plaintext)
2. Append ICV to plaintext: P' = plaintext || ICV
3. Concatenate IV with shared key: K = IV || SharedKey
4. Generate keystream: RC4(K) → keystream
5. Produce ciphertext: C = P' ⊕ keystream
6. Transmit: IV || C

The IV is sent in the clear because the receiver needs it to reconstruct the same keystream for decryption. This design decision, combined with the small IV space, proved catastrophic.

WEP's choice of RC4 was significant. RC4 (Rivest Cipher 4), designed by Ron Rivest in 1987, was popular for several reasons:

Advantages of RC4:

• Speed: RC4 is exceptionally fast in software, important for resource-constrained wireless devices of the late 1990s.
• Simplicity: Easy to implement in low-power hardware without complex operations.
• Variable key length: Supports keys from 8 to 2048 bits, providing flexibility.
• No block boundaries: As a stream cipher, there's no padding required regardless of message length.

However, RC4's security properties have subtle requirements that WEP violated.

How RC4 Works:

RC4 operates in two phases:

Key Scheduling Algorithm (KSA):

1. Initialize a 256-byte state array S with values 0-255
2. Permute S using the key bytes:

   for i = 0 to 255:
       j = (j + S[i] + key[i mod keylen]) mod 256
       swap(S[i], S[j])
   

3. The final state S becomes the cipher's internal state

Pseudo-Random Generation Algorithm (PRGA): For each output byte:

i = (i + 1) mod 256
j = (j + S[i]) mod 256
swap(S[i], S[j])
output S[(S[i] + S[j]) mod 256]

The PRGA produces a keystream—a sequence of pseudorandom bytes that appear random but are deterministic given the key. XORing this keystream with plaintext produces ciphertext.

Why RC4 Itself Is Not the Problem:

While RC4 has known biases in its keystream (the first bytes are not uniformly distributed), these weaknesses alone don't break WEP. The catastrophic failures came from how WEP used RC4:

1. Prepending the IV to the key: RC4 was designed for keys that appear random. The WEP key format (known IV + secret key) creates patterns that leak information.

2. Related-key structure: All WEP keys for a given network share the same suffix (the secret key). This creates what cryptographers call 'related keys'—a serious weakness when the relationship is predictable.

3. Weak key scheduling: RC4's KSA doesn't fully mix key bits before producing output. The first few keystream bytes are statistically correlated with key bytes—especially when keys have structure like WEP's.

The 24-bit Initialization Vector is perhaps WEP's most critical design flaw. Multiple catastrophic vulnerabilities stem directly from this choice:

Problem 1: IV Space Exhaustion

With only 24 bits, there are exactly 2²⁴ = 16,777,216 possible IVs. This sounds like a large number, but consider modern wireless traffic:

• A typical 802.11 frame is ~1500 bytes
• At 54 Mbps (802.11g), that's approximately 4,500 frames per second
• 16.7 million frames ÷ 4,500 frames/second = ~3,700 seconds ≈ 1 hour

In a busy network, IV reuse is guaranteed within approximately one hour of heavy traffic. Even with lighter loads, reuse typically occurs within a few hours.

Problem 2: No IV Uniqueness Enforcement

The 802.11 standard doesn't mandate how IVs should be generated or that they must be unique. Common implementations used:

• Sequential IVs: Starting from 0 and incrementing. Predictable and often reset on reboot.
• Random IVs: Collision probability follows the birthday paradox—50% collision probability after only ~4,823 frames (√(2 × 2²⁴)).
• Counter with resets: Counters that reset to 0 on driver reload, card reset, or firmware update.

None of these approaches prevent IV reuse in practice.

Problem 3: Weak IVs and Key Correlation

The Fluhrer, Mantin, and Shamir (FMS) attack discovered in 2001 identified that certain IVs—called 'weak IVs'—leak information about the secret key bytes.

Specifically, when the first three bytes of the IV+Key concatenation have a specific relationship, the first keystream byte has a strong statistical bias toward revealing a key byte. The pattern:

IV of form: (A+3, N-1, X) where:
  - A is the target key byte index
  - N is 256
  - X is any value

With approximately 2%–5% of IVs being 'weak' for each key byte, collecting enough traffic to solve the entire key becomes feasible.

WEP's choice of CRC-32 for integrity protection represents a fundamental misunderstanding of the difference between error detection and cryptographic integrity.

What CRC-32 Was Designed For:

Cyclic Redundancy Check (CRC) algorithms detect accidental errors in data—bit flips, electrical interference, transmission noise. They are optimized for speed and can detect common error patterns with high probability.

What CRC-32 Cannot Do:

CRC is not cryptographically secure. It has no keyed input—anyone can compute the CRC of any message. More critically, CRC is linear:

CRC(A ⊕ B) = CRC(A) ⊕ CRC(B)

This linearity is devastating when combined with stream cipher encryption.

The Bit-Flipping Attack:

Because XOR is also linear, an attacker can modify encrypted WEP packets without knowing the key:

1. Let C = P ⊕ K (ciphertext = plaintext XOR keystream)
2. Attacker computes a modification mask M
3. Attacker transmits C' = C ⊕ M
4. When decrypted: P' = C' ⊕ K = (C ⊕ M) ⊕ K = P ⊕ M

The attacker has modified the plaintext in a predictable way without knowing the key!

The CRC must also be modified to match. Due to CRC linearity:

New CRC = Old CRC ⊕ CRC(M)

Both values can be computed without knowing the original plaintext or key.

Why This Matters:

WEP's integrity check provides zero protection against malicious modification. An attacker who can capture one encrypted packet can:

1. Modify specific bits in the encrypted payload
2. Adjust the encrypted CRC to match
3. Rebroadcast the modified packet
4. The receiver will accept it as valid

This attack requires no key knowledge—only understanding of the packet structure being modified. Combined with the ability to inject packets, attackers gain significant control over network communications.

WEP defined two authentication modes, both fundamentally flawed:

Open System Authentication:

This mode performs no actual authentication—the client sends an authentication request, and the AP accepts it. The WEP key is only used for encryption after association. While this sounds insecure, it's actually no worse than the alternative.

Shared Key Authentication:

This mode attempts to prove knowledge of the WEP key through a challenge-response protocol:

1. Client sends authentication request
2. AP sends a 128-byte random challenge (cleartext)
3. Client encrypts challenge with WEP and sends back
4. AP decrypts and verifies challenge matches
5. If match, client is authenticated

The Shared Key Attack:

Paradoxically, Shared Key Authentication is less secure than Open Authentication. The problem:

1. Attacker captures the authentication exchange
2. Attacker now has: Challenge (plaintext) and Response (ciphertext)
3. Keystream = Challenge ⊕ Response (for the IV used in that response)
4. This keystream can be reused with the same IV!

Exploitation:

Step 1: Capture authentication: Challenge_plaintext, Response_ciphertext, IV
Step 2: Derive keystream: K = Challenge ⊕ Response
Step 3: Create new authentication request
Step 4: When challenged, encrypt with K using same IV
Step 5: AP accepts—attacker is authenticated

The attacker has authenticated without knowing the WEP key by replaying the keystream.

Additional Authentication Problems:

• No mutual authentication: The client cannot verify the AP's identity, enabling rogue AP attacks.
• No per-client keys: All clients share the same PSK, so compromising one client compromises all.
• No session key derivation: The same key is used for all traffic indefinitely, preventing key rotation.
• Replay vulnerability: No mechanism prevents capture and retransmission of valid encrypted frames.

The theoretical weaknesses in WEP were progressively weaponized into increasingly efficient attacks:

2001 — The FMS Attack (Fluhrer-Mantin-Shamir):

The foundational attack that proved WEP was fundamentally broken:

• Identified weak IV patterns that leak key bytes
• Required ~4-6 million packets for reliable key recovery
• Took several hours of packet capture on busy networks
• Could be mitigated (but not fixed) by filtering weak IVs

2004 — The KoreK Attack (Improved FMS):

Dramatically reduced the number of packets needed:

• Discovered 16 additional correlations beyond FMS
• Reduced packet requirements to ~500,000-1,000,000
• Key recovery possible in 10-30 minutes
• Weak IV filtering became ineffective

2005 — The Chopchop Attack:

Enabled decryption without key recovery:

• Allowed decrypting any captured packet byte-by-byte
• Used CRC weakness to verify guessed plaintext bytes
• Approximately 128 packets per decrypted byte
• Combined with fragmentation, enabled packet injection

2007 — The PTW Attack (Pyshkin-Tews-Weinmann):

The current state-of-the-art in WEP cracking:

• Uses all captured packets, not just weak IVs
• Requires only ~40,000-85,000 packets
• Key recovery in under 60 seconds on modern hardware
• Works against all WEP implementations

WEP's failure provides essential lessons that directly influenced the design of WPA, WPA2, and modern cryptographic protocols:

Lesson 1: Never Reuse Keystreams

Stream cipher security absolutely depends on unique key+nonce combinations. WEP's 24-bit IV guaranteed reuse. Modern protocols use 48-bit or larger nonces with strict sequencing requirements.

Lesson 2: Use Cryptographic MAC, Not CRC

Integrity protection requires keyed cryptographic operations like HMAC or authenticated encryption (AES-CCM, AES-GCM). CRC and other checksums provide no security against malicious modification.

Lesson 3: Don't Mix IV and Key Directly

Concatenating public and secret values violated RC4's assumptions. Modern protocols use key derivation functions (KDFs) that cryptographically mix inputs before use.

WEP failed not because of any single flaw, but because of a cascade of poor cryptographic decisions that compounded each other:

Current Status:

WEP was deprecated by the IEEE in 2004 and formally prohibited for WiFi Alliance certification since 2006. The PCI DSS (Payment Card Industry Data Security Standard) explicitly forbids WEP for any cardholder data transmission.

Despite this, WEP networks still exist in legacy industrial systems, older consumer devices, and misconfigured networks. Security audits frequently discover WEP where administrators assumed 'any encryption is better than none'—a dangerous misconception given that WEP attacks can also reveal traffic patterns and enable network access.

What's Next:

The next page examines WPA (Wi-Fi Protected Access), the emergency response to WEP's collapse. We'll see how WPA addressed WEP's critical flaws while maintaining compatibility with existing hardware—and the tradeoffs that decision required.