802.11i security analysis: can we build a secure wlan? changhua he stanford university march 24 th,...
Post on 21-Dec-2015
226 views
TRANSCRIPT
802.11i Security Analysis: Can we build a secure WLAN?
Changhua HeStanford University
March 24th, 2005
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
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
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,FMS01 …]
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] …
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
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
A Complete Conversation
Data Communication
SupplicantAuth/Assoc802.1X UnBlockedPTK/GTK
Authenticator Auth/Assoc802.1X UnBlockedPTK/GTK
Authentica-tion Server (RADIUS)No Key
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
......
Correctnesscondition 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
Murφ Model Checker
Running Murφ
Intruder Model
AnalysisTool
Formal Protocol
Informal Protocol
Description
Find error
Mur codeRFC, IEEE Std.
Mur code, similar for
all protocols
Specify security conditions and run
Mur
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
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
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
Authenticator Msg 1 (Mur)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
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, sn, msg1
AA, ANonce, sn, msg1
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
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 strongPTK=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
{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
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 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
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
(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
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
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
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
TKIP MPDU Format
Ext. IV Data/MSDU MIC ICV FCS
EncryptedContains TSCMIC: Message Integrity CodeICV: Integrity Check Value (from WEP)FCS: Frame Check SequenceTSC: 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 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
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
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
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]
Motivations & Difficulties
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
Methodology
Protocol Logic: Intuition
Alice’s information Protocol Private data Sends and receives
Honest Principals,Attacker
Protocol
Private Data
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
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-conditionHas(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
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
other’s 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
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
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?
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 !
Temporal Key Integrity Protocol
Re-use legacy hardware: RC4 for encryption Michael algorithm for MIC
“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
Typical Dolev-Yao Term Algebra
Attacker’s term algebra is a set of derivation rules
Tu Tv T[u,v]
Tu Tv
Tcryptu[v] vT Tu
T[u,v]
Tu
T[u,v]
Tv
Tcryptu[v] Tu
Tv
if u=v for some
In the real world, there is no guarantee that attacker is restricted to these operations! He may perform probabilistic operations, learn partial information, etc.