

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?




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:

Spec
Give high-level automaton specification for a service, low-level automaton description of distributed implementation.
 invariants, that the implementation satisfies the specification.
Successive refinement:
 Describe algorithms more and more specifically.
 Use simulation relations, invariants.

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

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

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

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

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

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





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






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)






For combined shared-key communication and D-H key distribution protocols.
Domains: M, B, X (no K---keys replaced by baseexponent 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)








Actions π (input, output, internal)
States s, start states
Transitions (s, π, s’) input
 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, output




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

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



Timed automata [Lynch, Vaandrager]:
 Adds timepassage 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].

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



Environment Env(U,A,N)
Signature allows it to communicate elements of universal set U to adversaries in A.
learn(u)
A
Env
 However, in actual executions, it avoids communicating anything in 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





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



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.

PC-send(m) p
PC-receive(m) q
PC reveal(u) a
Spec doesn’t mention separate components, keys---those aspects appear only in implementation description.





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
KD choose-key reveal(u) a

1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
Introduction

Cryptosystem model

I/O Automata

1.
2.
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

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

1




 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
PC
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]




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.
DH
1 grant
IC
DH
2 eavesdrop
Eve reveal learn
Env grant

2




Another forward simulation:

KD’s chosen key is obtained by:


KD
If both XConsts are chosen in S
2 then exponentiate b0 with both of them.
S
2
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.

1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
Introduction

Cryptosystem model

I/O Automata

1.
2.
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




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 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 – 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.

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

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




DH
1
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.
DH
1 grant
PC-send
Enc
DH
2
IC
DH
2 grant
Dec
PC-rcv eavesdrop
Eve learn
Env reveal



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

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