Security Analysis and Improvements for IEEE 802.11i

1
Security Analysis and Improvements for IEEE
802.11i

• Changhua He, John C Mitchell
• Stanford University
• NDSS05, Feb. 03, 2005

2
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

3
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

4
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

5
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 !

6
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

7
RSNA Conversations
8
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

9
Security Level Rollback Attack
Supplicant RSNA enabled Pre-RSNA enabled
Authenticator RSNA 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
10
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

11
Reflection Attack
Adversary Impersonates Communicating Peers
Legitimate Devices Authenticator and Supplicant
12
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

13
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

14
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

15
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 lt ICV lt TSC lt MIC
• Update TSC unless MIC is validated

16
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

17
RSN IE Poisoning
Supplicant Unauthenticated Unassociated 802.1X
Blocked
Authenticator Unauthenticated 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, sn1, msg3, MIC
18
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

19
4-Way Handshake Blocking
Supplicant Auth/Assoc 802.1X Blocked PMK
Authenticator Auth/Assoc 802.1X Blocked PMK
PTK Derived
PTK Derived Random GTK
AA, ANonce, AA RSN IE, GTK, sn1,
msg3, MIC
SPA, sn1, msg4, MIC
PTK and GTK 802.1X Unblocked
PTK and GTK 802.1X Unblocked
20
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

21
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 adversarys 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 gtgt protocol execution time

22
Improved 802.11i Architecture
23
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

24
Highlight Our Findings
ATTACKS SOLUTIONS
security 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.