Analysis of Security Protocols
(IV)
John C. Mitchell Stanford University
Mur
[Dill et al.]
Describe finite-state system
Startstate declaration Transition rules Correctness conditions
Scalable: choose system size parameters Automatic exhaustive testing
space limit: hash table to avoid repeated states
Mur for security protocols
Formulate protocol Add adversary
Control over “network” Possible actions
(shared variables)
Intercept any message Remember parts of messages Generate new messages, using observed data and initial knowledge (e.g. public keys)
Identify correctness conditions
Needham-Schroeder in Mur (1)
const NumInitiators: 1; NumResponders: 1; NumIntruders: 1; NetworkSize: 1; MaxKnowledge: 10; type InitiatorId: ResponderId: IntruderId: AgentId:
------
number of initiators number of responders number of intruders max. outstanding msgs in network number msgs intruder can remember
scalarset (NumInitiators); scalarset (NumResponders); scalarset (NumIntruders);
union {InitiatorId, ResponderId, IntruderId};
Needham-Schroeder in Mur (2)
MessageType : enum { M_NonceAddress, M_NonceNonce, M_Nonce }; Message : record source: AgentId; dest: AgentId; key: AgentId; mType: MessageType; nonce1: AgentId; nonce2: AgentId; end; -- types of messages -- {Na, A}Kb nonce and addr -- {Na,Nb}Ka two nonces -- {Nb}Kb one nonce
-------
source of message intended destination of msg key used for encryption type of message nonce1 nonce2 OR sender id OR empty
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;
Adversary Model
Formalize “knowledge”
initial data observed message fields results of simple computations
Optimization
only generate messages that others read time-consuming to hand simplify
Future goal: automatic generation
Run of Needham-Schroeder
Find error after 1.7 seconds exploration Output: trace leading to error state example Mur times after correcting error:
number of ini. res. int. 1 1 1 1 1 1 2 1 1 2 2 1
size of network 1 2 1 1
states time 1706 3.1s 40207 82.2s 17277 43.1s 514550 5761.1s
State Reduction on N-S Protocol
1000000 100000 10000 1000 100 10 1
1706 980 222 58 17277 6981 514550 155709
Base: hand optimization of model CSFW: eliminate net, max knowledge Merge intrud send, princ reply
3263
1 init 1 resp
2 init
2 init
1 resp 2 resp
Limitations
System size with current methods
2-6 participants
Kerberos: 2 clients, 2 servers, 1 KDC, 1 TGS
3-6 steps in protocol May need to optimize adversary
Adversary model
Cannot model randomized attack Do not model adversary running time
Analysis Results
Analyze common protocols
Needham-Schroeder Kerberos
Found bug in documented algorithm (not in RFC) one client, two servers Found all known bugs automatically Model algebraic properties of encryption function
TMN cellular phone protocol
Largest case study: SSL protocol
TMN Protocol
B, {Na }
S
B {Nb } A {Nb } K
Ks
A
A
Na
B
s
A initiates and B sends session key Several bugs:
replay step 3 for chosen Na’ I S : I, {Nb}Ks
TMN Replay Attack
B, {Na}Ks A
A
B, {Nb}Na
D, {Nc}Ks
S
A, {Nb}Ks
C
B
C
D, {Nb}Nc
S
C, {Nb}Ks
REPLAY
D
TMN Replay with “Blinding”
B, {Na}Ks A
A
B, {Nb}Na
D, {Nc}Ks
S
A, {Nb}Ks
C
B
C
D, {i*Nb}Nc
S
C, i*{Nb}Ks
REPLAY
D
Modeling Challenge
Avoid repeated keys by storing list
Do not allow new session with old key
But RSA allows “blinding”:
Adversary sends multiple of old key Divides later message by multiplier
Need to model multiplication in Mur
Model message by pair: datum, blinding bit
Secure Socket Layer (SSL)
De facto standard for Internet security Goal: “... provide privacy and reliability between two communicating applications” Handshake Protocol
Use public-key cryptography to establish shared secret key
Record Layer
Transmit data using negotiated key
Handshake Protocol (SSL)
Three goals
Negotiate specific encryption scheme
Possible “version attack”
Authenticate client and server
Appeal to “signature authority”
Use public key to transmit secret key
Several underlying primitives: public key, signature scheme, hash function, private key
Rational Reconstruction of SSL
Begin with simple, intuitive protocol
Client sends id, version, crypto preference Server sends version, crypto pref, public key Client sends encrypted random secret
Model check and find bug Fix bug and repeat, to produce full SSL
Intruder can modify server public key, obtain client secret, then sent to complete protocol
SSL Handshake Protocol
Negotiate version, crypto suite
Possible “version rollback attack”
Authenticate client and server
Appeal to “certificate authority”
Use public key to establish shared secret
Several underlying primitives: public key, signature, hash function, private key
Handshake Protocol Description
ClientHello ServerHello ClientVerify CS SC CS C, VerC, SuiteC, NC VerS, SuiteS, NS, signCA{ S, KS+ }
signCA{C, VC } { VerC, SecretC } K + S signC { Hash( Master(NC, NS, SecretC) + Pad2 + Hash(Msgs + C + Master(NC, NS, SecretC) + Pad1)) } (Change to negotiated cipher) ServerFinished S C { Hash( Master(NC, NS, SecretC) + Pad2 + Hash( Msgs + S + Master(NC, NS, SecretC) + Pad1)) } Master(N , N , Secret )
C S C
ClientFinished C S
{ Hash( Master(NC, NS, SecretC) + Pad2 + Hash( Msgs + C + Master(NC, NS, SecretC) + Pad1)) } Master(N , N , Secret )
C S C
Rational Reconstruction of SSL
Begin with simple, intuitive protocol
VersionC, SuiteC
C
VersionS, SuiteS, Key KS { SecretC } K S
S
Model check and find bug Add a piece of SSL to fix bug and repeat
Summary of Reconstruction
A = Basic protocol C = A + certificates for public keys
Authentication for client and server
E = C + verification (Finished) messages
Prevention of version and crypto suite attacks
F = E + nonces
Prevention of replay attacks
Z = “Correct” subset of SSL
Anomaly (Protocol F)
… SuiteC … … SuiteS … …
C
Switch to negotiated cipher
S
Finished
data
Finished
data
Anomaly (Protocol F)
… SuiteC … … SuiteS … …
C
Switch to negotiated cipher
S
Finished
X
Finished data
data
X
Protocol Resumption
SessionId, VerC= 3.0, NC, ... VerS= 3.0, NS, ...
C
Finished
Finished
S
data
data
Version Rollback Attack
SessionId, VerC= 2.0, NC, ... VerS= 2.0, NS, ...
C
Finished { NS } SecretKey
X
Finished { NC } SecretKey
X
S
data
data
Protocol Analysis
Protocol Specification
Abstract notions of message, key, nonce, cryptographic functions
Protocol Analysis
High-level models for crypto primitives
Protocol Implementation
Specific key length, random number generator, encryption and decryption functions
What Do We Learn?
Find an error
Error in Mur model implies error in protocol Can confirm error in impl by testing
Do not find error
Not a proof of correctness
Idealized adversary, communication models Bound on number of participants Implementation may not be faithful to specification
Correct impl safe against certain attacks
Conclusions
Mur is useful tool for complex protocols Rational reconstruction of protocol
Understand protocol Ensure “completeness” of analysis Protocol spec simpler, more precise than RFC
Uncover problem areas in SSL
SSL 2.0 errors identified “Gray” areas in the resumption protocol