Model Checking for Security

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

2. This Lecture • Building network protocols using cryptographic primitives from last lecture • Overview of model checking • 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?

4. Protocols from the class

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

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

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

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, s0, , ) where • S: set of states • s0:initial state • : set of actions • : transition relation : S x   S I_SLEEP sendmsg1 I_WAIT receivemsg2 I_COMMIT

10. This Lecture • Building network protocols using cryptographic primitives • Overview of model checking • 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 e a b p p;q q;r a c d M (M) = { a;b;c;d;e;f } AP = { p;q;r } alphabet propositions Typically, models of systems are manually created

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

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

15. Query 2: Liveness • Whenever p holds, a happens some time in the future: G ( pFa ) e p p;q q;r a c d counterexample NO! 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.”

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 • Building network protocols using cryptographic primitives • Overview of model checking • Model checking security protocols using the Murphi tool

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

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 • Murphi 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, s0, , ) where • S: set of states • s0:initial state • : set of actions • : transition relation : S x   S I_SLEEP sendmsg1 I_WAIT receivemsg2 I_COMMIT

23. Big Picture Each state of the system is a combination of the state of initiator, responder and intruder Sleep|Sleep|Sleep f Ini:SendMsg1 f Wait|Sleep|Sleep f Int:Intercepts Res:ReceiveMsg1 Wait|Sleep|OneIntercepted Wait|Wait|Sleep f f f f … Commit|Commit|Sleep …

24. Data structures Scalable model 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

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, s0, , ) • 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

27. Initial State in NS (S, s0, , ) • 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;

28. Actions in NS (S, s0, , ) • 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

29. Transition Relation in NS (S, s0, , ) • Transition relation for protocol steps (honest parties) • Transition relation for adversary steps

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) < NetworkSize ==> 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; 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 Murphi 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?