802.11i Security Analysis:
Can we build a secure WLAN?
Changhua He
Stanford University
March 24th, 2005
Changhua@stanford.edu
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

802.11 Infrastructure Network
Wired
Network
Can we build a secure WLAN ?
Wireless Threats

Passive Eavesdropping/Traffic Analysis


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


Easy, most wireless NICs have promiscuous mode
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

History of Wireless Security

802.11 (Wired Equivalent Protocol)





WPA: Wi-Fi Protected Access




Authentication: Open system (SSID) and Shared Key
Authorization: some vendor use MAC address filtering
Confidentiality/Integrity: RC4 + CRC
Completely insecure [Walker00,Arbaugh01,Wagner01,FMS01 …]
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] …
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

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
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
A Complete Conversation
Supplicant
UnAuth/UnAssoc
Auth/Assoc
802.1X UnBlocked
Blocked
No Key
MSK
PMK
New
PTK/GTK
GTK
Authenticator
UnAuth/UnAssoc
Auth/Assoc
802.1X UnBlocked
Blocked
No Key
PMK
New
PTK/GTK
GTK
Authentication Server
(RADIUS)
MSK
No
Key
802.11 Association
EAP/802.1X/RADIUS Authentication
MSK
4-Way Handshake
Group Key Handshake
Data Communication
Outline
WLAN Security Overview
 IEEE 802.11i Standard
 Finite-state Verification of 4-Way Handshake




Murφ Model Checker
Modeling the 4-way handshake
Attacks and solutions
More Insecurities and Improvements
 Modular Proof of Security
 Conclusions

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:
• Murφ, Spin, SMV

Automatic model generation model checking:
• Pathfinder, Bandera, Verisoft
Murφ Model Checker

...

...

Correctness
condition violated

Murφ rules for protocol
participants and the intruder
define a nondeterministic state
transition graph
Murφ will exhaustively
enumerate all graph nodes
Murφ will verify whether
specified security conditions
hold in every reachable node
If not, the path to the violating
node will describe the attack
Running Murφ
Informal
Protocol
Description
Formal
Protocol
Intruder
Model
Murj code
Murj code,
similar for
all protocols
RFC, IEEE Std.
Find error
Specify security
conditions and run Murj
Analysis
Tool
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
The 4-Way Handshake
Supplicant
Auth/Assoc
802.1X Blocked
PMK
Authenticator
Auth/Assoc
802.1X Blocked
PMK
AA, ANonce, sn, msg1
PTK Derived
SPA, SNonce, SPA RSN IE, sn, msg2, MIC
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
Modeling the 4-Way Handshake

Authenticators/Supplicants:




