[TOC]
Wired Equivalent Privacy (WEP) was the original confidentiality and integrity mechanism for IEEE 802.11 wireless LANs. Designed in the late 1990s, WEP aimed to provide a level of security comparable to wired networks. In practice, however, multiple design flaws and weaknesses have rendered WEP insecure; it is now deprecated and should be replaced by modern standards such as WPA2/WPA3.
This note summarizes WEP’s design, key management assumptions, core weaknesses (IV reuse, weak RC4 key scheduling, and weak integrity checks), common attacks, and recommended modern replacements.
- Purpose: provide confidentiality and message integrity for 802.11 frames using RC4 stream cipher and a CRC‑32 integrity check.
- Key idea: combine a per‑packet initialization vector (IV) with a shared secret key to form an RC4 seed; use RC4 keystream to encrypt payload and append a CRC‑32 (ICV) for integrity.
- Reality: predictable/short IVs, RC4 key scheduling weaknesses, and CRC‑32 provide little protection; trivial attacks (key recovery, packet forgery) exist.
- Secret key: WEP relies on a pre‑shared symmetric key (commonly 40‑bit or 104‑bit keys historically). WEP itself does not define strong key distribution or management; keys are typically configured manually (out‑of‑band).
- IV: 24‑bit initialization vector (IV) sent in clear in each 802.11 frame header. The IV is concatenated with the shared key to form the RC4 seed.
- Encryption: RC4 stream cipher generates a keystream; plaintext (including the ICV) is XORed with the keystream to produce ciphertext.
- Integrity: a 32‑bit CRC (called the Integrity Check Value, ICV) of the plaintext is appended before encryption. CRC‑32 is not a cryptographic MAC and is vulnerable to intentional manipulation.
WEP does not mandate a key management protocol. Typical deployments used a shared static key manually configured on access points and clients. Authentication in the original 802.11 (open vs WEP shared key) had two modes:
- Open System: no real authentication; any client may associate, and WEP is optional for data confidentiality.
- Shared Key Authentication (flawed): a challenge‑response exchange where the AP sends a plaintext challenge (nonce), the client encrypts it with the WEP key, and the AP verifies decryption. This process leaks information and does not provide strong mutual authentication; it also can be used to facilitate key recovery.
Because key distribution was handled out of band (manual configuration), operational key rotation was rare, increasing exposure to attacks.
- Short IV and IV reuse
- The IV is only 24 bits; on a busy network IVs repeat frequently. When the same IV is reused with the same secret key, the RC4 keystream repeats, enabling simple plaintext recovery or keystream extraction by XORing ciphertexts.
- RC4 key scheduling vulnerabilities
- Certain RC4 key schedules produce weak initial bytes of the keystream that leak information about key bytes (the so‑called FMS, KoreK, and PTW attacks exploit these biases). Attackers collecting enough frames with chosen or predictable IVs can recover the shared key offline.
- Weak integrity (CRC‑32 instead of MAC)
- CRC‑32 detects random transmission errors but is trivial to forge: an attacker can flip bits in the ciphertext and compute a corresponding change to the ICV so that the CRC still matches — enabling controlled bit‑flipping attacks.
- Authentication design problems
- Shared key authentication leaks information that helps key recovery. The challenge/response messages, when captured, provide material for offline attacks against the WEP key.
Combined, these weaknesses make WEP susceptible to rapid practical attacks: with passive collection or modest active traffic injection, keys can be recovered in minutes to hours with readily available tools.
- Passive keystream reuse: capture two ciphertexts encrypted with the same IV and XOR them to cancel the keystream; this reveals XOR of plaintexts and facilitates plaintext recovery with classical techniques.
- FMS (Fluhrer, Mantin, and Shamir) attack: exploits RC4 key scheduling biases to recover key bytes by collecting many frames with specific IVs.
- KoreK and PTW improvements: later attacks dramatically reduced the number of frames needed for practical key recovery.
- Replay and injection: because CRC is malleable and integrity checks are weak, an attacker can forge packets or modify captured frames to inject traffic into the network.
- Never use WEP for protecting sensitive traffic. WEP provides a false sense of security.
- In environments still running legacy WEP devices, isolate them on segmented networks and limit privileges; apply network‑level controls (firewalls, VLANs) and monitor for anomalous activity.
- WPA (Wi‑Fi Protected Access): an intermediate replacement using TKIP (a retrofitting around RC4) and improved key management. TKIP was intended as a stopgap and is now considered insecure.
- WPA2: uses IEEE 802.11i/RSN with CCMP (AES in CCM mode) as the robust confidentiality and integrity primitive. WPA2 with 802.1X/EAP provides enterprise‑grade authentication and key management.
- WPA3: modern standard with SAE (Simultaneous Authentication of Equals) for password‑based authentication, improved cryptography, and enhanced protections for open networks (OWE).
- Alternatives: modern VPNs or IPsec can add another layer of protection when strong Wi‑Fi security is not available.
- Use WPA2‑Enterprise (802.1X/EAP) or WPA3 where possible.
- Enforce strong passphrases and certificate‑based authentication for enterprise deployments; rotate keys and certificates regularly.
- Decommission WEP and TKIP devices or isolate them on restricted network segments.
- Monitor wireless networks for repeated IVs, suspicious authentication attempts, and unexpected traffic injection.
- Kurose, Ross — Computer Networking: A Top‑Down Approach (WEP and wireless security sections)
- FMS: Fluhrer, Mantin, and Shamir — Weaknesses in the RC4 key scheduling algorithm
- Practical attack writeups (KoreK, PTW) and modern wireless security deployment guides