WEP2 Security Analysis

12
May 2001 Bernard Aboba, Microsoft Slide 1 doc.: IEEE 802.11- 00/253 Submission WEP2 Security Analysis Bernard Aboba Microsoft

description

WEP2 Security Analysis. Bernard Aboba Microsoft. Goals. To (briefly) summarize security weaknesses discovered in WEP v1.0 To analyze security vulnerabilities of WEP2 To recommend potential improvements. Classes of Attacks Against WEP v1.0. IV (key) reuse [Walker, Berkeley team, Arbaugh] - PowerPoint PPT Presentation

Transcript of WEP2 Security Analysis

Page 1: WEP2 Security Analysis

May 2001

Bernard Aboba, MicrosoftSlide 1

doc.: IEEE 802.11-00/253

Submission

WEP2 Security Analysis

Bernard Aboba

Microsoft

Page 2: WEP2 Security Analysis

May 2001

Bernard Aboba, MicrosoftSlide 2

doc.: IEEE 802.11-00/253

Submission

Goals• To (briefly) summarize security weaknesses discovered

in WEP v1.0• To analyze security vulnerabilities of WEP2• To recommend potential improvements

Page 3: WEP2 Security Analysis

May 2001

Bernard Aboba, MicrosoftSlide 3

doc.: IEEE 802.11-00/253

Submission

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

Page 4: WEP2 Security Analysis

May 2001

Bernard Aboba, MicrosoftSlide 4

doc.: IEEE 802.11-00/253

Submission

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

Page 5: WEP2 Security Analysis

May 2001

Bernard Aboba, MicrosoftSlide 5

doc.: IEEE 802.11-00/253

Submission

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

Page 6: WEP2 Security Analysis

May 2001

Bernard Aboba, MicrosoftSlide 6

doc.: IEEE 802.11-00/253

Submission

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

Page 7: WEP2 Security Analysis

May 2001

Bernard Aboba, MicrosoftSlide 7

doc.: IEEE 802.11-00/253

Submission

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

Page 8: WEP2 Security Analysis

May 2001

Bernard Aboba, MicrosoftSlide 8

doc.: IEEE 802.11-00/253

Submission

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

Page 9: WEP2 Security Analysis

May 2001

Bernard Aboba, MicrosoftSlide 9

doc.: IEEE 802.11-00/253

Submission

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

Page 10: WEP2 Security Analysis

May 2001

Bernard Aboba, MicrosoftSlide 10

doc.: IEEE 802.11-00/253

Submission

Summary – Vulnerabilities Thwarted

Attack WEPv1.0 WEP v2.0 + KerbV AES + KerbV AES + SRPUnintentional IV reuse X X XIntentional IV reuse X XRealtime decryption X X XKnown plaintext X XPartial known plaintext X XAuthentication forging X XDenial of Service w/fix w/fix w/fixDictionary attack X

Page 11: WEP2 Security Analysis

May 2001

Bernard Aboba, MicrosoftSlide 11

doc.: IEEE 802.11-00/253

Submission

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

Page 12: WEP2 Security Analysis

May 2001

Bernard Aboba, MicrosoftSlide 12

doc.: IEEE 802.11-00/253

Submission

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