1. Analysis of Security Protocols (IV) John C. Mitchell Stanford University

2. Mur  [Dill et al.] l Describe finite-state system  Startstate declaration  Transition rules  Correctness conditions l Scalable: choose system size parameters l Automatic exhaustive testing space limit: hash table to avoid repeated states

3. Mur  for security protocols l Formulate protocol l 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) l Identify correctness conditions

4. 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};

5. 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;

6. 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;

7. Adversary Model l Formalize “knowledge”  initial data  observed message fields  results of simple computations l Optimization  only generate messages that others read  time-consuming to hand simplify l Future goal: automatic generation

8. Run of Needham-Schroeder l Find error after 1.7 seconds exploration l Output: trace leading to error state Mur  times after correcting error:

10. State Reduction on N-S Protocol

11. Limitations l 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 l Adversary model  Cannot model randomized attack  Do not model adversary running time

12. Analysis Results l 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 l Largest case study: SSL protocol

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

14. TMN Replay Attack SBA B, {N a } Ks A A, {N b } Ks B, {N b } Na SDC D, {N c } Ks C C, {N b } Ks D, {N b } Nc REPLAY

15. TMN Replay with “Blinding” SBA B, {N a } Ks A A, {N b } Ks B, {N b } Na SDC D, {N c } Ks C C, i*{N b } Ks D, {i*N b } Nc REPLAY

16. Modeling Challenge l Avoid repeated keys by storing list  Do not allow new session with old key l But RSA allows “blinding”:  Adversary sends multiple of old key  Divides later message by multiplier Need to model multiplication in Mur j  Model message by pair: datum, blinding bit

17. Secure Socket Layer (SSL) l De facto standard for Internet security Goal: “... provide privacy and reliability between two communicating applications ” l Handshake Protocol Use public-key cryptography to establish shared secret key l Record Layer Transmit data using negotiated key

18. Handshake Protocol (SSL) l 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

19. Rational Reconstruction of SSL l Begin with simple, intuitive protocol  Client sends id, version, crypto preference  Server sends version, crypto pref, public key  Client sends encrypted random secret l Model check and find bug  Intruder can modify server public key, obtain client secret, then sent to complete protocol l Fix bug and repeat, to produce full SSL

20. SSL Handshake Protocol l Negotiate version, crypto suite  Possible “version rollback attack” l Authenticate client and server  Appeal to “certificate authority” l Use public key to establish shared secret Several underlying primitives: public key, signature, hash function, private key

21. Handshake Protocol Description ClientHello C  S C, Ver C, Suite C, N C S C Ver S, Suite S, N S, S, K S + 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 } + N S sign C { Hash( Master(N C, N S, Secret C ) + Pad 2 + N S Hash(Msgs + C + Master(N C, N S, Secret C ) + Pad 1 )) } (Change to negotiated cipher) N S ServerFinished S  C { Hash( Master(N C, N S, Secret C ) + Pad 2 + N S Hash( Msgs + S + Master(N C, N S, Secret C ) + Pad 1 )) } N S ClientFinished C  S { Hash( Master(N C, N S, Secret C ) + Pad 2 + N S Hash( Msgs + C + Master(N C, N S, Secret C ) + Pad 1 )) } SKSSKS S Master(N C, N S, Secret C )

22. l Begin with simple, intuitive protocol l Model check and find bug l Add a piece of SSL to fix bug and repeat Rational Reconstruction of SSL Version C, Suite C Version S, Suite S, Key K S { Secret C } CS KSKS

23. Summary of Reconstruction l A = Basic protocol l C = A + certificates for public keys  Authentication for client and server l E = C + verification (Finished) messages  Prevention of version and crypto suite attacks l F = E + nonces  Prevention of replay attacks l Z = “Correct” subset of SSL

24. Anomaly (Protocol F) CS … Suite C … … Suite S … … Switch to negotiated cipher Finished data

25. Anomaly (Protocol F) CS … Suite C … … Suite S … … Switch to negotiated cipher Finished data X X Modify

26. Protocol Resumption CS SessionId, Ver C = 3.0, N C,... Finished data Ver S = 3.0, N S,...

27. Version Rollback Attack CS SessionId, Ver C = 2.0, N C,... Finished data Ver S = 2.0, N S,... X X { N S } SecretKey { N C } SecretKey

28. Protocol Analysis l Protocol Specification Abstract notions of message, key, nonce, cryptographic functions l Protocol Analysis High-level models for crypto primitives l Protocol Implementation Specific key length, random number generator, encryption and decryption functions

29. What Do We Learn? l Find an error  Error in Mur  model implies error in protocol  Can confirm error in impl by testing l 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

30. Conclusions Mur  is useful tool for complex protocols l Rational reconstruction of protocol  Understand protocol  Ensure “completeness” of analysis  Protocol spec simpler, more precise than RFC l Uncover problem areas in SSL  SSL 2.0 errors identified  “Gray” areas in the resumption protocol