Security analysis and improvements for ieee 802 11i
Download
1 / 24

Security Analysis and Improvements for IEEE 802.11i - PowerPoint PPT Presentation


  • 127 Views
  • Uploaded on

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

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

PowerPoint Slideshow about 'Security Analysis and Improvements for IEEE 802.11i' - naomi


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



ad