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 model3. I/O Automata4. Some basic automata for security protocols5. Abstract service specifications

1. Private communication (PC)2. Key distribution (KD)

6. Implementing PC using abstract spec for KD7. Implementing KD using Diffie-Hellman8. Simple cryptosystem => richer cryptosystem9. 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 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,

input output

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 (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.)

sA

s’BsB

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 protocols5. Abstract service specifications

1. Private communication (PC)2. Key distribution (KD)

6. Implementing PC using abstract spec for KD7. Implementing KD using Diffie-Hellman8. Simple cryptosystem => richer cryptosystem9. 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)alearn(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.

PCPC-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-Hellman8. Simple cryptosystem => richer cryptosystem9. Putting the pieces together:10. Conclusions

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.

PC-send

IC

Eve

Env

DecEnc

KD

PC-rcv

reveal

reveallearn

grant grant

eavesdrop

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

S1S1

IC

Eve

Env

DH1 DH2

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.

grant grant

eavesdrop

learn reveal

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.

S2

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 cryptosystem9. Putting the pieces together:10. Conclusions

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 to S1. So S’1 implements S1,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

reveallearn

grant grant

eavesdrop

IC

Eve

Env

DH1 DH2

DH1DH2

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

reveallearn

grant grant

eavesdrop

IC

DH1 DH2

DH1 DH2

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