802.11i Security Analysis: Can we build a secure WLAN?

1
802.11i Security Analysis Can we build a secure
WLAN?

• Changhua He
• Stanford University
• March 24th, 2005
• Changhua_at_stanford.edu

2
Outline

• WLAN Security Overview
• Wireless Local Area Networks
• Wireless threats
• Wireless security history
• IEEE 802.11i Standard
• Finite-state Verification of 4-Way Handshake
• More Insecurities and Improvements
• Modular Proof of Security
• Conclusions

3
802.11 Infrastructure Network
Wired Network
Can we build a secure WLAN ?
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, exploit MAC cooperation to interfere
  in a timely way
• 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 Attack

5
History of Wireless Security

• 802.11 (Wired Equivalent Protocol)
• Authentication Open system (SSID) and Shared Key
• Authorization some vendor use MAC address
  filtering
• Confidentiality/Integrity RC4 CRC
• Completely insecure Walker00,Arbaugh01,Wagner01,F
  MS01
• WPA Wi-Fi Protected Access
• Authentication 802.1X
• Confidentiality/Integrity TKIP
• Reuse the legacy hardware, still problematic
  Arbaugh02
• Availability is a big problem
• Frequency jamming inevitable but expensive and
  detectable
• Network and upper Layer depend on protocols
• Link Layer DoS attack unprotected management
  frames

Arbaugh et al 01 Bellardo et al 03 Chen04
6
Outline

• WLAN Security Overview
• IEEE 802.11i Standard
• Data confidentiality and integrity
• Mutual authentication
• Key management protocols
• Finite-state Verification of 4-Way Handshake
• More Insecurities and Improvements
• Modular Proof of Security
• Conclusions

7
IEEE 802.11i

• Ratified on June 24, 2004
• Data confidentiality and integrity
• Encryption in Data Link Layer
• WEP Wired Equivalent Privacy
• TKIP Temporal Key Integrity Protocol
• CCMP Counter-mode/CBC-MAC Protocol
• Long term solution, need hardware upgrade
• With a fresh key, 802.11i CCMP is believed secure
  for data confidentiality and integrity !
• Mutual authentication
• RSNA Robust Security Network Association
• EAP-TLS/802.1X/RADIUS
• Key management
• 4-Way handshake, Group key handshake

8
RSNA Establishment

• 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
• Our 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
• Availability is still problematic

9
A Complete Conversation
10
Outline

• WLAN Security Overview
• IEEE 802.11i Standard
• Finite-state Verification of 4-Way Handshake
• Murf Model Checker
• Modeling the 4-way handshake
• Attacks and solutions
• More Insecurities and Improvements
• Modular Proof of Security
• Conclusions

11
Finite-State Verification

• Powerful methodology
• Used in protocol and software verifications
• No requirements on implementations
• Comparing to static analysis and dynamic tracing
• Challenges
• Requires complete understanding of what you check
• State space reduction techniques
• Many tools available
• Generic model checking
• Murf, Spin, SMV
• Automatic model generation model checking
• Pathfinder, Bandera, Verisoft

12
Murf Model Checker

• Murf rules for protocol participants and the
  intruder define a nondeterministic state
  transition graph
• Murf will exhaustively enumerate all graph nodes
• Murf will verify whether specified security
  conditions hold in every reachable node
• If not, the path to the violating node will
  describe the attack

...
...
Correctness condition violated
13
Running Murf
Informal Protocol Description
Intruder Model
Formal Protocol
Murj code
Murj code, similar for all protocols
RFC, IEEE Std.
Analysis Tool
Find error
Specify security conditions and run Murj
14
Diagnosing Errors

• Bad abstraction
• Removed too much detail from the protocol when
  constructing the abstract model
• Add the piece that fixes the bug and repeat
• Genuine attack
• Yay! Hooray!
• Attacks found by formal analysis are usually
  quite strong
• Independent of specific cryptographic schemes
• Independent of implementations, etc.
• Test an implementation of the protocol, if
  available

15
The 4-Way Handshake
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
16
Modeling the 4-Way Handshake

• Authenticators/Supplicants
• An association is maintained between a pair of
  authenticator and supplicant
• Each association has a uniquely shared PMK
• Multiple sequential legitimate handshakes in one
  association
