Analysis of Security Protocols (IV) John C. Mitchell Stanford University
Dec 20, 2015
Analysis of Security Protocols (IV)
John C. MitchellStanford 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” (shared variables)
Possible actions 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; -- 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;
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
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
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
TMN cellular phone protocol Found all known bugs automatically Model algebraic properties of encryption function
Largest case study: SSL protocol
TMN Protocol
A initiates and B sends session key Several bugs:
replay step 3 for chosen Na’ I S : I, {Nb}Ks
a
N ab b K
K s
s
S
BA
B, {N } A
B{N }
A{N }
TMN Replay Attack
S BAB, {Na}Ks A
A, {Nb}KsB, {Nb}Na
S DCD, {Nc}Ks C
C, {Nb}KsD, {Nb}Nc
REPLAY
TMN Replay with “Blinding”
S BAB, {Na}Ks A
A, {Nb}KsB, {Nb}Na
S DCD, {Nc}Ks C
C, i*{Nb}KsD, {i*Nb}Nc
REPLAY
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 Intruder can modify server public key, obtain
client secret, then sent to complete protocol Fix bug and repeat, to produce full SSL
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 DescriptionClientHello CS C, VerC, SuiteC, NC
ServerHello S S C Ver C VerSS, Suite, SuiteSS, N, NSS, , signCA{ S, K S, 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)
Begin with simple, intuitive protocol
Model check and find bug Add a piece of SSL to fix bug and repeat
Rational Reconstruction of SSL
VersionC, SuiteC
VersionS, SuiteS, Key KS
{ SecretC }
C SKS
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)
C S
… SuiteC …
… SuiteS …
…
Switch to negotiated cipher
Finished Finished
data data
Anomaly (Protocol F)
C S
… SuiteC …
… SuiteS …
…
Switch to negotiated cipher
Finished Finished
data dataX X
Modify
Modify
Protocol Resumption
C S
SessionId, VerC= 3.0, NC, ...
Finished Finished
data data
VerS= 3.0, NS, ...
Version Rollback Attack
C S
SessionId, VerC= 2.0, NC, ...
Finished Finished
data data
VerS= 2.0, NS, ...
XX{ NS } SecretKey { NC } SecretKey
Protocol Analysis
Protocol SpecificationAbstract notions of message, key, nonce,
cryptographic functions
Protocol AnalysisHigh-level models for crypto primitives
Protocol ImplementationSpecific 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
Muris 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