submission august 2001 nancy cam-winget, atheros slide 1 rapid re-keying wep a recommended practice...

August 2001

Nancy Cam-Winget, AtherosSlide 1Submission

Rapid Re-keying WEPa recommended practice to improve

WLAN Security

Nancy Cam-Winget, Atheros

Jesse Walker, Intel Corp

Bernard Aboba, Microsoft Corp

Joe Kubler, Intermec Corp

August 2001


Outline

• WEP attacks summary • Improving WEP• Recommended Practice

August 2001


WEP Summary of Attacks• Downloadable procedures

– To crack the Key:• http://airsnort.sourceforge.net/• http://sourceforge.net/projects/wepcrack/

– To brute force enter into WLAN, select THC-RUT from • http://www.thehackerschoice.com/releases.php

• Attacks based on [Walker], [Arbaugh], [Berkeley team], [Fluhrer/Shamir]

– Lack of IV replay protection– Short IV sequence space– RC4 vulnerabilities due to WEP’s implementation– Linear properties of CRC32 (allows bit flipping))

– Lack of keyed MIC– Use of shared keys

August 2001


Quest to Improve WEP

• How can we improve WEP security and– Retain (most) performance

• Enhance without greatly reducing line rates

– Easily upgrade deployed systems• Avoid hardware upgrades

– Retain interoperability• Allow most deployed systems to upgrade• Allow for incremental deployment• Allow legacy systems to continue to work without

improvements

• Provide better protection until AES is available

August 2001


Improving WEP’s Security

• Recommended Practice includes1. Per-link keys

• Unique key per STA

2. IV Sequencing – Check for monotonically increasing IVs – Weak IV avoidance

3. 104-bit keys– IV + Key = 128-bits

4. Rapid Rekey• Derive WEP keys from master key• Change encryption key frequently

August 2001


Rapid Rekey Explained

• MAC-Layer Authenticated Key Refresh– 3-way handshake between AP and STA

– Authenticates the refresh operation

– Ensures master keys are synchronized

– Key material is exchanged

– Increases master key entropy (lifetime)

– Uses HMAC-MD5 to authorize the exchange

August 2001


Rekey every 10K frames(as recommeded by Shamir)

Probability of Key word recovery for WEP

IV Length Probability Expected IVs required

3 bytes 4.57 x 10-5 1310K

8 bytes 2.8 x 10-4 214K

12 bytes 5.04 x 10-4 119K

16 bytes 7.18 x 10-4 83.6K

August 2001


Rekey impact

Bit Rate

Mbits/sec

Time Frequency* between key refreshes

50k pkts

(sec)

10k pkts

(sec)

6 30 6

11 16.3 3.3

54 3.3 .67

*Based on 450byte packet size

August 2001


MAC-Layer Authenticated Key Refresh

Bit Rate

Mbits/sec

Rekey Time Requirements

Air + CPU Air1 CPU2

6 2762 usec 2562 usec

200usec11 1598 usec 1398 usec

54 484 usec 284 usec1 Time required to transfer exchange packets over the air

2 Time required to perform Authenticated Key Refresh on 333MHz Pentium Pro, using HMAC-MD5 for authentication and AES-CBC-MAC for key derivation

August 2001


Recommended Practice Improves WEP Security

• IV Sequence check protects from both intentional and unintentional IV reuse

• Protection from IV reuse makes it harder to mount attacks [Arbaugh], [Berkeley team] and [Shamir] Longer Key requires adversary to acquire more packets for key recovery (derived key, not master key)

• Authenticated Key Refresh provides a secure and synchronized mechanism for rekeying

August 2001


Improvements to WEP Security (cont’d)

• Frequent rekeying makes it harder to recover (derived) encryption key. Even if key is cracked, it’s only the temporal encryption key vs. master

• MAC-Layer Rekeying allows for faster refresh• Implementation is backward compatible. All

improvements are additions on top of current WEP implementations.

August 2001


On the Flip side…..

• Recommended Practice does not address– Bit-flipping attacks: a keyed MIC is required

• Active attacks

• But IV sequencing protects from

– Shared keys• Provide more data for passive attacks

• Rekeying could be adapted for shared keys

August 2001


Alternatives Considered

• Removing first 256 bytes of RC4 key stream– Not backward compatible– Still requires IV Sequencing and Keyed MIC– Must be treated as separate encryption to old RC4

• Prepending N pseudorandom bytes to plaintext data– Not backward compatible– Unclear what a sufficient N should be– Increases per packet overhead– Still requires IV Sequencing and Keyed MIC– Must be treated as separate encryption to old RC4

August 2001


Alternatives Discussed (cont’d)

• Using Beacon as a means to synchronize new key– Only addresses shared key

– Rekeying is not authenticated (i.e. insecure)

– Constrained to rekey only on Beacon intervals

• Using a Longer IV– Worsens security it reduces the number of frames

required to recover key!

August 2001


Call To Action

• WECA to form a subcommittee to– Establish requirements for rapid rekeying

– Create test plan for rapid rekeying

• Subcommittee to present solution for review at the next WECA meeting

August 2001


Comments?

August 2001


Appendix A

August 2001


Known Classes of Attacks on WEP

• IV Reuse [Walker, Berkeley team, Arbaugh, Fluhrer]

– Lack of replay protection allows IV values to be reused

– Collisions made possible by small IV space in WEP

– Enables statistical attack against ciphertexts with replayed IVs

• Known plaintext attack [Walker, Berkeley team, Arbaugh, Fluhrer]

– 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 [Arbaugh]

– Enables statistical attack and recovery of Key with known IVs [Fluhrer]

August 2001


Classes of Attacks (cont’d)

• Partial known plaintext [Berkeley team, Arbaugh, Shamir, Fluhrer]

– May only know a portion of the plaintext (e.g. IP header, SNAP)

– Possible to recover M octets of the keystream, M < N

– Statistical analysis of plaintext and IV shows keystream bias [Shamir]

– Statistical analysis of plaintext and IV allows Key recovery [Fluhrer]

– Via repeated probing, can extend keystream from M to N [Arbaugh]

• CRC32 [Berkeley team, Arbaugh]– Linearity of algorithm and absence of Key use allows for forgery

– Possible to flip bits in realtime, adjust CRC32 and cause denial of service

August 2001


Classes of Attacks (cont’d)

• Authentication forging [Berkeley team]– WEP encrypts challenge using IV chosen by client

– Recovery of key stream for a given IV enables re-use of that IV for forging WEP authentication and thus recovery of key

• Reliance on security strength of external authentication mechanisms– Some are vulnerable to dictionary attacks (and thus key

recovery)

August 2001


Authenticated Key Refresh

AP

STA

AP

STA

msg-1: Negotiate key sync,pass nonce

msg-2: Negotiate key sync,pass nonce, authenticate keys

msg-3: Final agreement andauthentication

August 2001


Why MAC-Layer vs. Upper-Layer

• Allows for interoperability with legacy systems– Minimizes protocols to be added for key management– If legacy doesn’t support rekeying, packets can be dropped

(ignored); new system can force full authentication (at performance cost)

• Allows for optimal efficiency– Reduces interdependencies between MAC and Upper Layer– Reduces exchanges between Layers– Reduces key synchronization complexity between Peers & Layers

• Allows for interoperability with ESN– Same mechanism can be used for AES

submission august 2001 nancy cam-winget, atheros slide 1 rapid re-keying wep a recommended practice...

Documents