• Intruder
• Impersonate both supplicant and authenticator
• Eavesdrop, intercept and replay messages
• Compose messages with known nonce and MIC
• Forge fresh Message 1
• Predict and replay nonces for pre-computation of
  MIC
• Invariants
• Represent the security property, must be true for
  each state

17
Authenticator Msg 1 (Murj)

• ruleset i AuthenticatorId do
• ruleset j AgentId do
• rule 20 "Authenticator sends Message 1 to
  associated Supplicants"
• !ismember(j, AuthenticatorId) -- no
  message to Authenticators
• !ismember(j, IntruderId) -- no message
  to Intruders
• multisetcount(lnet, true) lt NetworkSize
• (auti.associationsj.session.state
  A_PMKSA
• auti.associationsj.session.state
  A_DONE)
• gt
• var
• outM Message -- outgoing message
• begin
• outM.source i
• outM.dest j
• outM.mtype M_1
• outM.nonce freshNonce()
• outM.sequence
  freshSequence()
• outM.address i
• multisetadd(outM, net)

18
Invariant Security Properties

• invariant "PTKs are consistent and fresh"
• forall i AuthenticatorId do
• forall j SupplicantId do
• auti.associationsj.session.state
  A_DONE
• -gt
• (supj.associationsi.session.state
  S_DONE
• ptkEqual(auti.associationsj.session.pt
  k,
• supj.associationsi.session.pt
  k)
• auti.associationsj.sid
  supj.associationsi.sid)
• (supj.associationsi.session.state
  S_PTKSA
• auti.associationsj.sid lt
  supj.associationsi.sid)
• end
• end

19
Forged Message 1 Attack
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 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
21
4-Way Blocking Solution 1

• Random-Drop Queue
• Randomly drop a stored entry to adopt the state
  for the incoming Message 1 if the queue is filled.

Not so effective
22
4-Way Blocking Solution 2

• Authenticate Message 1
• To reuse the algorithms/hardware, set nonces to
  special values, e.g., 0, and derive PTK.
• Calculate MIC for Msg 1 using the derived PTK
• Good solution if PMK is fresh
• If PSK and cached PMK, replay attacks !
• Add a monotonically increasing global sequence
  counter
• Use local time in authenticator side
• Sufficient space in Message 1 ( 8-octet sequence
  field )
• No worry about time synchronization

Modifications on packet format
23
4-Way Blocking Solution 3

• Re-Use Nonce
• Supplicant re-use SNonce until one 4-way
  handshake completes successfully
• Derive correct PTK from Message 3
• Authenticator may (or may not) re-use ANonce
• Solve the problem, but
• More computations in the supplicant
• Attacker might gather more infomation about PMK
  by playing with Message 1, ok if PMK is strong
• PTKPRFPMK, AASPAANonceSNonce

Performance Degradation
24
4-Way Blocking Solution 4

• Combined solution
• Supplicant re-use SNonce
• Store one entry of ANonce and PTK for the first
  Message 1
• If nonce in Message 3 matches the entry, use PTK
  directly otherwise derive PTK again and use it.
• Advantages
• Eliminate the memory DoS attack
• Ensure performance in friendly scenarios
• Only minor modifications on the algorithm in the
  Supplicant
• No modifications on the packet format
• Adopted by TGi
• Simple solution, but not immediate
• Practical considerations, not designing a new
  protocol

25
Reflection Attack
Adversary Impersonates Communicating Peers
Legitimate Devices Authenticator and Supplicant
26
Reflection Attack Solutions

• Possible in ad hoc networks
• Each participant plays the role of both
  authenticator and supplicant
• Less damage if strong confidentiality adopted
• Adversary fool the peers to send packets
• Cannot decrypt the packet and generate response
• Violate the mutual authentication concept
• 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

27
4-Way Handshake Summary

• Finite-state verification
• Find subtle bugs, suitable for verifying small
  protocols
• State-space explosion is a problem
• Message 1 vulnerability
• Forge first message to block the protocol
• TPTK/PTK to prevent this, but only do partial
  work
• Store all states, but queue size is a problem
• Final solution adopted by Standards Committee
• Reflection attack
• Possible in ad hoc scenario
• Each entity plays only one role, or both roles
  under different PMK

28
Outline

