Security analysis and improvements for ieee 802 11i l.jpg
This presentation is the property of its rightful owner.
Sponsored Links
1 / 24

Security Analysis and Improvements for IEEE 802.11i PowerPoint PPT Presentation


  • 107 Views
  • Uploaded on
  • Presentation posted in: General

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

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.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -

Presentation Transcript


Security analysis and improvements for ieee 802 11i l.jpg

Security Analysis and Improvements for IEEE 802.11i

Changhua He, John C Mitchell

Stanford University

NDSS’05, Feb. 03, 2005


Outline l.jpg

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 l.jpg

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 l.jpg

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 l.jpg

802.11i: Confidentiality & 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

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


802 11i mutual authentication l.jpg

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


Rsna conversations l.jpg

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


Outline8 l.jpg

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 l.jpg

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


Security rollback solutions l.jpg

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 l.jpg

{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


Reflection attack solutions l.jpg

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 l.jpg

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 l.jpg

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 l.jpg

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


Michael dos and solutions l.jpg

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 l.jpg

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}


Rsn ie poisoning solutions l.jpg

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 l.jpg

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


4 way blocking solutions l.jpg

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 l.jpg

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 architecture l.jpg

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


Conclusions l.jpg

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 l.jpg

Highlight Our Findings


  • Login