WEP2 Security Analysis

1. WEP2 Security Analysis Bernard Aboba Microsoft Bernard Aboba, Microsoft

2. Goals • To (briefly) summarize security weaknesses discovered in WEP v1.0 • To analyze security vulnerabilities of WEP2 • To recommend potential improvements Bernard Aboba, Microsoft

3. Classes of Attacks Against WEP v1.0 • IV (key) reuse [Walker, Berkeley team, Arbaugh] • Made possible by small IV space in WEPv1.0, lack of IV replay protection • Enables statistical attack against ciphertexts w/replayed IVs • Known plaintext attack [Walker, Berkeley team, Arbaugh] • Lots of known plaintext in IP traffic: ICMP, ARP, TCP ACK, etc. • Can send pings from Internet through AP to snooping attacker • Enables recovery of key stream of length N for a given IV • Can forge packets of size N by reusing IV in absence of a keyed MIC • Partial known plaintext [Berkeley team, Arbaugh] • May only know a portion of the plaintext (e.g. IP header) • Possible to recover M octets of the keystream, M < N • Via repeated probing, can extend keystream from M to N [Arbaugh] • Possible to flip bits in realtime, adjust CRC32, divert traffic to attacker • Enabled by linearity of CRC32, absence of keyed MIC Bernard Aboba, Microsoft

4. Classes of Attacks (cont’d) • Authentication forging [Berkeley team] • WEP v1.0 encrypts challenge using IV chosen by client • Recovery of key stream for a given IV enables re-use of that IV for forging WEP v1.0 authentication • Does not provide key, so can’t join LAN • Denial of service • Disassociate, reassociate messages not authenticated • Dictionary attack • Possible where WEP keys derived from passwords • Realtime decryption [Berkeley team, Arbaugh] • Repeated IV reuse, probing enables building of a dictionary of IVs, key streams • Enables decryption of traffic in realtime • Possible to store dictionary due to small IV space • Need 1500 octets of key stream for each IV • 2^24 * 1500 octets = 24 GB Bernard Aboba, Microsoft

5. WEP2 • Increases size of IV space to 128 bits • Key may be changed periodically via IEEE 802.1X re-authentication to avoid staleness • No keyed MIC • No authentication for reassociate, disassociate • No IV replay protection • Use of Kerberos for authentication within IEEE 802.1X Bernard Aboba, Microsoft

6. WEP2 Security Analysis • IV (key) reuse • Larger IV, re-key support makes unintentional reuse much less likely • Without IV replay protection, intentional reuse still possible • Known/Partial plaintext attacks • Not affected by larger IV • Probing, key stream extension still possible in absence of keyed MIC • Still possible to recover key streams via ping from Internet • Can still forge packets by reusing IV, key stream • Can still divert traffic in absence of non-linear, keyed MIC • Authentication forging attack • Not affected by larger IV, since intentional IV replay still possible • Dictionary attack • New vulnerabilities introduced by mandatory KerberosV authentication • Realtime decryption • Much more difficult due to larger IV • 2^128 * 1500 octets = 5.1E32 GB Bernard Aboba, Microsoft

7. KerberosV Dictionary Attack Vulnerabilities • References • Bellovin & Meritt “Limitations of the Kerberos authentication system”, USENIX 1991 • Wu, T. “A Real-World Analysis of Kerberos Password Security”, 1998 http://theory.stanford.edu/~tjw/krbpass.html • Scenario • Attacker snoops AS_REQ/AS_REP exchange, recovers passwords offline • In popular 802.11 networks (“hot spots”), may be possible to collect many such exchanges in a single attempt • Vulnerabilities • PADATA or TGT encrypted with client Key derived from password via STRING-TO-KEY(P) • Results [Wu, 1998] • Password checkers not successful in significantly increasing password entropy • Structure of TGT (service name = krbtgt) enables verification of key guess by decrypting only 14 octets; similar issues with PADATA • Use of DES to encrypt TGT enables use of parallel DES cracking techniques • Of 25,000 sample TGTs, 2045 could be decrypted in two weeks using a cluster of 3 UltraSPARC-2 (200 Mhz) and 5 UltraSPARC-1 (167 Mhz) machines • Today, 15 off-the-shelf PCs could accomplish the same thing in 1 day at a cost of < $15K Bernard Aboba, Microsoft

8. Solutions • Machine versus user authentication • Machine keys typically have full entropy • Use of alterative ciphers in Kerberos • Draft-raeburn-krb-gssapi-krb5-3des-01.txt • Draft-raeburn-krb-rijndael-krb-00.txt • Revision to Kerberos [Wu] • SRP used for Kerberos pre-authentication • Derived key used to encrypt TGT Bernard Aboba, Microsoft

9. Reassociate, Disassociate & Beacon Security • Currently, reassociate, disassociate messages are not secure • Enables denial of service attacks • Proposal • Add an authenticator to reassociate and disassociate messages • Replay counter, HMAC-SHA1 (replay counter || SourceMAC || destMAC || transmit key) • On disassociate: ignore if HMAC is not valid • On reassociate: validate authenticator via move-request to old AP; if invalid, old AP ignores move-request • Beacon security • Currently, beacon messages are not authenticated • Enables station to roam to a rogue AP • Proposal: validate beacon before reassociating • Replay Counter, HMAC-SHA1 (replay counter || sourceMAC || multicast key) • Any station can forge this, but better than nothing Bernard Aboba, Microsoft

10. Summary – Vulnerabilities Thwarted Bernard Aboba, Microsoft

11. Conclusions • WEP2 not significantly more secure than WEPv1.0 • Small IV only part of the problem; absence of a keyed MIC remains a major deficiency • Denial of service attacks not addressed • WEP2 should not be treated as a significant security enhancement (should state this explicitly in security considerations section) • Kerberos V vulnerable to dictionary attack • Most important in “Hot spot” scenarios where many exchanges could be recovered • Expect at least 10 percent of passwords to be crackable in 24 hours • Downside greater than WEP v1.0 vulnerabilities: not only can traffic be decrypted, but attacker can assume user identity and access other services! • Protocol modifications required to address the vulnerability • Support for 3DES, AES ciphers • Support for SRP pre-authentication • Backward compatibility issues • AP with built-in KDC • AP would need software upgrade to support new ciphers, pre-auth types • AP in “pass-through” mode (IAKERB or RADIUS) • AP does not need to understand AS_REQ/AS_REP, so no issue Bernard Aboba, Microsoft

12. Recommendations • Examine feasibility of adding keyed MIC to WEP2 • Without keyed MIC, downplay security value of WEP2 • Make this clear up front • Choose a mandatory-to-implement authentication method resistant to dictionary attack • Example: SRP: RFC 2945 • EAP-SRP: draft-ietf-pppext-eap-srp-01.txt Bernard Aboba, Microsoft