1. Model Checking for Security Anupam Datta CMU Fall 2009 18739A: Foundations of Security and Privacy

2. This Lecture 1. Building network protocols using cryptographic primitives from last lecture 2. Overview of model checking 3. Model checking security protocols using the Murphi tool

3. Authenticating over an untrusted network  How can Alice use cryptography to send an authenticated message to Bob over an untrusted network?  What is authentication?  What can go wrong? 3

4. Protocols from the class 4

5. A’s reasoning: The only person who could know NonceA is the person who decrypted 1 st message Only B can decrypt message encrypted with Kb Therefore, B is on the other end of the line B is authenticated! Authentication by Encryption AB A’s identityFresh random number generated by A B’s reasoning: The only way to learn NonceB is to decrypt 2 nd message Only A can decrypt 2 nd message Therefore, A is on the other end A is authenticated! Kb { NonceB} Ka { NonceA, NonceB } Kb { A, NonceA } [Needham- Schroeder 1978]

6. What Does This Protocol Achieve? AB Kb { NonceB} Ka { NonceA, NonceB } Kb { A, NonceA }  Protocol aims to provide both authentication and secrecy  After this exchange, only A and B know NonceA and NonceB

7. B can’t decrypt this message, but he can replay it Anomaly in Needham-Schroeder AB { A, Na } Kc C { A, Na } Kb { Na, Nc } Ka { Na, Nc } Ka { Nc } Kb Evil agent B tricks honest A into revealing C’s private value Nc C is convinced that he is talking to A! [published by Lowe 1995] Evil B pretends that he is A

8. Lessons of Needham-Schroeder  Classic man-in-the-middle attack  Exploits participants’ reasoning to fool them  A is correct that B must have decrypted {A,Na} Kb message, but this does not mean that {Na,Nb} Ka message came from B  The attack has nothing to do with cryptography!  It is important to realize limitations of protocols  The attack requires that A willingly talk to adversary  In the original setting, each workstation is assumed to be well- behaved, and the protocol is correct!  Wouldn’t it be great if one could discover attacks like this automatically?

9. NS Initiator as a State Machine  State machine (S, s 0, ,  ) where  S: set of states  s 0 :initial state   : set of actions   : transition relation  : S x   S 9 I_SLEEP sendmsg1 I_WAIT I_COMMIT receivemsg2

10. This Lecture 1. Building network protocols using cryptographic primitives 2. Overview of model checking 3. Model checking security protocols using the Murphi tool

11. Model Checking  Algorithm for checking properties about behaviors of finite state machines  Given a state machine M and a property , does M satisfy   ?  Discovered independently by Clarke & Emerson and Queille & Sifakis in 1981 2007 Turing Award to Clarke, Emerson & Sifakis http://www.acm.org/press-room/news-releases/turing-award-07/

12. Models: Doubly Labeled State Machines pp;q a a b c d e M  ( M ) = { a;b;c;d;e;f } AP = { p;q;r } q;r alphabet propositions Typically, models of systems are manually created

13. Property 1: Safety  p and r are never true at the same time: G (  ( p  r) )  pp;q a a b c d e q;r YES! Safety: “Nothing bad happens” More relevant for security: secrecy, authentication, order of system calls (MOPS) Model checking is a graph search problem

14. Property 2: Liveness  Whenever p holds, a happens some time in the future: G ( p  F a )  pp;q a a b c d e q;r Liveness: “Something good eventually happens”

15. Query 2: Liveness  Whenever p holds, a happens some time in the future: G ( p  F a )  pp;q ac d e q;r NO! counterexample Counterexample useful for diagnostics

16. 2007 Turing Award Citation “ This verification technology provides an algorithmic means of determining whether an abstract model--representing, for example, a hardware or software design--satisfies a formal specification expressed as a temporal logic formula. Moreover, if the property does not hold, the method identifies a counterexample execution that shows the source of the problem. … As a result many major hardware and software companies are now using Model Checking in practice. Examples of its use include the verification of VLSI circuits, communication protocols, software device drivers, real-time embedded systems, and security algorithms.” 16

17. Model Checking: Pros and Cons  Pros:  Fully automated  Fast (relative to similar rigorous methods)  Counterexample useful for diagnostics Cons  No correctness proof  Applies to finite model (though some exceptions)  State space explosion (many techniques to address) 15-817: Introduction to Model Checking

18. This Lecture 1. Building network protocols using cryptographic primitives 2. Overview of model checking 3. Model checking security protocols using the Murphi tool

19. Big Picture Intruder Model Checker Formal Protocol Informal Protocol Description Find error Specify Property RFC, IETF draft, research paper…

20. Making the Model Finite  Two sources of infinite behavior  Many instances of participants, multiple runs  Message space or data space may be infinite  Finite approximation  Assume finite number of participants  For example, 2 clients, 2 servers  Mur phi is scalable: can choose system size parameters  Assume finite message space  Represent random numbers by constants r1, r2, r3, …  Do not allow encrypt(encrypt(encrypt(…)))

