1 / 56

802.11i Security Analysis: Can we build a secure WLAN?

802.11i Security Analysis: Can we build a secure WLAN?. Changhua He Stanford University March 24 th , 2005 Changhua@stanford.edu. Outline. WLAN Security Overview Wireless Local Area Networks Wireless threats Wireless security history IEEE 802.11i Standard

tuyen
Download Presentation

802.11i Security Analysis: Can we build a secure WLAN?

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. 802.11i Security Analysis: Can we build a secure WLAN? Changhua He Stanford University March 24th, 2005 Changhua@stanford.edu

  2. Outline • WLAN Security Overview • Wireless Local Area Networks • Wireless threats • Wireless security history • IEEE 802.11i Standard • Finite-state Verification of 4-Way Handshake • More Insecurities and Improvements • Modular Proof of Security • Conclusions

  3. 802.11 Infrastructure Network Wired Network Can we build a secure WLAN ?

  4. Wireless Threats • Passive Eavesdropping/Traffic Analysis • Easy, most wireless NICs have promiscuous mode • Message Injection/Active Eavesdropping • Easy, some techniques to gen. any packet with common NIC, exploit MAC cooperation to interfere in a timely way • Message Deletion and Interception • Possible, interfere packet reception with directional antennas • Masquerading and Malicious AP • Easy, MAC address forgeable and s/w available (HostAP) • Session Hijacking • Man-in-the-Middle • Denial-of-Service Attack

  5. History of Wireless Security • 802.11 (Wired Equivalent Protocol) • Authentication: Open system (SSID) and Shared Key • Authorization: some vendor use MAC address filtering • Confidentiality/Integrity: RC4 + CRC • Completely insecure [Walker00,Arbaugh01,Wagner01,FMS01 …] • WPA: Wi-Fi Protected Access • Authentication: 802.1X • Confidentiality/Integrity: TKIP • Reuse the legacy hardware, still problematic [Arbaugh02 …] • Availability is a big problem • Frequency jamming: inevitable but expensive and detectable • Network and upper Layer: depend on protocols • Link Layer DoS attack: unprotected management frames [Arbaugh et al 01] [Bellardo et al 03] [Chen04] …

  6. Outline • WLAN Security Overview • IEEE 802.11i Standard • Data confidentiality and integrity • Mutual authentication • Key management protocols • Finite-state Verification of 4-Way Handshake • More Insecurities and Improvements • Modular Proof of Security • Conclusions

  7. IEEE 802.11i • Ratified on June 24, 2004 • Data confidentiality and integrity • Encryption in Data Link Layer • WEP: Wired Equivalent Privacy • TKIP: Temporal Key Integrity Protocol • CCMP: Counter-mode/CBC-MAC Protocol • Long term solution, need hardware upgrade • With a fresh key, 802.11i CCMP is believed secure for data confidentiality and integrity ! • Mutual authentication • RSNA: Robust Security Network Association • EAP-TLS/802.1X/RADIUS • Key management • 4-Way handshake, Group key handshake

  8. RSNA Establishment • 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 • Our security analysis gives: • can provide satisfactory authentication and key management • could be problematic in Transient Security Networks (TSN) • reflection attack could be possible if not implemented correctly • Availability is still problematic

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

  10. Outline • WLAN Security Overview • IEEE 802.11i Standard • Finite-state Verification of 4-Way Handshake • Murφ Model Checker • Modeling the 4-way handshake • Attacks and solutions • More Insecurities and Improvements • Modular Proof of Security • Conclusions

  11. Finite-State Verification • Powerful methodology • Used in protocol and software verifications • No requirements on implementations • Comparing to static analysis and dynamic tracing • Challenges • Requires complete understanding of what you check • State space reduction techniques • Many tools available • Generic model checking: • Murφ, Spin, SMV • Automatic model generation model checking: • Pathfinder, Bandera, Verisoft

  12. Murφ Model Checker • 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

  13. 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

  14. Diagnosing Errors • Bad abstraction • Removed too much detail from the protocol when constructing the abstract model • Add the piece that fixes the bug and repeat • Genuine attack • Yay! Hooray! • Attacks found by formal analysis are usually quite strong • Independent of specific cryptographic schemes • Independent of implementations, etc. • Test an implementation of the protocol, if available

  15. The 4-Way Handshake AA, ANonce, sn, msg1 SPA, SNonce, SPA RSN IE, sn, msg2, MIC 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

  16. Modeling the 4-Way Handshake • Authenticators/Supplicants: • An association is maintained between a pair of authenticator and supplicant • 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 • Invariants • Represent the security property, must be true for each state

  17. Authenticator Msg 1 (Murj) ruleset i: AuthenticatorId do ruleset j: AgentId do rule 20 "Authenticator sends Message 1 to associated Supplicants" !ismember(j, AuthenticatorId) & -- no message to Authenticators !ismember(j, IntruderId) & -- no message to Intruders multisetcount(l:net, true) < NetworkSize & (aut[i].associations[j].session.state = A_PMKSA | aut[i].associations[j].session.state = A_DONE) ==> var outM: Message; -- outgoing message begin outM.source := i; outM.dest := j; outM.mtype := M_1; outM.nonce := freshNonce(); outM.sequence := freshSequence(); outM.address := i; multisetadd(outM, net); aut[i].associations[j].peer := j; aut[i].associations[j].pmk := usePMK(i, j); aut[i].associations[j].sequence := outM.sequence; aut[i].associations[j].nonce := outM.nonce; aut[i].associations[j].session.state:= A_WAITFORNS; end; end; end;

  18. Invariant: Security Properties invariant "PTKs are consistent and fresh" forall i: AuthenticatorId do forall j: SupplicantId do aut[i].associations[j].session.state = A_DONE -> (sup[j].associations[i].session.state = S_DONE & ptkEqual(aut[i].associations[j].session.ptk, sup[j].associations[i].session.ptk) & aut[i].associations[j].sid = sup[j].associations[i].sid) | (sup[j].associations[i].session.state = S_PTKSA & aut[i].associations[j].sid <= sup[j].associations[i].sid) end; end;

  19. Forged Message 1 Attack AA, ANonce, sn, msg1 SPA, SNonce, SPA RSN IE, sn, msg2, MIC AA, ANonce, sn, msg1 AA, ANonce, sn, msg1 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

  20. 4-Way Handshake Blocking AA, ANonce, sn, msg1 SPA, SNonce, SPA RSN IE, sn, msg2, MIC AA, ANonce[1], sn, msg1 AA, ANonce[n], sn, msg1 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

  21. 4-Way Blocking: Solution 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

  22. 4-Way Blocking: Solution 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

  23. 4-Way Blocking: Solution 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 • More computations in the supplicant • Attacker might gather more infomation about PMK by playing with Message 1, ok if PMK is strong PTK=PRF{PMK, AA||SPA||ANonce||SNonce} Performance Degradation

  24. 4-Way Blocking: Solution 4 • 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 • Simple solution, but not immediate • Practical considerations, not designing a new protocol

  25. Reflection Attack {A1, Nonce1, sn, msg1} {A2, Nonce1, sn, msg1} {A1, Nonce2, RSN IE, sn, msg2, MIC} {A2, Nonce2, RSN IE, sn, msg2, MIC} {A1, Nonce1, RSN IE, GTK, sn+1, msg3, MIC} {A2, Nonce1, RSN IE, GTK, sn+1, msg3, MIC} {A1, sn+1, msg4, MIC} {SPA, sn+1, msg4, MIC} Bogus Authentication Peers Authenticated Adversary Impersonates Communicating Peers Legitimate Devices Authenticator and Supplicant

  26. Reflection Attack: Solutions • Possible in ad hoc networks • Each participant plays the role of both authenticator and supplicant • Less damage if strong confidentiality adopted • Adversary fool the peers to send packets • Cannot decrypt the packet and generate response • Violate the mutual authentication concept • Solutions: • Restrict each participant to play only one role: ok for WLAN, but inappropriate for ad hoc networks • Each participant play both roles, but under different PMK

  27. 4-Way Handshake Summary • Finite-state verification • Find subtle bugs, suitable for verifying “small” protocols • State-space explosion is a problem • Message 1 vulnerability • Forge first message to block the protocol • TPTK/PTK to prevent this, but only do partial work • Store all states, but queue size is a problem • Final solution adopted by Standards Committee • Reflection attack • Possible in ad hoc scenario • Each entity plays only one role, or both roles under different PMK

  28. Outline • WLAN Security Overview • IEEE 802.11i Standard • Finite-state Verification of 4-Way Handshake • More Insecurities and Improvements • Poisoning and rollback attacks • TKIP Michael Countermeasure problem • Failure recovery • Modular Proof of Security • Conclusions

  29. RSN IE Poisoning Bogus Beacon + Modified RSN IE Bogus Probe Response + Modified RSN IE Disassociate the Supplicant RSN IE confirmation failed, Disassociation Supplicant Unauthenticated Unassociated 802.1X Blocked AuthenticatorUnauthenticated Unassociated 802.1X Blocked (1) Beacon + AA RSN IE (2) Probe Request (3) Probe Response + AA RSN IE Legitimate Message Exchanges (18) {AA, ANonce, AA RSN IE, GTK, sn+1, msg3, MIC}

  30. RSN IE Poisoning: Solutions • Easy to launch the attack • Legitimate participants unaware of it • Continue message exchanges, waste resources • Adversary have more time to repeat the attack • Solutions • Authenticate management frames • Difficult to authenticate Beacon and Probe Response frame • Confirm RSN IE as soon as possible (EAP-TLS) • Necessary modifications on the standard • Relax the condition of RSN IE confirmation • Ignore insignificant bits, only confirm authentication suite • If authentication suite modified, probably fails at the beginning of associations and retry new APs

  31. Security Level Rollback Attack Bogus Beacon (Pre-RSNA only) Bogus Probe Response (Pre-RSNA only) Bogus Association Request (Pre-RSNA only) Pre-RSNA Connections Supplicant RSNA enabled Pre-RSNA enabled AuthenticatorRSNA enabled Pre-RSNA enabled Beacon + AA RSN IE Probe Request Probe Response + AA RSN IE 802.11 Authentication Request 802.11 Authentication Response Association Request + SPA RSN IE 802.11 Association Response

  32. Security Rollback: solutions • Security Level Rollback Attack • Similar to general version-rollback attack • Destroy the security since WEP is completely insecure • Not a real vulnerability of 802.11i standard, but an implementation problem of TSN • Very possible mistake if requires transparency in hybrid configurations • Solutions • Allow only RSNA connections: secure, but too strict for common network systems, where TSN is more convenient • Adopt both, supplicant manually choose to deny or accept a connection, authenticator restrict pre-RSNA (WEP) connections to only insensitive data

  33. Michael Countermeasure MAC IV/KeyID Ext. IV Data/MSDU MIC ICV FCS Contains TSC Encrypted TKIP MPDUFormat • TKIP Michael algorithm and countermeasures • Michael algorithm provides 20-bit security for MIC • one successful forgery / 2 min., need countermeasures • 802.11i documentation proposes: • Cease communication for 60 sec. if two Michael MIC failures detected in one minute, re-key & deauthentication • Limit to one successful forgery / 6 month • Verify in strict order: FCS < ICV < TSC < MIC • Update TSC unless MIC is validated MIC: Message Integrity Code ICV: Integrity Check Value (from WEP) FCS: Frame Check Sequence TSC: TKIP Sequence Counter

  34. Michael DoS and Solutions • Still DoS attack through MIC failures ! • Intercept a packet with valid TSC (possible) • Modify packet and corresponding values of FCS, ICV to get a packet with valid FCS, ICV, TSC but invalid MIC (easy) • Send modified packet twice in one minute (easy) • MIC always invalid, TSC always valid • Solutions • When MIC failure, cease communication only, no re-keying and deauthentication • Update TSC before MIC is validated • What happens if modify TSC to extremely large number? • Change TSC also change encryption key, wrong decryption • Some confidence on TKIP key schedule algorithm • Mitigation but not elimination

  35. Management Frame att. & Sol. • DoS attacks on plain 802.11 networks • Forge unprotected management frames, like Deauthentication/Disassociation [Bellardo et al 03] • Exploit virtual carrier sense mechanism by forging unprotected control frames, like RTS/CTS etc. [Bellardo 03] • 802.11i still has these problems, solutions could be • Authenticate management frames • Validate virtual carrier sense in control frames • DoS attacks on EAP messages • Forge EAPOL-Start, EAPOL-Success, EAPOL-Logoff, EAPOL-Failure • 802.11i can eliminate these by simply ignoring them ! • Send more than 255 association request to exhaust the EAP identifier space (8 bits) • Adopt separate EAP identifier counter for each association [Arbaugh et al 01] [Lynn02] [Moore02] [Bellardo et al 03] [Chen04] …

  36. Failure Recovery • Important for large protocols like 802.11i • Not affect protocol correctness, but efficiency • Not eliminate DoS vulnerabilities, but make DoS more difficult • 802.11i adopts a simple scheme • Whenever failure, restart from the beginning, inefficient ! • What about restart from nearest point ? • Tradeoffs • Defensive DoS attack vs Captured DoS attack • Assumptions on adversary’s capability and network scenario • A better failure recovery for 802.11i • If failure before 802.1X finishes, restart everything • Otherwise restart components from nearest point • Confidence on 802.1X authentication, mobile user? • channel scanning time >> protocol execution time

  37. Summarize Insecurities • Components insecurities • The 4-Way Handshake: blocking and reflection • TKIP Michael Countermeasure attacks • Combine 802.11i as a whole • RSN IE Poisoning Attack: waste resources • Security Level Rollback Attack: for hybrid configuration • Attacks on unprotected management frames • Inefficient failure recovery • Improved variant of 802.11i • Mitigate all discussed vulnerabilitites • Need more modifications on existing codes

  38. Improved 802.11i Architecture Stage 1: Network and Security Capability Discovery Stage 2: 802.1X Authentication (mutual authentication, shared secret, cipher suite) 802.1X Failure Stage 3: Secure Association (management frames protected) Association Failure Stage 4: 4-Way Handshake (PMK confirmation, PTK derivation, and GTK distribution) 4-Way Handshake Timout Stage 5: Group Key Handshake Group Key Handshake Timout Stage 6: Secure Data Communications Michael MIC Failure or Other Security Failures

  39. Outline • WLAN Security Overview • IEEE 802.11i Standard • Finite-state Verification of 4-Way Handshake • More Insecurities and Improvements • Modular Proof of Security • Methodology • Protocol compositional logic • Proved theorems • Conclusions

  40. Motivations & Difficulties • Proof of security is necessary and useful • “Head-scratching” approach is inconvincible • Finite-state verification is incomplete • Prove security vs find bugs • Difficulties • How to model the protocol? • How to define security? • How to prove? • There are already some formal methods to do these! • [BAN90], [Paulson97], [Strand98], [Spi98], … … • IEEE 802.11i • a large protocol, complicated control flows • Compositional Logic, originated from [DMP01]

  41. Methodology • Divide-and-conquer paradigm in security • Divide the large protocol to several components • Use protocol logic to reason the security properties of each subprotocol • Study the compositionality of all components • 802.11i components • 802.11 Association: a physical connection assumed • EAP/802.1X/RADIUS Authentication • 4-Way Handshake • Group Key Handshake • Secure Data Communications: CCMP believed secure

  42. Protocol Logic: Intuition • Alice’s information • Protocol • Private data • Sends and receives Honest Principals, Attacker Protocol Private Data

  43. Formalizing the Approach • Abstraction based on Dolev-Yao Model [1983] • “Black-box” cryptography • No partial knowledge, no statistical tests • Language for protocol description • Arrows-and-messages are informal • “Cord” program for each protocol role: terms & actions • Protocol Semantics • How does the protocol execute? • Protocol, initial configuration, run • Protocol logic • Stating security properties • Proof system • Formally proving security properties

  44. Cords: 4-Way Handshake Authenticator = (X, Y, PMKXY)[ new x; send X, Y, x, m1; receive Y, X, z; match z/y,m2,Hash(PTKXY,y,m2); send X,Y,x,m3,Hash(PTKXY,x,m3); receive Y, X, z; match z/m4, Hash(PTKXY, m4) ]X Supplicant = (Y, PMKXY)[ receive X, Y, z; match z/x, m1; new y; send Y, X, y, m2,Hash(PTKXY,y,m2); receive X, Y, z; match z/x,m3,Hash(PTKXY,x,m3); send Y, X, m4, Hash(PTKXY, m4) ]Y

  45. Authenticator: 4-Way Handshake Pre-condition Has(X, PMKXY)  Has(Y, PMKXY)  (Has(Z, PMKXY)  (Z = X  Z = Y)) Secret Key Agreement Honest(X)  Honest(Y)  Has(X, PTKXY)  Has(Y, PTKXY)  (Has(Z, PMKXY)  (Z = X  Z = Y)) Session Authentication Y. Honest(X)  Honest(Y)  Send(X, X, Y, x, m1)  Receive(Y, X, Y, x, m1)  Send(Y, Y, X, y, m2, Hash(PTKXY,y,m2))  Receive(X, Y, X, y, m2, Hash(PTKXY,y,m2))  Send(X, X, Y, x, m3, Hash(PTKXY,x,m3))  Receive(Y, X, Y, x, m3, Hash(PTKXY,x,m3))  Send(Y, Y, X, m4, Hash(PTKXY, m4))  Receive(X, Y, X, m4, Hash(PTKXY, m4))

  46. Protocol Composition • Composition • Convenient for analyzing large protocols and systems • Not only for proving things, but also for building systems • Non-destructive combination • Ensure that the combined parts do not degrade each other’s security • Assumptions about the environment: invariance assertions • Additive combination: • Accumulate security properties of combined parts, assuming they do not interfere • Properties achieved by individual protocol roles • Invariants of one component must be satisfied by any other components

  47. 802.11i Proved Properties • EAP-TLS • Mutual authentication: actions matched in order • Secret key achieved: known and only known to peers • The 4-Way Handshake • Session authentication: actions matched in order • Secret key agreement: fresh PTK derived • Group Key Handshake • Session authentication: actions matched in order • Secret group key: group key distributed • 802.11i components compose safely

  48. Answering the question • Can we build a secure WLAN? (with 802.11i) • Yes ! • Limitations • “Security” means “mutual authentication” and “secret key” • If CCMP secure, also have data confidentiality and integrity • Assume perfect “black-box” cryptography • Assume legitimate entities are honest • Only from perspective of the protocol • No consideration on implementations • Software bug, buffer overflow … • No consideration on the whole system • IPsec or firewall implemented? • SSL application?

  49. Conclusions • Finite-state verification of 802.11i components • Very useful methodology to find bugs • Vulnerabilities found in the 4-Way Handshake • Attacks and solutions on 802.11i • On the 4-Way Handshake: blocking and reflection • On RSN IE: poisoning and rollback • On the TKIP Michael Algorithm • Failure recovery • Improved 802.11i • It is really secure • Prove “mutual authentication” and “secret key” properties • We CAN build a secure WLAN !

  50. Questions? [http://www.pacwireless.com]

More Related