1 / 29

Security Analysis and Improvements for IEEE 802.11i

Security Analysis and Improvements for IEEE 802.11i. Changhua He, John C Mitchell Stanford University. Acronym List. CCMP: Counter-mode/CBC-MAC Protocol RSNA: Robust Security Network Association RSN IE: RSN Information Element PTK: Pairwise Transient Key GTK: Group Transient Key

fadhila
Download Presentation

Security Analysis and Improvements for IEEE 802.11i

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. Security Analysis and Improvements for IEEE 802.11i Changhua He, John C Mitchell Stanford University

  2. Acronym List • CCMP: Counter-mode/CBC-MAC Protocol • RSNA: Robust Security Network Association • RSN IE: RSN Information Element • PTK: Pairwise Transient Key • GTK: Group Transient Key • TKIP: Temporal Key Integrity Protocol • EAP: Extensible Authentication Protocol • PSK: Pre-Shared Key • MIC: Message Integrity Code

  3. Outline • Wireless Threat Models • Possible threats and their practicality in wireless networks • IEEE 802.11i • Data Confidentiality & Integrity: CCMP • Mutual Authentication: RSNA Establishment Procedure • Availability: not an original design objective, problematic • Attacks and Solutions • On Authentication: Security level rollback, reflection attack • On Availability: Michael countermeasure attack, RSN IE poisoning, 4-Way Handshake blocking • Failure Recovery and improved 802.11i • Conclusions

  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 • 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: cost related evaluation

  5. IEEE 802.11a/b/g • WEP • Key (IV (24) + shared key (40 or 104)) • Encryption algorithm: RC4 • Data integrity: ICV (Integrity Check Value), which is linear and un-keyed function of the message. • Open system (no authentication) • Shared key authentication (challenge response handshake) • Weakness in WEP • Key scheduling problem due to the short IV. • Weak one direction authentication. • No protection mechanism (such as timestamp, nonce) against replay attack.

  6. WPA: a interim solution • WPA (Wi-Fi protected Access) • Data integrity: • TKIP (Temporal Key Integrity Protocol) using key mixing function and IV space extension. • A weak keyed MIC (Message Integrity Code) is introduced to improve the ICV. • Monotonically increasing sequence number to prevent replay attacks. • Two more authentication schemes • PSK (Pre-Shared Key) to authenticate peers. Besides, based on PSK, 128 bit encryption key and 64 bit MIC key can be generated. • IEEE 802.1X+EAP (Extensible Authentication Protocol) is stronger.

  7. Is WPA good enough? • It seems that WPA patches every vulnerabilities in WEP. • Weakness is predestined since WPA wants to re-use the legacy hardware: • TKIP’s key mixing function is not strong as expected. • Whole security is broken for the duration of a Temporal Key if two per-packet keys with the same IV32. • It is possible to find the MIC key given one per-packet key. • 802.1x still vulnerable to session hijacking and man-in-the-middle attack. • Long term solution: IEEE 802.11i

  8. IEEE 802.11i • Ratified on June 24, 2004. • Proposed to provide enhanced MAC layer security. • Data confidentiality and integrity • Encryption in Link Layer • WEP: Wired Equivalent Privacy • TKIP: Temporal Key Integrity Protocol • CCMP: Counter-mode/CBC-MAC Protocol • Mutual authentication • RSNA: Robust Security Network Association • EAP-TLS/802.1X/RADIUS • Key management: 4-Way handshake, Group key handshake, etc. • Availability • not an original design objective • Some real vulnerabilities exist

  9. RSNA Establishment Procedures

  10. 802.11i: Confidentiality & Integrity • WEP, TKIP for backward compatibility (802.11a/b/g) • CCMP: long-term solution • AES: 128-bit key, 128-bit block, Counter mode + CBC-MAC • 48-bit Packet Number for replay prevention • Use the same key for both Encryption and MIC • Counter and init. vector not overlap • better to use different key for different purpose • With a fresh key, 802.11i CCMP is believed secure for confidentiality and integrity !

  11. 802.11i: Mutual Authentication • 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 • RSNA 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

  12. 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 PTK/GTK AuthenticatorAuth/Assoc 802.1X Blocked No Key AuthenticatorAuth/Assoc 802.1X UnBlocked New 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) MSK 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) No Key 802.11 Association EAP/802.1X/RADIUS Authentication MSK 4-Way Handshake Group Key Handshake Data Communication RSNA Conversations

  13. Outline • Wireless Threat Models • IEEE 802.11i • Attacks and Solutions • On Authentication: • 1. Security level rollback • 2. reflection attack • On Availability: • 3. Michael countermeasure attack • 4. RSN IE poisoning • 5. 4-Way Handshake blocking • Failure Recovery and improved 802.11i • Conclusions

  14. Bogus Beacon (Pre-RSNA only) Bogus Probe Response (Pre-RSNA only) Bogus Association Request (Pre-RSNA only) Pre-RSNA Connections Security Level Rollback Attack 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

  15. 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 for transparency requirement • 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

  16. {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 Reflection Attack Adversary Impersonates Communicating Peers Legitimate Devices Authenticator and Supplicant

  17. Reflection Attack: Solutions • Possible in ad hoc networks • Each participant plays the role of both authenticator and supplicant • Violate the mutual authentication concept • Less damage if strong confidentiality adopted • Adversary fool the peers to send packets • Cannot decrypt the packet and generate response • 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

  18. 802.11i: Availability • Not an original design objective • Physical Layer DoS attack • Inevitable but expensive and detectable • Network and upper Layer DoS attack • Depend on protocols, not our focus • Link Layer DoS attack • Flooding attack: could be detected and located • Some Known DoS attacks on 802.11 networks • DoS attack on Michael countermeasure in TKIP • RSN IE Poisoning/Spoofing • 4-Way Handshake Blocking

  19. Known DoS attacks and Solutions • DoS attacks on plain 802.11 networks • Forge unprotected management frames, like Deauthentication/Disassociation frame • Exploit virtual carrier sense mechanism by forging unprotected control frames, like RTS/CTS etc. • 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

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

  21. Michael DoS and Solutions • DoS attack through MIC failures • Intercept a packet with valid TSC (possible) • Modify packet and corresponding values of FCS, ICV (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

  22. Bogus Beacon + Modified RSN IE Bogus Probe Response + Modified RSN IE Disassociate the Supplicant RSN IE confirmation failed, Disassociation RSN IE Poisoning 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}

  23. 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 error at the beginning of associations

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

  25. 4-Way Blocking: Solutions • Random-Drop Queue: not so effective • Authenticate Message 1 • Make use of the share PMK, but need to modify packet format • Re-use supplicant nonce • Supplicant re-use SNonce, eliminate memory DoS • Performance degradation, more computations in the supplicant • Combined solution: • Supplicant re-use SNonce • Store one entry of received ANonce and derived PTK • If ANonce in Message 3 matches the entry, use PTK directly; otherwise derive PTK from Message 3 and use it • Eliminate the attack, ensure performance in “friendly” scenarios, only minor modifications on the algorithm

  26. 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 ! • 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 • channel scanning time >> protocol execution time

  27. 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 Improved 802.11i Architecture

  28. Conclusions • 802.11i provides • Satisfactory data confidentiality & integrity with CCMP • Satisfactory mutual authentication & key management • Some implementation mistakes • Security Level Rollback Attack in TSN • Reflection Attack on the 4-Way Handshake • Availability is a problem • Simple policies can make 802.11i robust to some known DoS • Possible attack on Michael Countermeasures in TKIP • RSN IE Poisoning/Spoofing • 4-Way Handshake Blocking • Inefficient failure recovery scheme • Improved 802.11i

  29. Highlight Our Findings

More Related