Modeling and Analyzing Security Protocols using I/O Automata

1. Modeling and Analyzing Security Protocols using I/O Automata Nancy Lynch, MIT CSAIL DIMACS Security Workshop June 7, 2004

2. 1. Introduction • Goal: Methods of modeling and analyzing security protocols that are: • Mathematically precise, • Easy for people to use, • Amenable to computer support, and • Decomposable. • Approach: • Use interacting state machine models: I/O automata (IOA), timed I/O automata (TIOA), probabilistic I/O automata (PIOA). • Separate issues involving component interactions from issues involving cryptosystems. • Use standard I/O automata proof methods: compositional reasoning, invariants, and simulation relations. • Works well for distributed algorithms---why not security protocols?

3. Decomposition • Separate issues as much as possible. • Automata vs. cryptosystems: • Use I/O automata to model individual protocol participants, communication channels, external services, adversaries,… • Use abstract algebraic model for cryptosystems: • Define explicitly which values are computable “easily” from which other values. • Abstracts away from number theory. • I/O automata methods don’t contribute anything here. • Decompose the distributed algorithms.

4. Spec Impl Decomposing distributed algorithms • Parallel composition of protocols: • Analyze protocols separately, combine using general theorems about automaton composition. • Implementation vs. specification: • Give high-level automaton specification for a service, low-level automaton description of distributed implementation. • Show, using simulation relations and invariants, that the implementation satisfies the specification. • Successive refinement: • Describe algorithms more and more specifically. • Use simulation relations, invariants.

5. External behavior models • Basis for compositional reasoning about protocols. • Abstract away from internal behavior of automata with external “traces” (IOA), or “timed traces” (TIOA), or “trace distributions” (PIOA). • Traces include information about input and output events; not about states, internal events. • Trace pasting, projection theorems for I/O automata composition. • For compositional reasoning about particular kinds of properties, traces must contain all information relevant for those properties.

6. Information recorded in traces • Ordinary inputs and outputs • Operation invocations and responses. • Input values and decision results. • For fault-tolerance properties: • Traces contain explicit “fail” events. • Possibly different kinds. • For timing properties: • Traces contain real-time information. • For secrecy properties: • “Learn” inputs, “reveal” outputs.

7. In this talk… • Describe a preliminary example, showing how the Diffie-Hellman Key Distribution protocol and Shared-Key Communication protocol compose to yield private communication. • Passive adversary only. • From old [Lynch 99] CSFW paper. • Use ordinary I/O automata, no timing, no probabilities. • Extensions to more complex protocols, properties seem possible now, using timed I/O automata and probabilistic I/O automata. • However, remains to be done.

8. Talk outline • Introduction  • Cryptosystem model • I/O Automata • Some basic automata for security protocols • Abstract service specifications • Private communication (PC) • Key distribution (KD) • Implementing PC using abstract spec for KD • Implementing KD using Diffie-Hellman • Simple cryptosystem => richer cryptosystem • Putting the pieces together: • Conclusions

9. Related work • Interactive theorem-proving • [Sheyner, Wing 00] • Modeled protocols from this work, proved claims using Isabelle/HOL [Nipkow]. • I/O automata support for Isabelle provided by [Mueller]. • Composition of security protocols: • [Abadi, Fournet, Gonthier 98] • [Canetti 01] • … • Inductive reasoning methods for security protocols: • [Paulson 98]

10. 2. Cryptosystem model • Cryptosystem • Signature • Type names, typed function names • “Easy” function names • Sets for all type names • Total functions for all function names • Term cryptosystem • Elements of sets are congruence classes of terms over the signature, with respect to some congruence relation.

11. Ex. 1: Shared-key cryptosystem • Domains: M (messages), K (keys) • Functions: • enc: M, K → M • dec: M, K → M • MConst, a set of message constants: → M • KConst, a set of key constants: → K • Easy functions: enc, dec • Congruence: Smallest congruence on terms satisfying equation: • dec(enc(m,k),k) = m

12. Ex. 2: Base-exponent cryptosystem • For Diffie-Hellman key distribution • Domains: B (bases), X (exponents) • Functions: • exp: B, X → B • BConst, base constants • XConst1, XConst2, two sets of exponent constants (for use by two parties) • Easy functions: exp, BConst • Congruence defined by: • exp(exp(b,x),y) = exp(exp(b,y),x)

