1
play

1 Description Mur Modeling Prior to 4-way handshake, we assume: - PDF document

Oct 29, 2022 •244 likes •285 views

Scenario: 802.11 Analysis of 4-way handshake protocol in IEEE 802.11i Wired Network Changhua He Stanford University Security ! Mar. 04, 2004 An example of a 802.11 wireless local area network History of Security Concerns Terms

  1. Scenario: 802.11 Analysis of 4-way handshake protocol in IEEE 802.11i Wired Network Changhua He Stanford University Security ! Mar. 04, 2004 An example of a 802.11 wireless local area network History of Security Concerns Terms � 802.11b (WEP) � Authenticator: Entities implemented in AP • Wired Equivalent Protocol � Supplicant: Entities implemented in Laptop • Many attacks found � Authentication Server � WPA: Wi-Fi Protected Access � PMK: Pair-wise Master Key • Proposed by Wi-Fi Alliance • Short-term solution based on 802.1x � PTK: Pair-wise Transient Key � 802.11i � MIC: Message Integrity Code • Standards approved Oct. 2003 � ANonce: nonce generated by authenticator • Long-term solution, may need hardware � SNonce: nonce generated by supplicant upgrades � AA: Authenticator Address (MAC) • This project focus on part of the authentication protocol in the standard � SPA: Supplicant Address (MAC) 802.11i Authentication Idealized 4-way Handshake Access Point Wireless Access Point Wireless Channel Ethernet Laptop computer Radius Server Laptop computer Ethernet PMK Known, PMK Known, Counter = n Last Seen < n 802.11 Association {AA, ANonce, n, msg1} PTK=PRF{PMK,AA||STA||Anonce||Snonce} 802.1x/Radius/EAP-TLS {SPA, SNonce, n, msg2, MIC PTK (SNonce, n, msg2)} Derive PTK, Counter = n+1 4-way Key management {AA, ANonce, n+1, msg3, MIC PTK (ANonce, n+1, msg3)} Install PTK, Last Seen = n+1 {SPA, n+1, msg4, MIC PTK (n+1, msg4)} Group Key management Install PTK, Counter = n+2 Secured Data Channel 1

  2. Description Mur φ Modeling � Prior to 4-way handshake, we assume: � Authenticators/Supplicants: • PMK only known to Supplicant and • Each authenticator maintain associations Authenticator, never transmitted over network with each supplicant, and vice versa � Objectives: • Each association has a unique PMK • Generate PTK and confirm the procession and freshness of PTK • Several sessions can happen in one � Methodology: association sequentially • Use Mur ϕ to model the protocol from simplest � In each run: version, find out attacks, add fields step by step to defense the attacks, get complete one. • Turn on/off fields: nonce, sequence, • Can make clear the function of each fields, and mtype, address find out attacks for the complete protocol. Intruder Invariant � Impersonate both supplicant and invariant "PTKs are consistent and fresh" forall i: AuthenticatorId do authenticator forall j: SupplicantId do • Forge MAC address in each message aut[i].associations[j].session.state = A_DONE • Can not get PMK for associations � Intercepts all messages -> � Replay all messages (sup[j].associations[i].session.state = S_DONE & � Forge messages with known nonce and MIC ptkEqual(aut[i].associations[j].session.ptk, sup[j].associations[i].session.ptk) & � Compose message 1 with known nonces aut[i].associations[j].sid = sup[j].associations[i].sid) | � Actively predict nonces and ask the (sup[j].associations[i].session.state = S_PTKSA & supplicant to pre-compute MIC aut[i].associations[j].sid <= sup[j].associations[i].sid) • Model attacks when nonces are predictable or end not globally unique end; Achieved protocol Summary of fields � Nonces is necessary for fresh PTK Access Point � Mtype Wireless Channel Ethernet Laptop computer • Necessary, otherwise can fool supplicant to calculate msg 3, or vice versa {ANonce, msg1} � Sequence PTK=PRF{PMK,Anonce||Snonce} • Not necessary here {SNonce, msg2, MIC PTK (SNonce, msg2)} • Defense msg 3 replay, but it is harmless � AA, SPA {ANonce, msg3, MIC PTK (ANonce, msg3)} • Bind PTK to the physical device, not necessary here, but need to be {msg4, MIC PTK (msg4)} considered with PMK 2

  3. Implementation error DoS attack Access Point • Intruder keep sending msg. 1 to Supplicant, Wireless Channel Ethernet supplicant needs to keep all the states Laptop computer • No CPU exhaustion attack assume hash is easy {AA, ANonce, n, msg1} to compute {SPA, SNonce, n, msg2, MIC PTK (SNonce, n, msg2)} • But maybe memory exhaustion attack {AA, Nonce, n, msg1} – Not consume much memory for each state – But so easy for the attacker to flooding msg 1 • Possible Solution {AA, ANonce, n+1, msg3, MIC PTK (ANonce, n+1, msg3)} – Send Anonce together with Snonce in msg 3 {SPA, n+1, msg4, MIC PTK (n+1, msg4)} – Sequence acts to defense replay {AA, Nonce, n, msg1} – Need to change packet formats • The standard adopts TPTK & PTK: not work Conclusions � Murphi Modelling • Suitable for finite state verification • Inspiration for finding attacks, but need to model attacks correctly • Can not model DoS attacks � 802.11i 4-way handshake protocol • Fortunately, well-designed & secure • Some fields are redundant for this part • Implementation error (corresponding to DoS attack) 3

Recommend

More recommend