CSE 4905 Wi Fi Security I WEP Wired

  • Slides: 21
Download presentation
CSE 4905 Wi. Fi Security I WEP (Wired Equivalent Privacy) 8 -1

CSE 4905 Wi. Fi Security I WEP (Wired Equivalent Privacy) 8 -1

Securing 802. 11 WLAN v First attempt § Wired Equivalent Privacy (WEP), 1999 §

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

First attempt: WEP v Completely broken § Fails all security goals § Provides no

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

WEP security goals v Confidentiality § Fundamental goal § prevent eavesdropping v Data integrity

WEP security goals v Confidentiality § Fundamental goal § prevent eavesdropping v Data integrity § Prevent tampering with transmitted messages v 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 v Use symmetric key crypto § RC 4 stream cipher • Believed

WEP Encryption v Use symmetric key crypto § RC 4 stream cipher • Believed to be a strong cipher • Efficient: easy to implement in hardware/software v 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 key v keystream generator keystream combine each byte of keystream with

Symmetric stream ciphers key v keystream generator 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 v self-synchronizing: each packet separately encrypted § given encrypted

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

WEP encryption: RC 4 stream cipher v v v host/AP share 40 bit symmetric

WEP encryption: RC 4 stream cipher v v v 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. IV used to encrypt i-th byte, di, in frame: ci = di XOR ki. IV IV and encrypted bytes, ci sent in frame 8 -8

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

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

Exercise v Differences between one-time pad and stream cipher used in WEP? v WEP

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

Security hole in 802. 11 WEP encryption v 24 -bit IV, one IV per

Security hole in 802. 11 WEP encryption v 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 v IV transmitted in plaintext IV reuse 8 -11

802. 11 WEP encryption v one attack: § Trudy causes Alice to encrypt known

802. 11 WEP encryption v one attack: § Trudy causes Alice to encrypt known plaintext d 1 d 2 d 3 d 4 … § Trudy sees: ci = di XOR ki. IV § Trudy knows ci di, so can compute ki. IV § Trudy knows encrypting key sequence k 1 IV k 2 IV k 3 IV … § Next time IV is used, Trudy can decrypt! v 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… 8 -12

Key management v Not specified v Vendors use their own strategies, often times §

Key management v Not specified v 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 v Integrity checksum field: CRC-32 checksum § NOT a cryptographically secure authentication

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

Message modification v Suppose ciphertext C is intercepted; C corresponds to unknown message M

Message modification v Suppose ciphertext C is intercepted; C corresponds to unknown message M v: IV, k: key, c(): CRC checksum function v 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 v Suppose attacker recovers a keystream (e. g. , through a chosen-plaintext

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

Shared-key Authentication v v 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 8 -17

Authentication spoofing v Get a legitimate keystream § E. g. , by monitoring the

Authentication spoofing v Get a legitimate keystream § E. g. , by monitoring the challenge (plaintext) and response (ciphertext of the challenge) of a legitimate authentication sequence v v 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 v Many security flaws § None needs to know

Summary: Security Holes in WEP v 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 RC 4 v Later on, people found weakness in RC 4 v… v Consensus: need a completely new protocol designed from the scratch 8 -19

WEP – Lessons learned v engineering security protocols is difficult § combining strong building

WEP – Lessons learned v 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 v Nikita Borisov, Ian Goldberg, David Wagner, “Intercepting Mobile Communications: The Insecurity of

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