• WLAN Security Overview
• IEEE 802.11i Standard
• Finite-state Verification of 4-Way Handshake
• More Insecurities and Improvements
• Poisoning and rollback attacks
• TKIP Michael Countermeasure problem
• Failure recovery
• Modular Proof of Security
• Conclusions

29
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
30
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 fails
  at the beginning of associations and retry new APs

31
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
32
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 if requires transparency in
  hybrid configurations
• 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

33
Michael Countermeasure

• TKIP Michael algorithm and countermeasures
• Michael algorithm provides 20-bit security for
  MIC
• one successful forgery / 2 min., need
  countermeasures
• 802.11i documentation proposes
• Cease communication for 60 sec. if two Michael
  MIC failures detected in one minute, re-key
  deauthentication
• Limit to one successful forgery / 6 month
• Verify in strict order FCS lt ICV lt TSC lt MIC
• Update TSC unless MIC is validated

MIC Message Integrity Code ICV Integrity Check
Value (from WEP) FCS Frame Check Sequence TSC
TKIP Sequence Counter
34
Michael DoS and Solutions

• Still DoS attack through MIC failures !
• Intercept a packet with valid TSC (possible)
• Modify packet and corresponding values of FCS,
  ICV to get a packet with valid FCS, ICV, TSC but
  invalid MIC (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

35
Management Frame att. Sol.

• DoS attacks on plain 802.11 networks
• Forge unprotected management frames, like
  Deauthentication/Disassociation Bellardo et al
  03
• Exploit virtual carrier sense mechanism by
  forging unprotected control frames, like RTS/CTS
  etc. Bellardo 03
• 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

Arbaugh et al 01 Lynn02 Moore02 Bellardo
et al 03 Chen04
36
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 !
• What about restart from nearest point ?
• 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
• Confidence on 802.1X authentication, mobile user?
• channel scanning time gtgt protocol execution time

37
Summarize Insecurities

• Components insecurities
• The 4-Way Handshake blocking and reflection
• TKIP Michael Countermeasure attacks
• Combine 802.11i as a whole
• RSN IE Poisoning Attack waste resources
• Security Level Rollback Attack for hybrid
  configuration
• Attacks on unprotected management frames
• Inefficient failure recovery
• Improved variant of 802.11i
• Mitigate all discussed vulnerabilitites
• Need more modifications on existing codes

38
Improved 802.11i Architecture
39
Outline

• WLAN Security Overview
• IEEE 802.11i Standard
• Finite-state Verification of 4-Way Handshake
• More Insecurities and Improvements
• Modular Proof of Security
• Methodology
• Protocol compositional logic
• Proved theorems
• Conclusions

40
Motivations Difficulties

• Proof of security is necessary and useful
• Head-scratching approach is inconvincible
• Finite-state verification is incomplete
• Prove security vs find bugs
• Difficulties
• How to model the protocol?
• How to define security?
• How to prove?
• There are already some formal methods to do
  these!
• BAN90, Paulson97, Strand98, Spi98,
• IEEE 802.11i
• a large protocol, complicated control flows
• Compositional Logic, originated from DMP01

41
Methodology

• Divide-and-conquer paradigm in security
• Divide the large protocol to several components
• Use protocol logic to reason the security
  properties of each subprotocol
• Study the compositionality of all components
• 802.11i components
• 802.11 Association a physical connection assumed
• EAP/802.1X/RADIUS Authentication
• 4-Way Handshake
• Group Key Handshake
• Secure Data Communications CCMP believed secure

42
Protocol Logic Intuition
Honest Principals, Attacker
Protocol
Private Data

• Alices information
• Protocol
• Private data
• Sends and receives

43
Formalizing the Approach

• Abstraction based on Dolev-Yao Model 1983
• Black-box cryptography
• No partial knowledge, no statistical tests
• Language for protocol description
• Arrows-and-messages are informal
• Cord program for each protocol role terms
  actions
• Protocol Semantics
• How does the protocol execute?
• Protocol, initial configuration, run
• Protocol logic
• Stating security properties
• Proof system
• Formally proving security properties

44
Cords 4-Way Handshake
Authenticator (X, Y, PMKXY) new x send X,
Y, x, m1 receive Y, X, z match
z/y,m2,Hash(PTKXY,y,m2) send X,Y,x,m3,Hash(PTKXY,
x,m3) receive Y, X, z match z/m4, Hash(PTKXY,
m4) X
Supplicant (Y, PMKXY) receive X, Y, z
match z/x, m1 new y send Y, X, y,
m2,Hash(PTKXY,y,m2) receive X, Y, z match
z/x,m3,Hash(PTKXY,x,m3) send Y, X, m4,
Hash(PTKXY, m4) Y
45
Authenticator 4-Way Handshake
Pre-condition Has(X, PMKXY) ? Has(Y, PMKXY) ?
(Has(Z, PMKXY) ? (Z X ? Z Y)) Secret Key
Agreement Honest(X) ? Honest(Y) ? Has(X, PTKXY)
? Has(Y, PTKXY) ? (Has(Z, PMKXY) ? (Z X ? Z
Y)) Session Authentication ?Y. Honest(X) ?
Honest(Y) ? Send(X, X, Y, x, m1) ? Receive(Y, X,
Y, x, m1) ? Send(Y, Y, X, y, m2,
Hash(PTKXY,y,m2)) ? Receive(X, Y, X, y, m2,
Hash(PTKXY,y,m2)) ? Send(X, X, Y, x, m3,
Hash(PTKXY,x,m3)) ? Receive(Y, X, Y, x, m3,
Hash(PTKXY,x,m3)) ? Send(Y, Y, X, m4,
Hash(PTKXY, m4)) ? Receive(X, Y, X, m4,
Hash(PTKXY, m4))
46
Protocol Composition

• Composition
• Convenient for analyzing large protocols and
  systems
• Not only for proving things, but also for
  building systems
• Non-destructive combination
• Ensure that the combined parts do not degrade
  each others security
• Assumptions about the environment invariance
  assertions
• Additive combination
• Accumulate security properties of combined parts,
  assuming they do not interfere
• Properties achieved by individual protocol roles
• Invariants of one component must be satisfied by
  any other components

47
802.11i Proved Properties

• EAP-TLS
• Mutual authentication actions matched in order
• Secret key achieved known and only known to
  peers
• The 4-Way Handshake
• Session authentication actions matched in order
• Secret key agreement fresh PTK derived
• Group Key Handshake
• Session authentication actions matched in order
• Secret group key group key distributed
• 802.11i components compose safely

48
Answering the question

• Can we build a secure WLAN? (with 802.11i)
• Yes !
• Limitations
• Security means mutual authentication and
  secret key
• If CCMP secure, also have data confidentiality
  and integrity
• Assume perfect black-box cryptography
• Assume legitimate entities are honest
• Only from perspective of the protocol
• No consideration on implementations
• Software bug, buffer overflow
• No consideration on the whole system
• IPsec or firewall implemented?
• SSL application?

49
Conclusions

• Finite-state verification of 802.11i components
• Very useful methodology to find bugs
• Vulnerabilities found in the 4-Way Handshake
• Attacks and solutions on 802.11i
• On the 4-Way Handshake blocking and reflection
• On RSN IE poisoning and rollback
• On the TKIP Michael Algorithm
• Failure recovery
• Improved 802.11i
• It is really secure
• Prove mutual authentication and secret key
  properties
• We CAN build a secure WLAN !

50
Questions?
http//www.pacwireless.com
51
Temporal Key Integrity Protocol

• Re-use legacy hardware RC4 for encryption
• Michael algorithm for MIC

52
Dolev-Yao Model

• Inspired by their 1983 paper
• D. Dolev and A. Yao. On the security of public
  key protocols. IEEE Transactions on Information
  Theory, 29(2)198-208.
• Adversary is a nondeterministic process
• Can read any message, decompose it into parts and
  re-assemble
• Cannot gain partial knowledge, perform
  statistical tests,
• Black-box cryptography
• Adversary can decrypt if and only if he knows the
  correct key
• Assumes that cryptographic functions have no
  special properties
• Most mechanized formal methods for security
  analysis use some version of this model

53
Typical Dolev-Yao Term Algebra

• Attackers term algebra is a set of derivation
  rules

T?u T?v T?u,v
T?u T?v T?cryptuv
v?T T?u
if uv? for some ?
T?u,v T?v
T?u,v T?u
T?cryptuv T?u T?v
In the real world, there is no guarantee that
attacker is restricted to these operations! He
may perform probabilistic operations, learn
partial information, etc.
54
Cords 4-Way Handshake
55
Security properties
56
Sample Proof