Presentation is loading. Please wait.

Presentation is loading. Please wait.

1 Security Analysis and Improvements for IEEE 802.11i Changhua He, John C Mitchell Stanford University.

Similar presentations


Presentation on theme: "1 Security Analysis and Improvements for IEEE 802.11i Changhua He, John C Mitchell Stanford University."— Presentation transcript:

1 1 Security Analysis and Improvements for IEEE i Changhua He, John C Mitchell Stanford University

2 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 3 Outline  Wireless Threat Models  Possible threats and their practicality in wireless networks  IEEE i  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 i  Conclusions

4 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 5 IEEE a/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 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 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 i

8 8 IEEE i  Ratified on June 24,  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 9 RSNA Establishment Procedures

10 i: Confidentiality & Integrity  With a fresh key, i CCMP is believed secure for confidentiality and 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

11 i: Mutual Authentication  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  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 12 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 RSNA Conversations Data Communication Supplicant Auth/Assoc 802.1X UnBlocked PTK/GTK Authenticator Auth/Assoc 802.1X UnBlocked PTK/GTK Authentica- tion Server (RADIUS) No Key

13 13 Outline  Wireless Threat Models  IEEE i  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 i  Conclusions

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

15 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 i 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 16 Reflection Attack {A2, Nonce2, RSN IE, sn, msg2, MIC} {A1, Nonce1, RSN IE, GTK, sn+1, msg3, MIC} {A1, sn+1, msg4, MIC} Bogus AuthenticationPeers Authenticated {A1, Nonce1, sn, msg1} {A2, Nonce1, sn, msg1} {A1, Nonce2, RSN IE, sn, msg2, MIC} {A2, Nonce1, RSN IE, GTK, sn+1, msg3, MIC} {SPA, sn+1, msg4, MIC} Adversary Impersonates Communicating Peers Legitimate Devices Authenticator and Supplicant

17 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 i: 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 networks  DoS attack on Michael countermeasure in TKIP  RSN IE Poisoning/Spoofing  4-Way Handshake Blocking

19 19 Known DoS attacks and Solutions  DoS attacks on plain networks  Forge unprotected management frames, like Deauthentication/Disassociation frame  Exploit virtual carrier sense mechanism by forging unprotected control frames, like RTS/CTS etc.  i 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  i 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 20 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 MACIV/KeyID TKIP MPDU Format Ext. IVData/MSDUMICICVFCS Encrypted Contains TSC

21 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 22 RSN IE Poisoning (2) Probe Request (3) Probe Response + AA RSN IE (18) {AA, ANonce, AA RSN IE, GTK, sn+1, msg3, MIC} RSN IE confirmation failed, Disassociation Disassociate the Supplicant (1) Beacon + AA RSN IE Bogus Beacon + Modified RSN IE Bogus Probe Response + Modified RSN IE Legitimate Message Exchanges Supplicant Unauthenticated Unassociated 802.1X Blocked Authenticator Unauthenticated Unassociated 802.1X Blocked

23 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 24 4-Way Handshake Blocking 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[1], sn, msg1 AA, ANonce[n], sn, msg1

25 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 26 Failure Recovery  Important for large protocols like i  Not affect protocol correctness, but efficiency  Not eliminate DoS vulnerabilities, but make DoS more difficult  i 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 i  If failure before 802.1X finishes, restart everything  Otherwise restart components from nearest point  channel scanning time >> protocol execution time

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

28 28 Conclusions  i 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 i 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 i

29 29 Highlight Our Findings ATTACKSSOLUTIONS security rollbacksupplicant manually choose security; authenticator restrict pre-RSNA to only insensitive data. reflection attackeach participant plays the role of either authenti- cator or supplicant; if both, use different PMKs. attack on Michael countermeasures cease connections for a specific time instead of re-key and deauthentication; update TSC before MIC and after FCS, ICV are validated. RSN IE poisoningAuthenticate Beacon and Probe Response frame; Confirm RSN IE in an earlier stage; Relax the condition of RSN IE confirmation. 4-way handshake blocking adopt random-drop queue, not so effective; authenticate Message 1, packet format modified; re-use supplicant nonce, eliminate memory DoS.


Download ppt "1 Security Analysis and Improvements for IEEE 802.11i Changhua He, John C Mitchell Stanford University."

Similar presentations


Ads by Google