1 / 18

Analysis of the 802.11i 4-Way Handshake

Analysis of the 802.11i 4-Way Handshake. Changhua He, John C Mitchell Stanford University WiSE , Oct. 1, 2004. Outline. IEEE 802.11i RSNA (Robust Security Network Association) 4-Way Handshake ( our focus ! ) Murφ Verification Murφ Modeling Clarifications of the protocol

Thomas
Télécharger la présentation

Analysis of the 802.11i 4-Way Handshake

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  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 !) • 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

  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. Supplicant UnAuth/UnAssoc 802.1X Blocked No Key Supplicant Auth/Assoc 802.1X Blocked No Key Supplicant Auth/Assoc 802.1X UnBlocked PTK/GTK Supplicant Auth/Assoc 802.1X Blocked MSK Supplicant Auth/Assoc 802.1X UnBlocked New GTK Supplicant Auth/Assoc 802.1X Blocked PMK Supplicant Auth/Assoc 802.1X UnBlocked PTK/GTK AuthenticatorAuth/Assoc 802.1X UnBlocked New GTK AuthenticatorAuth/Assoc 802.1X Blocked No Key AuthenticatorAuth/Assoc 802.1X UnBlocked PTK/GTK AuthenticatorAuth/Assoc 802.1X UnBlocked PTK/GTK AuthenticatorUnAuth/UnAssoc 802.1X Blocked No Key AuthenticatorAuth/Assoc 802.1X Blocked PMK AuthenticatorAuth/Assoc 802.1X Blocked No Key Authentica-tion Server(RADIUS) No Key Authentica-tion Server(RADIUS) No Key Authentica-tion Server(RADIUS) No Key Authentica-tion Server(RADIUS) MSK Authentica-tion Server(RADIUS) No Key Authentica-tion Server(RADIUS) No Key Authentica-tion Server(RADIUS) No Key 802.11 Association EAP/802.1X/RADIUS Authentication MSK 4-Way Handshake Group Key Handshake Data Communication RSNA Conversations

  5. Supplicant Auth/Assoc 802.1X Blocked PMK Supplicant Auth/Assoc 802.1X UnBlocked PTK/GTK AuthenticatorAuth/Assoc 802.1X Blocked PMK AuthenticatorAuth/Assoc 802.1X UnBlocked PTK/GTK Authentica-tion Server(RADIUS) No Key Authentica-tion Server(RADIUS) No Key 802.11 Association EAP/802.1X/RADIUS Authentication {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} Group Key Handshake Data Communication 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 PTK=PRF{PMK, AA||SPA||ANonce||SNonce} • Analysis • Based on the existing specifications of the 4-way handshake • Murj verification using “rationale reconstruction”

  7. Finite-State Verification • 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 ... ... Correctness condition violated

  8. Running Murφ Informal Protocol Description Formal Protocol Intruder Model 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. AA, ANonce, sn, msg1 SPA, SNonce, SPA RSN IE, sn, msg2, MIC Simplified 4-Way Handshake Supplicant Auth/Assoc 802.1X Blocked PMK AuthenticatorAuth/Assoc 802.1X Blocked PMK PTK Derived PTK Derived Random GTK AA, ANonce, AA RSN IE, GTK, sn+1, msg3, MIC SPA, sn+1, 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. AA, ANonce, sn, msg1 SPA, SNonce, SPA RSN IE, sn, msg2, MIC AA, ANonce, sn, msg1 AA, ANonce, sn, msg1 Forged Message 1 Attack Supplicant Auth/Assoc 802.1X Blocked PMK AuthenticatorAuth/Assoc 802.1X Blocked PMK PTK Derived PTK Derived Random GTK AA, ANonce, AA RSN IE, GTK, sn+1, msg3, MIC SPA, sn+1, 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 PTK=PRF{PMK, AA||SPA||ANonce||SNonce} • 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 => 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 802.11i correctness

More Related