Intruder






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
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
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(l:net, true) < NetworkSize &
(aut[i].associations[j].session.state = A_PMKSA |
aut[i].associations[j].session.state = A_DONE)
==>
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);
aut[i].associations[j].peer
:=
j;
aut[i].associations[j].pmk
:=
usePMK(i, j);
aut[i].associations[j].sequence
:=
outM.sequence;
aut[i].associations[j].nonce
:=
outM.nonce;
aut[i].associations[j].session.state:=
A_WAITFORNS;
end;
end;
end;
Invariant: Security Properties
invariant "PTKs are consistent and fresh"
forall i: AuthenticatorId do
forall j: SupplicantId do
aut[i].associations[j].session.state = A_DONE
->
(sup[j].associations[i].session.state = S_DONE
ptkEqual(aut[i].associations[j].session.ptk,
sup[j].associations[i].session.ptk)
aut[i].associations[j].sid = sup[j].associations[i].sid)
(sup[j].associations[i].session.state = S_PTKSA
aut[i].associations[j].sid <= sup[j].associations[i].sid)
end;
end;
&
&
|
&
Forged Message 1 Attack
Supplicant
Auth/Assoc
802.1X Blocked
PMK
Authenticator
Auth/Assoc
802.1X Blocked
PMK
AA, ANonce, sn, msg1
PTK Derived
SPA, SNonce, SPA RSN IE, sn, msg2, MIC
AA, ANonce, sn, msg1
PTK Derived
Random GTK
AA, ANonce, AA RSN IE, GTK, sn+1, msg3, MIC
SPA, sn+1, msg4, MIC
AA, ANonce, sn, msg1
PTK and GTK
802.1X Unblocked
PTK and GTK
802.1X Unblocked
4-Way Handshake Blocking
Supplicant
Auth/Assoc
802.1X Blocked
PMK
Authenticator
Auth/Assoc
802.1X Blocked
PMK
AA, ANonce, sn, msg1
PTK Derived
SPA, SNonce, SPA RSN IE, sn, msg2, MIC
AA, ANonce[1], sn, msg1
AA, ANonce[n], sn, msg1
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: 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
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
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
PTK=PRF{PMK, AA||SPA||ANonce||SNonce}
Performance Degradation
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
Reflection Attack
Adversary
Impersonates
Communicating
Peers
Legitimate
Devices
Authenticator and
Supplicant
{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: 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
4-Way Handshake Summary

Finite-state verification



Message 1 vulnerability





Find subtle bugs, suitable for verifying “small” protocols
State-space explosion is a problem
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
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

RSN IE Poisoning
Supplicant
Authenticator
Unauthenticated
Unauthenticated
Unassociated
Unassociated
802.1X Blocked
802.1X Blocked
(1) Beacon + AA RSN IE
Bogus Beacon + Modified RSN IE
(2) Probe Request
(3) Probe Response + AA RSN IE
Bogus Probe Response + Modified RSN IE
Legitimate Message Exchanges
(18) {AA, ANonce, AA RSN IE, GTK, sn+1, msg3, MIC}
RSN IE confirmation
failed, Disassociation
Disassociate the
Supplicant
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
Security Level Rollback Attack
Supplicant
RSNA enabled
Pre-RSNA enabled
Authenticator
RSNA enabled
Pre-RSNA enabled
Bogus Beacon (Pre-RSNA only)
Beacon + AA RSN IE
Probe Request
Bogus Probe Response (Pre-RSNA only)
Probe Response + AA RSN IE
802.11 Authentication Request
802.11 Authentication Response
Bogus Association Request (Pre-RSNA only)
Association Request + SPA RSN IE
802.11 Association Response
Pre-RSNA Connections
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
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 < ICV < TSC < MIC
• Update TSC unless MIC is validated
MAC IV/KeyID
Ext. IV
Contains TSC
Data/MSDU
MIC
ICV
FCS
Encrypted
TKIP MPDU Format
MIC: Message Integrity Code
ICV: Integrity Check Value (from WEP)
FCS: Frame Check Sequence
TSC: TKIP Sequence Counter
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
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] …
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 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
Confidence on 802.1X authentication, mobile user?
• channel scanning time >> protocol execution time
Summarize Insecurities

Components insecurities



Combine 802.11i as a whole





The 4-Way Handshake: blocking and reflection
TKIP Michael Countermeasure attacks
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
Improved 802.11i Architecture
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
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
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]
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
Protocol Logic: Intuition
Honest Principals,
Attacker
Protocol
Private
Data

Alice’s information



Protocol
Private data
Sends and receives
Formalizing the Approach

Abstraction based on Dolev-Yao Model [1983]



Language for protocol description




How does the protocol execute?
Protocol, initial configuration, run
Protocol logic


Arrows-and-messages are informal
“Cord” program for each protocol role: terms & actions
Protocol Semantics


“Black-box” cryptography
No partial knowledge, no statistical tests
Stating security properties
Proof system

Formally proving security properties
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
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))
Protocol Composition

Composition



Non-destructive combination



Ensure that the combined parts do not degrade each
other’s security
Assumptions about the environment: invariance assertions
Additive combination:



Convenient for analyzing large protocols and systems
Not only for proving things, but also for building systems
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
802.11i Proved Properties

EAP-TLS



The 4-Way Handshake



Session authentication: actions matched in order
Secret key agreement: fresh PTK derived
Group Key Handshake



Mutual authentication: actions matched in order
Secret key achieved: known and only known to peers
Session authentication: actions matched in order
Secret group key: group key distributed
802.11i components compose safely
Answering the question

Can we build a secure WLAN? (with 802.11i)


Limitations





Yes !
“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?
Conclusions

Finite-state verification of 802.11i components



Attacks and solutions on 802.11i






Very useful methodology to find bugs
Vulnerabilities found in the 4-Way Handshake
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 !
Questions?
[http://www.pacwireless.com]
Temporal Key Integrity Protocol


Re-use legacy hardware: RC4 for encryption
Michael algorithm for MIC
“Dolev-Yao” Model

Inspired by their 1983 paper


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



D. Dolev and A. Yao. “On the security of public key protocols”. IEEE
Transactions on Information Theory, 29(2):198-208.
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
Typical Dolev-Yao Term Algebra
Attacker’s term algebra is a set of derivation rules
vT
if u=v for some 
Tu
T[u,v]
Tu
T[u,v]
Tv
Tu Tv
T[u,v]
Tu
Tv
Tcryptu[v]
Tcryptu[v] 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.
Cords: 4-Way Handshake
Security properties
Sample Proof