protocol analysis, wireless networking, and mobility
DESCRIPTION
Protocol analysis, wireless networking, and mobility. John Mitchell Stanford University. Many security Protocols. Challenge-response ISO 9798-1,2,3; Needham-Schroeder, … Authentication Kerberos Key Exchange SSL handshake, IKE, JFK, IKEv2, Wireless and mobile computing - PowerPoint PPT PresentationTRANSCRIPT
Protocol analysis, wireless networking, and
mobility
John MitchellStanford University
Many security Protocols
Challenge-response• ISO 9798-1,2,3; Needham-Schroeder, …
Authentication• Kerberos
Key Exchange• SSL handshake, IKE, JFK, IKEv2,
Wireless and mobile computing• Mobile IP, WEP, 802.11i
Electronic commerce• Contract signing, SET, electronic cash, …
Mobile IPv6 Architecture
IPv6
Mobile Node (MN)
Corresponding Node (CN)
Home Agent (HA)
Direct connection via binding update
Authentication is a requirement
Early proposals weak
802.11i Wireless Authentication
TLS protocol layer over TCP/IP
Network interface
Transport (TCP)
Physical layer
Internet (IP)
Applicationtelnet
http ftp
nntp
SSL/TLS
SSL/TLS
C
ClientHello
ServerHello, [Certificate],[ServerKeyExchange],[CertificateRequest],ServerHelloDone
S[Certificate],ClientKeyExchange,[CertificateVerify]
Finished
switch to negotiated cipher
Finished
switch to negotiated cipher
Handshake Protocol
ClientHello CS C, VerC, SuiteC, NC
ServerHello S C VerS, Suite, SuiteSS, N, NSS,, signCA{ S, KS, KSS }
ClientVerify C S signCA{ C, VC }
{ VerC, SecretC }
signC { Hash( Master(NC, NNSS, SecretC) + Pad2 + Hash(Msgs + C + Master(NC, NNSS, SecretC) + Pad1)) }
(Change to negotiated cipher)
ServerFinished S C { Hash( Master(NC, NNSS, SecretC) + Pad2 + Hash( Msgs + S + Master(NC, NNSS, SecretC) + Pad1)) }
ClientFinished C S { Hash( Master(NC, NNSS, SecretC) + Pad2 + Hash( Msgs + C + Master(NC, NNSS, SecretC) + Pad1)) }
KSS
Master(NC, NSS, SecretC)
Master(NC, NSS, SecretC)
IKE subprotocol from IPSEC
A, (ga mod p)
B, (gb mod p)
Result: A and B share secret gab mod p
A B
m1
m2 ,
signB(m1,m2)
signA(m1,m2)
Analysis involves probability, modular exponentiation, complexity, digital signatures, communication networks
Explicit Intruder Method
Intruder Model
AnalysisTool
Formal Protocol
Informal Protocol
Description
Find error
Run of protocol
A
BInitiate
Respond
C
D
Correct if no security violation in any run
Attacker
Automated Finite-State Analysis
Define finite-state system• Bound on number of steps• Finite number of participants• Nondeterministic adversary with finite options
Pose correctness condition• Can be simple: authentication and secrecy• Can be complex: contract signing
Exhaustive search using “verification” tool• Error in finite approximation Error in protocol• No error in finite approximation ???
Mur[Dill et al.]
Describe finite-state system• State variables with initial values• Transition rules• Communication by shared variables
Scalable: choose system size parameters Automatic exhaustive state enumeration
• Space limit: hash table to avoid repeating states
Research and industrial protocol verification
Applying Mur to security protocols
Formulate protocol• Assume finite participants
– Example: 2 clients, 2 servers• Assume finite message space
– Represent random numbers by r1, r2, r3, …– Do not allow unbounded encrypt(encrypt(encrypt(…)))
Add adversary• Control over “network” (shared variables)• Possible actions
– Intercept any message– Remember parts of messages– Generate new messages, using observed data and
initial knowledge (e.g. public keys)
Needham-Schroeder in Mur (1)
const
NumInitiators: 1; -- number of initiators
NumResponders: 1; -- number of responders
NumIntruders: 1; -- number of intruders
NetworkSize: 1; -- max. outstanding msgs in network
MaxKnowledge: 10; -- number msgs intruder can remember
type
InitiatorId: scalarset (NumInitiators);
ResponderId: scalarset (NumResponders);
IntruderId: scalarset (NumIntruders);
AgentId: union {InitiatorId, ResponderId, IntruderId};
Needham-Schroeder in Mur (2)
MessageType : enum { -- types of messages
M_NonceAddress, -- {Na, A}Kb nonce and addr
M_NonceNonce, -- {Na,Nb}Ka two nonces
M_Nonce -- {Nb}Kb one nonce
};
Message : record
source: AgentId; -- source of message
dest: AgentId; -- intended destination of msg
key: AgentId; -- key used for encryption
mType: MessageType; -- type of message
nonce1: AgentId; -- nonce1
nonce2: AgentId; -- nonce2 OR sender id OR empty
end;
Needham-Schroeder in Mur (3)
-- intruder i sends recorded message
ruleset i: IntruderId do -- arbitrary choice of
choose j: int[i].messages do -- recorded message
ruleset k: AgentId do -- destination
rule "intruder sends recorded message"
!ismember(k, IntruderId) & -- not to intruders
multisetcount (l:net, true) < NetworkSize
==>
var outM: Message;
begin
outM := int[i].messages[j];
outM.source := i;
outM.dest := k;
multisetadd (outM,net);
end; end; end; end;
example
number of sizeofini. res. int. network states time1 1 1 1 1706 3.1s1 1 1 2 40207 82.2s2 1 1 1 17277 43.1s2 2 1 1 514550 5761.1s
Run of Needham-Schroeder
Find error after 1.7 seconds exploration
Output: trace leading to error state Mur times after correcting error:
State Reduction on N-S Protocol
1706
17277
514550
980
6981
155709
58222
3263
1
10
100
1000
10000
100000
1000000
1 init
1 resp
2 init
1 resp
2 init
2 resp
Base: handoptimizationof model
CSFW:eliminatenet, maxknowledgeMergeintrud send,princ reply
Security Protocols in Mur
Standard “benchmark” protocols• Needham-Schroeder, TMN, …• Kerberos
Study of Secure Sockets Layer (SSL)• Versions 2.0 and 3.0 of handshake protocol• Include protocol resumption
Tool optimization Additional protocols
• Contract-signing• Wireless networking … ADD YOUR PRODUCT HERE …
CS259 Term Projects
iKP protocol family Electronic voting XML Security
IEEE 802.11i wireless handshake protocol
Onion Routing Electronic Voting
Secure Ad-Hoc Distance Vector Routing
An Anonymous Fair Exchange E-commerce Protocol
Key Infrastructure
Secure Internet Live Conferencing
Windows file-sharing protocols
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
Changhua He
Wireless Security Evolution
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
WPA: Wi-Fi Protected Access • Authentication: 802.1X• Confidentiality/Integrity: TKIP• Reuse the legacy hardware, still problematic
IEEE 802.11i (Ratified on June 24, 2004 )• Mutual authentication• Data confidentiality and integrity: CCMP• Key management• Availability
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
Data Communication
SupplicantAuth/Assoc802.1X UnBlockedPTK/GTK
Authenticator Auth/Assoc802.1X UnBlockedPTK/GTK
Authentica-tion Server (RADIUS)No Key
RSNA Conversations
Security Level Rollback Attack
Probe Request
SupplicantRSNA enabledPre-RSNA enabled
AuthenticatorRSNA enabledPre-RSNA enabled
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
Solutions Security Level Rollback Attack
• Similar to general version rollback attack• Destroy security since WEP is insecure• Not vulnerability of 802.11i standard, but an
implementation problem
Solutions• Allow only RSNA connections: secure, but too
strict for common networks, where Transient Security Network is more convenient
• Deploy both, but– Supplicant manually choose to deny or accept– Authenticator limit pre-RSNA connections to only
insensitive data
Reflection AttackAdversaryImpersonatesCommunicatingPeers
{A2, Nonce2, RSN IE, sn, msg2, MIC}{A1, Nonce1, RSN IE, GTK, sn+1, msg3, MIC}
{A1, sn+1, msg4, MIC}
Legitimate DevicesAuthenticator andSupplicant
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}
Reflection Solutions
Possible in ad hoc networks Violates mutual authentication Solutions:
• Restrict each entity to single role– Access point is not wireless station
• Allow one entity to have two roles– But require different pairwise master keys (PMK)
802.11i Availability
Not an original design objective Physical Layer DoS attacks
• Inevitable but detectable, not our focus
Network and upper Layer DoS attack• Depend on protocols, not our focus
Link Layer attack• Flooding attack: Lots of traffic and power req’d• Some Known DoS attacks in 802.11 networks• DoS attack on Michael algorithm in TKIP• RSN IE Poisoning/Spoofing• 4-Way Handshake Blocking• Failure Recovery
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, sn, msg1
AA, ANonce, sn, msg1
Countermeasures
Random-Drop Queue• Randomly drop a stored entry if the queue is full• Not so effective
Authenticate Message 1• Use the share PMK; must modify the packet format
Reuse supplicant nonce• Reuse SNonce, derive correct PTK from Message 3• Performance degradation, more computation in supplicant
Combined solution• Supplicant reuses SNonce• Store one entry of ANonce and PTK for the first Message 1• If nonce in Message 3 matches the entry, use PTK directly• Eliminate memory DoS, only minor change to algorithm• Adopted by TGi
Failure Recovery
Failure recovery is important• Can reduce but not eliminate DoS vulnerabilities
Current 802.11i method• When failure, restart everything: inefficient
A better failure approach• If 802.1X does not finish, restart everything• Otherwise restart from nearest completed
subprotocol• Channel scanning time is significantly larger than the
protocol execution time
Improved 802.11iStage 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 CommunicationsMichael MIC Failure or Other Security Failures
Group Key Handshake Timout
4-Way Handshake Timout
Association Failure
802.1X Failure
Summary of larger study 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.
802.11i correctness proof in PCL
EAP-TLS• Between Supplicant and Authentication Server• Authorizes supplicant and establishes access key
(PMK) 4-Way Handshake
• Between Access Point and Supplicant• Checks authorization, establish key (PTK) for data
transfer Group Key Protocol
• AP distributes group key (GTK) using KEK to supplicants
AES based data protection using established keys
Our proof covers subprotocols 1, 2, 3 alone and in various combinations
SSL/TLS
C
ClientHello
ServerHello, [Certificate],[ServerKeyExchange],[CertificateRequest],ServerHelloDone
S[Certificate],ClientKeyExchange,[CertificateVerify]
Finished
switch to negotiated cipher
Finished
switch to negotiated cipher
TLS Protocol: Client
The TLS Server actions also defined by a straight-line sequential process (cord)
TLS Properties
Authentication: client and the server agree on• Master secret• Protocol version and crypto suite• Each other’s identities • Protocol completion status
Secrecy• The master secret must not be known to any
other principal
Theorems: Agreement and Secrecy
Client is guaranteed:
• there exists a session of the intended server
• this server session agrees on the values of all messages
• all actions viewed in same order by client and server
• there exists exactly one such server session
Similar specification for server
Invariants required by TLS
Server Side Recommendation: If the server reuses Public Key in a protocol different from TLS, then it should not send decryptions of incoming messages
4-Way handshake: Authenticator
Supplicant actions also defined by a straight-line sequential process (cord)
4-Way Handshake properties
The pairwise key (PTK) is fresh and correctly generated from the PMK
Messages 2 and 4 assure authenticator that supplicant messages are current (not replay)
Message 3 assures supplicant that authenticator messages are current (not replay)
Pairwise key PTK derivation produces shared secret between supplicant and authenticator
4-way Handshake Properties
Similar specification for server
4-Way : Relating invariants to deployment
Recommendation: One Principal should not act as both authenticator and supplicant ! Otherwise, reflection attack. Consider careful deployment in Sensor Network scenarios
Group-Key Protocol
Group key handshake
Authenticator guarantee: If principal has the group key, then it must have a shared PTK with the authenticator
Supplicant guarantee: the GTK received was transmitted by the Access Point, and correctly supersedes any GTK from earlier handshakes (4-Way or Group Key)
Observation: For assurance of GTK freshness, important that the first handshake uses 4-Way protocol; one principal should not be authenticator and supplicant, as in the 4-way handshake.
Composition
All necessary invariants are satisfied by basic blocks of all the sub-protocols
The postconditions of TLS imply the preconditions of the 4-Way handshake
The postconditions of 4-Way handshake imply the preconditions of the Group Key protocol
Complex Control Flows
Simple Flow Complex Flow
And what about mobility … ?
IPv4: Triangle routing• All traffic routed through home agent
IPv6: Binding update• Mobile node sends new “care-of
address”• Many risks
– Attacker can subvert existing connection• Announce false care-of address
– Also, can send lots of packets to target• Announce that target is new care-of address for
many connections
Arnab Roy
Representative protocol
X
Y
H
Mobile node Home agent
Corresponding nodeX, Y, H1
1
X, Y, hash(m, n, H, X)
4
4
Y, X, n Y, H, m, X 2 222
H, X, m, Y3
3
Current situation
Under strong assumptions• Assume limited read access to
messages• Can prove that CN receives a good
address Under more realistic assumptions
• Have found many attacks
Conclusions
Protocol analysis methods• Model checking is fairly easy to apply• Ready for industrial use
Wireless 802.11i• Automated study led to improved standard• Deployment recommendations also
Mobile networking• Partial analysis so far• No clear guarantees without key infrastructure