CSE 4905 WiFi Security I WEP (Wired Equivalent Privacy)

Securing 802.11 WLAN First attempt Current standard Others efforts 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

First attempt: WEP Completely broken Why learn WEP? 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

WEP security goals Confidentiality Data integrity Access control 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

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

Symmetric stream ciphers keystream generator key 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)

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

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, kiIV kiIV used to encrypt i-th byte, di, in frame: ci = di XOR kiIV IV and encrypted bytes, ci sent in frame

Sender-side WEP encryption encrypted data ICV header IV

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?

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

802.11 WEP encryption one attack: Many ways to know plaintext Trudy causes Alice to encrypt known plaintext d1 d2 d3 d4 … Trudy sees: ci = di XOR kiIV Trudy knows ci di, so can compute kiIV Trudy knows encrypting key sequence k1IV k2IV k3IV … 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…

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

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

Message modification v: IV, k: key, c(): CRC checksum function 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.

Message injection Suppose attacker recovers a keystream (e.g., through a chosen-plaintext attack) v: IV, k: key, P: plaintext, C: ciphertext Construct ciphertext C’ of a new message M’ 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.

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

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

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

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

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.