Analysis of the 802.11i 4-Way Handshake

1
Analysis of the 802.11i 4-Way Handshake

• Changhua He, John C Mitchell
• Stanford University
• WiSE, Oct. 1, 2004

2
Outline

• IEEE 802.11i
• RSNA (Robust Security Network Association)
• 4-Way Handshake (our focus !)
• Murf Verification
• Murf Modeling
• Clarifications of the protocol
• Forged Message 1 attack
• DoS attack countermeasures
• DoS attack in practical implementation
• 3 possible countermeasures
• Conclusion Future work

3
IEEE 802.11i Standard

• Ratified on June 24, 2004
• Components
• RSNA and Pre-RSNA algorithms
• WEP, TKIP included for backward compatibility
• CCMP as a long-term solution with hardware
  upgrade
• RSNA Establishment Procedures
• Network and Security Capability Discovery
• 802.11 Open System Authentication and Association
• EAP/802.1X/RADIUS Authentication
• 4-Way Handshake
• Group Key Handshake
• Secure Data Communications

4
RSNA Conversations
5
The 4-Way Handshake
MSK
6
Problem Statement

• Assumption
• PMK is shared between the Supplicant and the
  Authenticator
• The AS move the key materials to the
  Authenticator
• Handshake Goals
• Confirm the possession of PMK
• Derive a fresh session key for data transmission
• PTKPRFPMK, AASPAANonceSNonce
• Analysis
• Based on the existing specifications of the 4-way
  handshake
• Murj verification using rationale reconstruction

7
Finite-State Verification

• Murf rules for protocol participants and the
  intruder define a nondeterministic state
  transition graph
• Murf will exhaustively enumerate all graph nodes
• Murf will verify whether specified security
  conditions hold in every reachable node
• If not, the path to the violating node will
  describe the attack

...
...
Correctness condition violated
8
Running Murf
Informal Protocol Description
Intruder Model
Formal Protocol
Murj code
Murj code, similar for all protocols
RFC, IEEE Std.
Analysis Tool
Find error
Specify security conditions and run Murj
9
Modeling the 4-Way Handshake

• Authenticators/Supplicants
• Each authenticator maintain one association with
  each supplicant, and vice versa
• Each association has a uniquely shared PMK
• Multiple sequential legitimate handshakes in one
  association
• Intruder
• Impersonate both supplicant and authenticator
• Eavesdrop, intercept and replay messages
• Compose messages with known nonce and MIC
• Forge fresh Message 1
• Predict and replay nonces for pre-computation of
  MIC
• Rationale reconstruction
• Turn on/off fields nonce, sequence, msg, address

10
Simplified 4-Way Handshake
Supplicant Auth/Assoc 802.1X Blocked PMK
Authenticator Auth/Assoc 802.1X Blocked PMK
PTK Derived
PTK Derived Random GTK
AA, ANonce, AA RSN IE, GTK, sn1,
msg3, MIC
SPA, sn1, msg4, MIC
PTK and GTK 802.1X Unblocked
PTK and GTK 802.1X Unblocked
11
Protocol Clarifications

• Sequence number, AA, SPA
• Essentially redundant
• Message flag
• Nessary to be included and protected
• otherwise could ambiguously use Msg 2 as 3, or
  vice versa
• Exclusive supplicant and authenticator
• Otherwise reflection attacks
• Fresh nonces
• globally unique and unpredictable
• Otherwise pre-computation attacks and replay
  attacks

12
Forged Message 1 Attack
Supplicant Auth/Assoc 802.1X Blocked PMK
Authenticator Auth/Assoc 802.1X Blocked PMK
PTK Derived
PTK Derived Random GTK
AA, ANonce, AA RSN IE, GTK, sn1,
msg3, MIC
SPA, sn1, msg4, MIC
PTK and GTK 802.1X Unblocked
PTK and GTK 802.1X Unblocked
13
DoS attack

• TPTK/PTK solution
• Proposed in the documentation
• not work for all cases
• Keep states for every incoming Message 1
• DoS attack Memory/CPU exhaustion
• Like a TCP SYN flooding attack
• Interleaving handshakes
• Authenticator could only accept expected messages
• Supplicant could not do so, must accept Msg 1 in
  all stages
• Parallel handshake instances exist

14
Countermeasures (1)

• Random-Drop Queue
• Randomly drop a stored entry to adopt the state
  for the incoming Message 1 if the queue is filled.

Not so effective
15
Countermeasures (2)

• Authenticate Message 1
• To reuse the algorithms/hardware, set nonces to
  special values, e.g., 0, and derive PTK.
• Calculate MIC for Msg 1 using the derived PTK
• Good solution if PMK is fresh
• If PSK and cached PMK, replay attacks !
• Add a monotonically increasing global sequence
  counter
• Use local time in authenticator side
• Sufficient space in Message 1 ( 8-octet sequence
  field )
• No worry about time synchronization

Modifications on packet format
16
Countermeasures (3)

• Re-Use Nonce
• Supplicant re-use SNonce until one 4-way
  handshake completes successfully
• Derive correct PTK from Message 3
• Authenticator may (or may not) re-use ANonce
• Solve the problem, but
• Attacker might gather more infomation about PMK
  by playing with Message 1, recall
• PTKPRFPMK, AASPAANonceSNonce
• More computations in the supplicant

Performance Degradation
17
Our Proposal

• Combined solution
• Supplicant re-use SNonce
• Store one entry of ANonce and PTK for the first
  Message 1
• If nonce in Message 3 matches the entry, use PTK
  directly otherwise derive PTK again and use it.
• Advantages
• Eliminate the memory DoS attack
• Ensure performance in friendly scenarios
• Only minor modifications on the algorithm in the
  Supplicant
• No modifications on the packet format
• Adopted by TGi
• Documentation will be updated once a chance

18
Conclusion Future Work

• Conclusions
• Simplified protocol and several clarifications
• Parallel instances exist gt Forged Message 1
  attack
• Keep all states gt Denial-of-Service attack
• 3 countermeasures and the effectiveness
• Proposed solution
• Supplicant re-use SNonce to eliminate the
  vulnerability
• Supplicant may store one entry of PTK for
  performance
• no modifications on the packet format, adopted by
  TGi
• Future Work
• A full study of the 802.11i correctness