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

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?

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.

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. Decomposing distributed algorithms Spec Impl

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.

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.

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.

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

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]

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.

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

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)

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)

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 s 0, π 1, s 1, π 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, inputoutput

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

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 (s A, π, s’ A ) of A and each state s B of B with s A R s B, there is a “corresponding” sequence of steps of B. (Same trace, takes s B to s’ B, where s’ A R s’ B.) sAsA s’ B sBsB s’ A π R R

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

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

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. Env learn(u) A

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

Eve 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 reveal(u) a learn(u) a compute

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. PC PC-send(m) p PC-receive(m) q reveal(u) a

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. grant(k) p choose-key reveal(u) a KD

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

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

Proof that S 1 implements PC Forward simulation:  PC’s message multiset is the union of S 1 ’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 S1S1 S1S1

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

Proof that S 2 implements KD Another forward simulation:  KD’s chosen key is obtained by: If both XConsts are chosen in S 2 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. S2S2 KD

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

8. Simple → richer cryptosystem Modify S 1 and S 2 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 S 1 and S 2. Example: S’ 1 = S 1 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 to S 1.  So S’ 1 implements S 1,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.

9. Putting the pieces together 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. PC-send IC Eve Env DecEnc PC-rcv reveal learn grant eavesdrop IC Eve Env DH 1 DH 2 DH 1 DH 2

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.

The final algorithm 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. PC-send Eve Env DecEnc PC-rcv reveal learn grant eavesdrop IC DH 1 DH 2 DH 1 DH 2

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

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?].