1 security analysis and improvements for ieee 802.11i changhua he, john c mitchell stanford...
TRANSCRIPT
1
Security Analysis and Improvements for IEEE
802.11i
Changhua He, John C MitchellStanford 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
With a fresh key, 802.11i 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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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.