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” (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; - NumResponders: 1; - NumIntruders: 1; - NetworkSize: 1; - MaxKnowledge: 10; - number of initiators number of responders number of intruders max. outstanding msgs in network 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 { - M_NonceAddress, - M_NonceNonce, - }; M_Nonce - types of messages {Na, A}Kb {Na,Nb}Ka {Nb}Kb nonce and addr two nonces one nonce Message : record source: AgentId; - dest: AgentId; - key: AgentId; - mType: MessageType; - nonce1: AgentId; - end; nonce2: AgentId; - 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

 - 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; (3)

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 ini.

number of res.

int.

1 1 2 2 1 1 1 2 1 1 1 1 size of network 1 2 1 1 states 1706 40 207 17 277 514550 time 3.1s

82.2s

43.1s

5761.1s

State Reduction on N-S Protocol

1000000 100000 10000 1000 100 10 1

58 17277 6981 222 514550 155709 3263

1 init 1 resp 2 init 1 resp 2 init 2 resp Base: hand optimization of model CSFW: eliminate net, max knowledge Merge intrud 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

B, { N a } K s S A A B { N b } N a A { N b } K s B   A initiates and B sends session key Several bugs:  replay step 3 for chosen N a ’ I S : I, { N b } Ks

TMN Replay Attack

A C B, { N a } Ks B, { N b } Na D, { N c } Ks D, { N b } Nc S S A A, { N b } Ks B C C, { N b } Ks REPLAY D

TMN Replay with “Blinding”

A C B, { N a } Ks B, { N b } Na S D, { N c } Ks D, { i*N b } Nc S A A, { N b } Ks B C C, i*{ N b } 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  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 Description

ClientHello C  S C, Ver C , Suite C , N C ServerHello S  C Ver S , Suite S , N S , sign CA { S, K S + } ClientVerify C  S sign CA { C, V C } { Ver C , Secret C sign C { Hash( } S + Master(N C , N S , Secret C ) + Pad 2 + Hash( Msgs + C + Master(N C , N S , Secret C ) + Pad 1 ))

(Change to negotiated cipher)

ServerFinished S  C { Hash( Hash( } Master(N C , N S , Secret C ) } Master(N C , N S , Secret C ) + Pad 2 + Msgs + S + Master(N C , N S , Secret C ) + Pad 1 )) ClientFinished C  S { Hash( Master(N C , N S , Secret C ) + Pad 2 + Hash( Msgs + C + Master(N C , N S , Secret C ) + Pad 1 )) } Master(N C , N S , Secret C )

Rational Reconstruction of

SSL  Begin with simple, intuitive protocol C Version C , Suite C Version S , Suite S, Key K S { Secret C } 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)

C … Suite C … … Suite S … … Switch to negotiated cipher Finished Finished data data S

Anomaly (Protocol F)

C … Suite C … … Suite S … … Switch to negotiated cipher Finished X data Finished data X S

Protocol Resumption

C SessionId, Ver C = 3.0, N C , ...

Ver S = 3.0, N S , ...

Finished Finished data data S

Version Rollback Attack

C SessionId, Ver C =

2.0

, N C , ...

Ver S = 2.0

, N S , ...

X { N S } SecretKey { N C } SecretKey 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