Analysis of the i 4-Way Handshake Changhua He, John C Mitchell Stanford University WiSE, Oct. 1, 2004

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

IEEE i 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  Open System Authentication and Association  EAP/802.1X/RADIUS Authentication  4-Way Handshake  Group Key Handshake  Secure Data Communications

Authentica- tion Server (RADIUS) No Key Authenticator UnAuth/UnAssoc 802.1X Blocked No Key Supplicant UnAuth/UnAssoc 802.1X Blocked No Key Supplicant Auth/Assoc 802.1X Blocked No Key Authenticator Auth/Assoc 802.1X Blocked No Key Authentica- tion Server (RADIUS) No Key Association EAP/802.1X/RADIUS Authentication Supplicant Auth/Assoc 802.1X Blocked MSK Authenticator Auth/Assoc 802.1X Blocked No Key Authentica- tion Server (RADIUS) MSK Supplicant Auth/Assoc 802.1X Blocked PMK Authenticator Auth/Assoc 802.1X Blocked PMK Authentica- tion Server (RADIUS) No Key 4-Way Handshake Supplicant Auth/Assoc 802.1X UnBlocked PTK/GTK Authenticator Auth/Assoc 802.1X UnBlocked PTK/GTK Authentica- tion Server (RADIUS) No Key Group Key Handshake Supplicant Auth/Assoc 802.1X UnBlocked New GTK Authenticator Auth/Assoc 802.1X UnBlocked New GTK Authentica- tion Server (RADIUS) No Key Data Communication Supplicant Auth/Assoc 802.1X UnBlocked PTK/GTK Authenticator Auth/Assoc 802.1X UnBlocked PTK/GTK Authentica- tion Server (RADIUS) No Key RSNA Conversations

Supplicant Auth/Assoc 802.1X Blocked PMK Authenticator Auth/Assoc 802.1X Blocked PMK Authentica- tion Server (RADIUS) No Key The 4-Way Handshake AssociationEAP/802.1X/RADIUS Authentication Group Key Handshake Data Communication MSK {AA, ANonce, sn, msg1, PMKID} {SPA, SNonce, SPA RSN IE, sn, msg2, MIC} {AA, ANonce, AA RSN IE, GTK, sn+1, msg3, MIC} {SPA, sn+1, msg4, MIC} Supplicant Auth/Assoc 802.1X UnBlocked PTK/GTK Authenticator Auth/Assoc 802.1X UnBlocked PTK/GTK Authentica- tion Server (RADIUS) No Key

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 PTK=PRF{PMK, AA||SPA||ANonce||SNonce}  Analysis  Based on the existing specifications of the 4-way handshake  Mur j verification using “rationale reconstruction”

Finite-State Verification... Correctness condition violated  Murφ rules for protocol participants and the intruder define a nondeterministic state transition graph  Murφ will exhaustively enumerate all graph nodes  Murφ will verify whether specified security conditions hold in every reachable node  If not, the path to the violating node will describe the attack

Running Murφ Intruder Model Analysis Tool Formal Protocol Informal Protocol Description Find error Mur j code RFC, IEEE Std. Mur j code, similar for all protocols Specify security conditions and run Mur j

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

Simplified 4-Way Handshake AA, ANonce, AA RSN IE, GTK, sn+1, msg3, MIC SPA, sn+1, msg4, MIC PTK Derived Random GTK PTK and GTK 802.1X Unblocked PTK and GTK 802.1X Unblocked Supplicant Auth/Assoc 802.1X Blocked PMK Authenticator Auth/Assoc 802.1X Blocked PMK AA, ANonce, sn, msg1 SPA, SNonce, SPA RSN IE, sn, msg2, MIC

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

Forged Message 1 Attack AA, ANonce, AA RSN IE, GTK, sn+1, msg3, MIC SPA, sn+1, msg4, MIC PTK Derived Random GTK PTK and GTK 802.1X Unblocked PTK and GTK 802.1X Unblocked Supplicant Auth/Assoc 802.1X Blocked PMK Authenticator Auth/Assoc 802.1X Blocked PMK AA, ANonce, sn, msg1 SPA, SNonce, SPA RSN IE, sn, msg2, MIC AA, ANonce, sn, msg1

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

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

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

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 PTK=PRF{PMK, AA||SPA||ANonce||SNonce}  More computations in the supplicant Performance Degradation

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

Conclusion & Future Work  Conclusions  Simplified protocol and several clarifications  Parallel instances exist => Forged Message 1 attack  Keep all states => 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 i correctness