13. Ex. 3: Structured-key cryptosystem • For combined shared-key communication and D-H key distribution protocols. • Domains: M, B, X (no K---keys replaced by base-exponent terms) • Functions: • enc, dec, MConst, exp, BConst, XConst1, XConst2 (no KConst ) • Easy functions: enc, dec, exp, BConst • Congruence: Combine the equations: • dec(enc(m,b),b) = b • exp(exp(b,x),y) = exp(exp(b,y),x)

14. input output 3. I/O Automata [Lynch, Tuttle 87] • Actions π (input, output, internal) • States s, start states • Transitions (s, π, s’) • Input actions enabled in all states • Execution s0, π1, s1, π2,… • Trace, sequence of input and output actions • Externally-visible behavior • A implements B: traces(A) is a subset of traces(B). • Parallel composition: • Compatibility: No shared outputs. • Identify same-named external actions. • One output can match several inputs. • Compositionality theorems: pasting, projection, substitutivity,

15. I/O Automata proof methods • Invariant assertions: • Property holds in all reachable states • Prove by induction on length of execution. • Forward and backward simulation relations • Imply one automaton implements another • Prove by induction on length of execution of implementation automaton. • Compositional methods

16. sB s’B R R π sA s’A Forward simulation from A to B: • Relation R from states(A) to states(B) satisfying: 1. Each start state of A is R-related to some start state of B. 2. For each step (sA, π, s’A ) of A and each state sB of B with sA R sB, there is a “corresponding” sequence of steps of B. (Same trace, takes sB to s’B, where s’A R s’B.)

17. Timed and probabilistic I/O automata • Timed automata [Lynch, Vaandrager]: • Adds time-passage steps or “trajectories”, to describe what happens between discrete events. • External behavior: Set of timed traces • Simulation, compositionality results carry over. • Probabilistic automata [Segala]: • Transitions: (state, action, distribution on states) • External behavior: Set of trace distributions • Forward simulation results carry over. • Compositionality: Partial results. Work in progress [Cheung, Lynch, Segala, Vaandrager].

18. Talk outline • Introduction  • Cryptosystem model  • I/O Automata  • Some basic automata for security protocols • Abstract service specifications • Private communication (PC) • Key distribution (KD) • Implementing PC using abstract spec for KD • Implementing KD using Diffie-Hellman • Simple cryptosystem => richer cryptosystem • Putting the pieces together: • Conclusions

19. learn(u)A Env 4. Some basic automata • Environment Env(U,A,N) • Signature allows it to communicate elements of universal set U to adversaries in A. • However, in actual executions, it avoids communicating anything in N.

20. Insecure Channel IC(U,P,A) • Sends, receives messages in U correctly, between clients in P. • Allows (passive) adversaries in A to eavesdrop on messages in transit. IC IC-send(u) IC-receive(u) eavesdrop(u)a

21. Eavesdropper Eve(P,A) • Receives everything adversaries in A hear (eavesdrop) from clients in P or learn from the environment. • Computes new values, using easy functions of the cryptosystem. • State includes “has” set. • Only reveals values that it “has”. eavesdrop(u)a Eve compute learn(u)a reveal(u)a

22. PC-send(m)p PC PC-receive(m)q reveal(u)a 5. Abstract service specifications • Model as I/O Automata. • States allow assertional reasoning. • Actions allow composition, define what must be preserved by implementations. • Private Communication service, PC(U,P,M,A): • Communicates messages in M reliably, between clients in P. • Can reveal anything in U – M to adversaries in A. • Spec doesn’t mention separate components, keys---those aspects appear only in implementation description.

23. KD Key Distribution service • KD(U,P,K,A) • Grants a single common key in K to clients in P. • Does not grant any other values. • Can reveal anything in U - K to adversaries in A. choose-key grant(k)p reveal(u)a

24. Talk outline • Introduction  • Cryptosystem model  • I/O Automata  • Some basic automata for security protocols  • Abstract service specifications:  • Private communication (PC)  • Key distribution (KD)  • Implementing PC using abstract spec for KD • Implementing KD using Diffie-Hellman • Simple cryptosystem => richer cryptosystem • Putting the pieces together: • Conclusions

25. KD reveal grant grant IC Enc Dec PC-send PC-rcv eavesdrop Eve reveal learn Env 6. Implementing PC using abstract KD • Encoder Encp,q: Encrypts messages from client p to client q using granted key. Sends encrypted messages on IC. • Decoder Decq,p: Decrypts messages from q arriving at p on IC using granted key. Delivers them to p. • System S1: Compose: • Enc, Dec, • KD (abstract), • IC, Eve • Env, for N = M union K • Hide all but external PC actions.