21. Applying Murphi to Security Protocols  Formulate the protocol  Define a datatype for each message format  Describe finite-state behavior of each participant  If received message M3, then create message M4, deposit it in the network buffer, and go to state WAIT  Describe security condition as state invariant  Add adversary  Full control over the “network” (shared buffer)  Nondeterministic choice of actions  Intercept a message and split it into parts; remember parts  Generate new messages from observed data and initial knowledge (e.g., public keys) Mur  will try all possible combinations

22. NS Initiator as a State Machine  State machine (S, s 0, ,  ) where  S: set of states  s 0 :initial state   : set of actions   : transition relation  : S x   S 22 I_SLEEP sendmsg1 I_WAIT I_COMMIT receivemsg2

23. Big Picture  should hold in all states Wait|Sleep|Sleep Wait|Sleep|OneIntercepted Commit|Commit| Sleep … Sleep|Sleep|Sleep …       Wait|Wait|Sleep  Ini:SendMsg1 Res:ReceiveMsg1 Int:Intercepts Each state of the system is a combination of the state of initiator, responder and intruder

24. Data structures const NumInitiators: 1; -- number of initiators NumResponders: 1; -- number of responders … type InitiatorId: scalarset (NumInitiators); InitiatorStates: enum{I_SLEEP, I_WAIT, I_COMMIT}; Initiator: record state: InitiatorStates responder: AgentId end; var ini: array [InitiatorId] of Initiator Scalable model

25. Messages and network 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; var net: multiset[NetworkSize] of Message; -- state variable for n/w

26. States in NS (S, s 0, ,  )  var -- state variables for  net: multiset[NetworkSize] of Message; -- network  ini: array[InitiatorId] of Initiator; -- initiators  res: array[ResponderId] of Responder; -- responders  int: array[IntruderId] of Intruder; -- intruders 26

27. Initial State in NS (S, s 0, ,  )  startstate  -- initialize initiators  undefine ini;  for i: InitiatorId do  ini[i].state := I_SLEEP;  ini[i].responder := i;  end;  -- initialize responders  -- make all responder states R_SLEEP  -- initialize intruders  -- make all intruder stored nonces empty  -- initialize network  undefine net;  end; 27

28. Actions in NS (S, s 0, ,  )  Actions in Murphi model of NS update the state variables  multisetadd (outM,net); -- add message to the network  res[i].state := R_WAIT; -- change responder state 28

29. Transition Relation in NS (S, s 0, ,  )  Transition relation for protocol steps (honest parties)  Transition relation for adversary steps 29

30. Modeling Protocol Actions ruleset i: InitiatorId do ruleset j: AgentId do rule 20 "initiator starts protocol" ini[i].state = I_SLEEP & !ismember(j,InitiatorId) & multisetcount (l:net, true) var outM: Message; -- outgoing message begin undefine outM; outM.source := i; outM.dest := j; outM.key := j; outM.mType := M_NonceAddress; outM.nonce1 := i; outM.nonce2 := i; multisetadd (outM,net); ini[i].state :=I_WAIT; ini[i].responder := j; end; end;end;

31. Adversary Model  Formalize “knowledge”  initial data  observed message fields  results of simple computations

32. Modeling the attacker -- 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;

33. Modeling Properties of NS invariant "responder correctly authenticated" forall i: InitiatorId do ini[i].state = I_COMMIT & ismember(ini[i].responder, ResponderId) -> res[ini[i].responder].initiator = i & ( res[ini[i].responder].state = R_WAIT | res[ini[i].responder].state = R_COMMIT ) end;

34. Murphi [Dill et al.]  Describe finite-state system  State variables with initial values  Transition rules for each protocol participant & attacker  Communication by shared variables  Specify security condition as a state invariant  Predicate over state variables that must be true in every state reachable by the protocol  Automatic exhaustive state enumeration  Can use hash table to avoid repeating states  Research and industrial protocol verification

35. Limitations  System size with current methods  2-6 participants Kerberos: 2 clients, 2 servers, 1 KDC, 1 TGS  3-6 steps in protocol  Adversary model  Cannot model randomized attack  Do not model adversary running time

36. Try Playing With Murphi  You’ll need to use Murp hi for your first homework  The input language is easy to understand, but ask us if you are having problems  Simple IF… THEN… guarded commands  Attacker is nondeterministic

37. Homework #1 (Using Murphi)  Investigate the NS flaw and the fixed Needham Schroeder Lowe protocol  Investigate conditions under which attack succeeds: adversary power, initiator behavior and crypto (malleable encryption)  Investigate version rollback attack on SSL protocol

38. Announcements  Form groups and send email to Arunesh with your group members  Homework 1 out next Tuesday (due in 2 weeks)

39. Questions?