Modeling and Analyzing Security Protocols using IO Automata

  • Slides: 35
Download presentation
Modeling and Analyzing Security Protocols using I/O Automata Nancy Lynch, MIT CSAIL DIMACS Security

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

1. Introduction n Goal: Methods of modeling and analyzing security protocols that are: ¡

1. Introduction n Goal: Methods of modeling and analyzing security protocols that are: ¡ ¡ n 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 n n Separate issues as much as possible. Automata vs. cryptosystems: ¡ ¡

Decomposition n n 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: n n 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.

Decomposing distributed algorithms n Parallel composition of protocols: ¡ n Implementation vs. specification: ¡

Decomposing distributed algorithms n Parallel composition of protocols: ¡ n Implementation vs. specification: ¡ ¡ n Analyze protocols separately, combine using general theorems about automaton composition. 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. Spec Impl

External behavior models n n Basis for compositional reasoning about protocols. Abstract away from

External behavior models n n 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). ¡ n n 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 n Ordinary inputs and outputs ¡ ¡ n For fault-tolerance

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

In this talk… n n n Describe a preliminary example, showing how the Diffie.

In this talk… n n n 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 Introduction Cryptosystem model I/O Automata Some basic automata for security protocols Abstract

Talk outline Introduction Cryptosystem model I/O Automata Some basic automata for security protocols Abstract service specifications 1. 2. 3. 4. 5. 1. 2. 6. 7. 8. 9. 10. 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

Related work n Interactive theorem-proving ¡ [Sheyner, Wing 00] n n n Composition of

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

2. Cryptosystem model n Cryptosystem ¡ Signature n n ¡ ¡ n Type names,

2. Cryptosystem model n Cryptosystem ¡ Signature n n ¡ ¡ n 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 n n Domains: M (messages), K (keys) Functions: ¡ ¡

Ex. 1: Shared-key cryptosystem n n Domains: M (messages), K (keys) Functions: ¡ ¡ n n 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) = m

Ex. 2: Base-exponent cryptosystem n n n For Diffie-Hellman key distribution Domains: B (bases),

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

Ex. 3: Structured-key cryptosystem n n n For combined shared-key communication and D-H key

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

3. I/O Automata [Lynch, Tuttle 87] n n n Actions π (input, output, internal)

3. I/O Automata [Lynch, Tuttle 87] n n n Actions π (input, output, internal) States s, start states Transitions (s, π, s’) ¡ n n n Input actions enabled in all states Execution s 0, π1, s 1, π2, … Trace, sequence of input and output actions ¡ n input 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, output

I/O Automata proof methods n Invariant assertions: ¡ ¡ n Forward and backward simulation

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

Forward simulation from A to B: n Relation R from states(A) to states(B) satisfying:

Forward simulation from A to B: n 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. ) s. B s’B R R s. A π s’A

Timed and probabilistic I/O automata n Timed automata [Lynch, Vaandrager]: ¡ ¡ ¡ n

Timed and probabilistic I/O automata n Timed automata [Lynch, Vaandrager]: ¡ ¡ ¡ n 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 Introduction Cryptosystem model I/O Automata Some basic automata for security protocols Abstract

Talk outline Introduction Cryptosystem model I/O Automata Some basic automata for security protocols Abstract service specifications 1. 2. 3. 4. 5. 1. 2. 6. 7. 8. 9. 10. 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

4. Some basic automata n n Environment Env(U, A, N) Signature allows it to

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

Insecure Channel IC(U, P, A) n n Sends, receives messages in U correctly, between

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

Eavesdropper Eve(P, A) n n Receives everything adversaries in A hear (eavesdrop) from clients

Eavesdropper Eve(P, A) n n 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 compute Eve learn(u)a reveal(u)a

5. Abstract service specifications n Model as I/O Automata. ¡ ¡ n States allow

5. Abstract service specifications n Model as I/O Automata. ¡ ¡ n 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. PC-send(m)p PC PC-receive(m)q reveal(u)a ¡ Spec doesn’t mention separate components, keys---those aspects appear only in implementation description.

Key Distribution service n n KD(U, P, K, A) Grants a single common key

Key Distribution service n n 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 KD reveal(u)a

Talk outline Introduction Cryptosystem model I/O Automata Some basic automata for security protocols Abstract

Talk outline Introduction Cryptosystem model I/O Automata Some basic automata for security protocols Abstract service specifications: 1. 2. 3. 4. 5. 1. 2. 6. 7. 8. 9. 10. 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

6. Implementing PC using abstract KD n n Encoder Encp, q: Encrypts messages from

6. Implementing PC using abstract KD n n 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. KD n System S 1: Compose: ¡ ¡ ¡ Enc, Dec, PC-send KD (abstract), IC, Eve Env, for N = M union K Hide all but external PC actions. grant Enc reveal grant IC eavesdrop Eve learn Env Dec reveal PC-rcv

Proof that S 1 implements PC n Forward simulation: ¡ PC’s message multiset is

Proof that S 1 implements PC n Forward simulation: ¡ PC’s message multiset is the union of S 1’s multisets: n n n Easy inductive argument. Uses invariants: ¡ ¡ n n Messages at Enc Messages at Dec, decrypted with KD’s key Messages in IC, decrypted with KD’s key PC S 11 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]

7. Implementing KD using Diffie-Hellman n DH 1: ¡ ¡ ¡ n DH 2:

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

Proof that S 2 implements KD n Another forward simulation: ¡ KD’s chosen key

Proof that S 2 implements KD n Another forward simulation: ¡ KD’s chosen key is obtained by: n n S 2 Another easy inductive argument. Uses invariants: ¡ ¡ n If both XConsts are chosen in S 2 then exponentiate b 0 with both of them. Else chosen key undefined. KD 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.

Talk outline Introduction Cryptosystem model I/O Automata Some basic automata for security protocols Abstract

Talk outline Introduction Cryptosystem model I/O Automata Some basic automata for security protocols Abstract service specifications: 1. 2. 3. 4. 5. 1. 2. 6. 7. 8. 9. 10. 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

8. Simple → richer cryptosystem n n n Modify S 1 and S 2

8. Simple → richer cryptosystem n n n 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 = B 2, the doublyexponentiated 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 – B 2. 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 n n Compose the two systems S’ 1 and

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

Putting the pieces together, cont’d n Combine adversaries: ¡ ¡ Forward simulation from combined

Putting the pieces together, cont’d n Combine adversaries: ¡ ¡ Forward simulation from combined Eve to two individual Eves. Main ideas: n n The rest is easy… Combine IC channels: ¡ ¡ n 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. 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 n n n Compose systems S’ 1 and S’ 2 using

The final algorithm n n n 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 DH 1 DH 2 DH 1 grant Enc DH 2 IC eavesdrop Eve learn Env grant Dec reveal PC-rcv

10. Conclusions n Summary: ¡ ¡ ¡ n Shared-key communication + Diffie-Hellman Key Distribution

10. Conclusions n Summary: ¡ ¡ ¡ n 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 n n More complex protocols, with active adversaries. Add timing, using Timed

Future Work n n More complex protocols, with active adversaries. Add timing, using Timed IOAs. ¡ ¡ n 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? ].