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

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

3. 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

4. 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

5. 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

6. 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)

7. 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. 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

9. Sender-side WEP encryption
encrypted
data
ICV
header IV

10. 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?

11. 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

12. 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…

13. 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

14. 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

15. 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.

16. 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 standard)
The WEP checksum is an unkeyed function of the message.

17. 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

18. 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

19. 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

20. 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

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