Security Analysis and Improvements for IEEE 802.11i Changhua He, John C Mitchell Stanford University NDSS’05, Feb. 03, 2005.

Security Analysis and Improvements for IEEE

802.11i

Changhua He, John C MitchellStanford University

NDSS’05, Feb. 03, 2005

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

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

IEEE 802.11i Ratified on June 24, 2004 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

802.11i: Confidentiality & Integrity

With a fresh key, 802.11i CCMP is believed secure for confidentiality and integrity !

WEP, TKIP for backward compatibility 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

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

Authentica-tion Server (RADIUS)No Key

Authenticator UnAuth/UnAssoc802.1X BlockedNo Key

SupplicantUnAuth/UnAssoc802.1X BlockedNo Key

SupplicantAuth/Assoc802.1X BlockedNo Key

Authenticator Auth/Assoc802.1X BlockedNo Key

Authentica-tion Server (RADIUS)No Key

802.11 Association

EAP/802.1X/RADIUS Authentication

SupplicantAuth/Assoc802.1X BlockedMSK

Authenticator Auth/Assoc802.1X BlockedNo Key

Authentica-tion Server (RADIUS)MSK

MSK

SupplicantAuth/Assoc802.1X BlockedPMK

Authenticator Auth/Assoc802.1X BlockedPMK

Authentica-tion Server (RADIUS)No Key

4-Way Handshake

SupplicantAuth/Assoc802.1X UnBlockedPTK/GTK

Authenticator Auth/Assoc802.1X UnBlockedPTK/GTK

Authentica-tion Server (RADIUS)No Key

Group Key Handshake

SupplicantAuth/Assoc802.1X UnBlockedNew GTK

Authenticator Auth/Assoc802.1X UnBlockedNew GTK

Authentica-tion Server (RADIUS)No Key

RSNA Conversations

Data Communication

SupplicantAuth/Assoc802.1X UnBlockedPTK/GTK

Authenticator Auth/Assoc802.1X UnBlockedPTK/GTK

Authentica-tion Server (RADIUS)No Key

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

Security Level Rollback Attack

Probe Request

Bogus Beacon (Pre-RSNA only)

Bogus Probe Response (Pre-RSNA only)

802.11 Authentication Request802.11 Authentication Response

Bogus Association Request (Pre-RSNA only)

802.11 Association ResponsePre-RSNA Connections

Beacon + AA RSN IE

Probe Response + AA RSN IE

Association Request + SPA RSN IE

SupplicantRSNA enabledPre-RSNA enabled

Authenticator RSNA enabledPre-RSNA enabled

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

Reflection Attack

{A2, Nonce2, RSN IE, sn, msg2, MIC}{A1, Nonce1, RSN IE, GTK, sn+1, msg3, MIC}

{A1, sn+1, msg4, MIC}

Bogus Authentication Peers 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}

AdversaryImpersonates CommunicatingPeers

Legitimate Devices Authenticator and Supplicant

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

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

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

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

MAC IV/KeyID

TKIP MPDU Format

Ext. IV Data/MSDU MIC ICV FCS

EncryptedContains TSC

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

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 IEBogus Beacon + Modified RSN IE

Bogus Probe Response + Modified RSN IE

Legitimate Message Exchanges

SupplicantUnauthenticatedUnassociated802.1X Blocked

Authenticator UnauthenticatedUnassociated802.1X Blocked

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

4-Way Handshake Blocking

AA, ANonce, AA RSN IE, GTK, sn+1, msg3, MIC SPA, sn+1, msg4, MIC

PTK Derived

PTK DerivedRandom GTK

PTK and GTK802.1X Unblocked

PTK and GTK 802.1X Unblocked

SupplicantAuth/Assoc802.1X BlockedPMK

Authenticator Auth/Assoc802.1X BlockedPMK

AA, ANonce, sn, msg1

SPA, SNonce, SPA RSN IE, sn, msg2, MIC

AA, ANonce[1], sn, msg1

AA, ANonce[n], sn, msg1

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

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

Improved 802.11i ArchitectureStage 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

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

Highlight Our Findings

ATTACKS SOLUTIONSsecurity rollback supplicant manually choose security;

authenticator restrict pre-RSNA to only insensitive data.

reflection attack each 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 poisoning Authenticate 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.