Understanding WEP Security: Flaws, Goals, and Encryption

CSE 4905 WiFi Security I WEP (Wired Equivalent Privacy) 8-1

Securing 802.11 WLAN First attempt Wired Equivalent Privacy (WEP), 1999 in IEEE 802.11, Part II Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) Specifications Current standard IEEE 802.11i adopted in 2004 Others efforts WPA2 (WiFi Protected Access 2) intermediate solutions: IEEE Temporary Key Integrity Protocol (TKIP) or WPA, 2003 8-2

First attempt: WEP Completely broken Fails all security goals Provides no protection at all Why learn WEP? Understand the design flaws Understand how it misuses cryptographic primitives Avoid similar mistakes in the future 8-3

WEP security goals Confidentiality Fundamental goal prevent eavesdropping Data integrity Prevent tampering with transmitted messages Access control Protect access to wireless LAN Optional feature: discard all packets that are not properly encrypted using WEP; manufactures advertise this ability as access control 8-4

WEP Encryption Use symmetric key crypto RC4 stream cipher Believed to be a strong cipher Efficient: easy to implement in hardware/software Assume host and AP share a secret key Suppose the key is obtained in off-line manner No mechanism on key management Caused many security issues 8-5

Symmetric stream ciphers keystream generator key keystream combine each byte of keystream with byte of plaintext to get ciphertext: m(i) = ith unit of message ks(i) = ith unit of keystream c(i) = ith unit of ciphertext c(i) = ks(i) m(i) ( = exclusive or) m(i) = ks(i) c(i) 8-6

Stream cipher and packet independence self-synchronizing: each packet separately encrypted given encrypted packet and key, can decrypt; can continue to decrypt packets when preceding packet was lost WEP approach: initialize keystream with key (fixed) + new IV for each packet: keystream generator Key+IVpacket keystreampacket 8-7

WEP encryption: RC4 stream cipher host/AP share 40 bit symmetric key host appends 24-bit initialization vector (IV) to create 64-bit key 64 bit key used to generate stream of keys, ki ki ci = diXORki IV and encrypted bytes, ci sent in frame IV IV used to encrypt i-th byte, di, in frame: IV 8-8

802.11 WEP encryption IV (per frame) key sequence generator ( for given KS, IV) KS: 40-bit secret symmetric IV k2 IV k3 IV kN IV kN+1 IV kN+1 IV k1 WEP-encrypted data plus CRC 802.11 header IV plaintext frame data plus CRC d2 d3 dN CRC1 CRC4 d1 c2 c3 cN cN+1 cN+4 c1 Figure 7.8-new1: 802.11 WEP protocol Sender-side WEP encryption encrypted header data ICV IV 8-9

Exercise Differences between one-time pad and stream cipher used in WEP? WEP encryption How easy will keystream be reused? Issues when a keystream is reused? 8-10

Security hole in 802.11 WEP encryption 24-bit IV, one IV per frame IV s eventually reused e.g., when IV is chosen randomly, it takes < 5000 packets to come up with key reuse Even worse: specification does not say how to select IVs common PCMCIA cards sets IV to zero and increment it by 1 for each packet IV transmitted in plaintext IV reuse detected 8-11

802.11 WEP encryption one attack: Trudy causes Alice to encrypt known plaintext d1 d2 d3 d4 Trudy sees: ci = diXORki Trudy knows cidi, so can compute ki Trudy knows encrypting key sequence k1 Next time IV is used, Trudy can decrypt! Many ways to know plaintext Protocols use well-defined structures E.g., login sequence Content of messages often predictable E.g., IP address, port numbers IV IV IV k2 IV k3 IV 8-12

Key management Not specified Vendors use their own strategies, often times Install keys manually Change keys infrequently (days, months) Use a single key for entire network Increase chances of IV reuse Difficult to replace compromised key 8-13

Message integrity Integrity checksum field: CRC-32 checksum NOT a cryptographically secure authentication code CRC: detect random errors, not resilient to malicious attacks Message modification possible Message injection possible 8-14

Message modification Suppose ciphertext C is intercepted; C corresponds to unknown message M v: IV, k: key, c(): CRC checksum function Attacker uses C to replace C; receiver recover M without discovering the change in M The WEP checksum is a linear function of the message. 8-15

Message injection Suppose attacker recovers a keystream (e.g., through a chosen-plaintext attack) Construct ciphertext C of a new message M v: IV, k: key, P: plaintext, C: ciphertext C uses the same IV as before, but in WEP, it is possible to reuse old IV without triggering an alarm at the receiver (allowed by 802.11 standard) The WEP checksum is an unkeyed function of the message. 8-16

Shared-key Authentication before association, host needs to authenticate itself to AP Shared-key authentication: host requests authentication from AP AP sends 128 bit nonce host encrypts nonce using shared symmetric key AP decrypts nonce, authenticates host once authenticated, host can send an association request no key distribution mechanism authentication: knowing the shared key is enough 8-17

Authentication spoofing Get a legitimate keystream E.g., by monitoring the challenge (plaintext) and response (ciphertext of the challenge) of a legitimate authentication sequence Recall due to lack of key management, all stations in network use the same key Now attacker can use the keystream to construct response to any challenge authenticate indefinitely 8-18

Summary: Security Holes in WEP Many security flaws None needs to know the secret key Even the secret key is much longer (than 40 bits in standard), it does not help None needs to attack RC4 Later on, people found weakness in RC4 Consensus: need a completely new protocol designed from the scratch 8-19

WEP Lessons learned engineering security protocols is difficult combining strong building blocks in a wrong way insecure system at the end don t do it alone security is a non-functional property it is extremely difficult to tell if a system is secure or not using expert in design phase pays out (fixes after deployment will be much more expensive) experts will not guarantee your system is 100% secure but at least they know many pitfalls they know the details of crypto algorithms 8-20

References Nikita Borisov, Ian Goldberg, David Wagner, Intercepting Mobile Communications: The Insecurity of 802.11 , Conference on Mobile Computer Networking, 2001. J. R. Walker. Unsafe at any key size; an analysis of the WEP encapsulation. IEEE Document 802.11-00/362, Oct. 2000. 8-21