26. Proof that S1 implements PC • Forward simulation: • PC’s message multiset is the union of S1’s multisets: • Messages at Enc • Messages at Dec, decrypted with KD’s key • Messages in IC, decrypted with KD’s key • Easy inductive argument. • Uses invariants: • Key consistency • No element of N = M union K is in IC or in Eve.has. • Stylized case analysis. • Checked with Isabelle/HOL [Sheyner, Wing 00] PC S1 S1

27. IC DH1 DH2 Eve Env 7. Implementing KD using Diffie-Hellman • DH1: • Chooses x in XConst1. • Sends exp(b0,x) to DH2. • After receiving b from DH2, it grants key exp(b,x) to client 1. • DH2: • Symmetric. • S2: Compose automata: • DH1,DH2,IC, Eve • Env, for N = K union X • Hide all but external KD actions. eavesdrop grant grant reveal learn

28. Proof that S2 implements KD • Another forward simulation: • KD’s chosen key is obtained by: • If both XConsts are chosen in S2 then exponentiate b0 with both of them. • Else chosen key undefined. • Another easy inductive argument. • Uses invariants: • Correctness of received messages • No element of N = K union X is in IC or in Eve.has. • Another stylized case analysis, checked with Isabelle. KD S2

29. Talk outline • Introduction  • Cryptosystem model  • I/O Automata  • Some basic automata for security protocols  • Abstract service specifications:  • Private communication (PC)  • Key distribution (KD)  • Implementing PC using abstract spec for KD  • Implementing KD using Diffie-Hellman  • Simple cryptosystem => richer cryptosystem • Putting the pieces together: • Conclusions

30. 8. Simple → richer cryptosystem • Modify S1 and S2 to work with common structured-key cryptosystem instead of shared-key and base-exponent cryptosystems. • Show the resulting systems are still correct, using forward simulations to the original systems S1 and S2. • Example: S’1 = S1 with key space K = B2, the doubly-exponentiated base terms. • Now assume Env avoids communicating M, K, and X. • Also assume Env avoids W, the M messages encrypted any number of times by elements of B – B2. • Show forward simulation from S’1 toS1. • So S’1 implementsS1,so S’1 implements PC. • Key idea of proof: The richer cryptosystem doesn’t introduce new ways of computing any elements of M union K.

31. 9. Putting the pieces together DH1 DH2 • Compose the two systems S’1 and S’2 using ordinary I/O automata composition. • Composed system implements PC, by general I/O automata pasting and projection theorems. IC DH2 DH1 Eve reveal Env grant grant IC Enc Dec PC-send PC-rcv eavesdrop Eve reveal learn Env

32. Putting the pieces together, cont’d • Combine adversaries: • Forward simulation from combined Eve to two individual Eves. • Main ideas: • Information that must not be learned in one sub-protocol is not revealed by the other sub-protocol. • Any information the combined Eve could acquire could also be acquired by either of the individual Eves. • The rest is easy… • Combine IC channels: • One IC channel can simulate two IC channels. • Another forward simulation. • Combine environments: • Combined environments’ avoidance set is the union of the individual environments’ avoidance sets. • Yet another forward simulation.

33. The final algorithm DH1 DH2 • Compose systems S’1 and S’2 using ordinary I/O automata composition. • Merge Eves, ICs, Envs. • Result implements PC, by general I/O automata composition theorems. DH1 DH2 IC grant grant Enc Dec eavesdrop PC-send PC-rcv Eve reveal learn Env

34. 10. Conclusions • Summary: • Shared-key communication + Diffie-Hellman Key Distribution implement Private Communication. • Values that should not be learned by adversary are represented explicitly in external behavior. • Compositional reasoning is used for combining the two protocols: neither reveals information that the other should not learn. • Several kinds of decomposition are used: • Subprotocols • Levels of abstraction, simulation relations • Cryptosystem vs. protocol issues

35. Future Work • More complex protocols, with active adversaries. • Add timing, using Timed IOAs. • What are good properties to consider? • Good protocol examples? • Add probabilities, using Probabilistic IOAs. • Use simple probabilities to state indistinguishability properties. • But try to avoid considering messier “negligible” probabilities. • Work on compositional PIOA still in progress [Cheung, Lynch, Segala, Vaandrager 04?].