Formal Methods and Protocol Analysis

7 June 2004DIMACS

P Y A RyanFormal Methods and Protocol Analysis

1

Formal Methods and Protocol Analysis

Peter Y A RyanUniversity of Newcastle

7 June 2004DIMACS


2

A Brief History of Security Protocol Analysis

• BAN logic of authentication.• Dolev-Yao.• NRL Analyser.• Interrogator.• FDM and Inajo.• The B-method.• The CSP approach.• Inductive approach (Isabelle).• Strand Spaces (Authentication tests, Athena,…)• Non-interference.• Spi-calculus.• Multi-Set-Rewriting.• Automata.• Petri Nets (strand spaces, opacity, causality,…)

7 June 2004DIMACS


3

BAN logic

• P | X P “believes” X• PKQ Key K is good for

communication between P and Q.(X) X is fresh.• P X P sees X.• P |~ X P once said X.• Example rule:P | (PKQ), P {X}K P | (Q|~ X)

7 June 2004DIMACS


4

BAN logic

• Assumptions and protocol steps are translated into terms of the logic (idealisation).

• Attempt to derive the authentication goals by application of the rules.

• “….several scalps under its belt”

7 June 2004DIMACS


5

Getting off the BAN Wagon

• Drawbacks of BAN:– Definition of authentication implicit.– Adversary capabilities implicit and hard-wired (in the

choice of rules).– Takes defensive viewpoint.– Assumes principles “honest”.– Needs extension to deal with other goals and

primitives.– (initial) lack of semantics.– Delicacy of “idealisation”.

7 June 2004DIMACS


6

Myths and Mythconceptions

• Authentication continues to be a slippery concept.

• Authentication of origin seems fairly clear cut.• Entity authentication rather delicate.• Definition from “The Handbook”:• “Entity authentication is the process whereby

one party is assured of the identity of a second party involved in a protocol, and that the second has actually participated”

7 June 2004DIMACS


7

Myths…

• So what does “involved” mean, or “participated”….?

• Consider the Lowe scenario for the NSPK protocol. Is this definition violated?

• How is a violation detected (manifest)?• Not clear that an intrusion detection device

could detect this.• What is authentication really supposed to

achieve?

7 June 2004DIMACS


8

Lowe attack on NSPK

• AB: {A, na}PKb

• BA: {na, nb}PKa

• AB: {nb}PKa

• AY : {A, na}PKy

• Y(A)B : {A, na}PKb

• BA[Y] : {na, nb}Pka

• YA : {na, nb}PKa

• AY : {nb}PKy

• Y(A)B : {nb}PKb

7 June 2004DIMACS


9

Discussion

• The upshot is that Anne believes that she has been interacting with Yves. Bob believes that he has been interacting with Anne, when in fact he’s been interacting with Yves.

• Note however that Anne does need to be present.

• Note: Yves does not play by the rules, i.e., violates one of the BAN assumptions.

7 June 2004DIMACS


10

The Dolev-Yao Approach• Treated the problem as a term re-writing

problem.• Decidability results.• Proposed the (FM) standard model of the

adversary:– Full powers short of breaking the crypto: tap, kill,

replay, reroute, reorder, fake,…– Perfect crypto– Free algebra of terms, aside from:

D(k, E(k, m))= mAnd, where appropriate:

E(k,D(k, m)) = m

7 June 2004DIMACS


11

Adversary Model

• Adversary can construct terms using an inference system, e.g.:

k, m |- {m}k

{m}k, k-1 |- m

(m, n) |- mm, n |- (m, n)m |- hash(m)

7 June 2004DIMACS


12

The CSP approach

• Natural for reasoning about systems exchanging messages, i.e., protocols.

• Explicit adversary model.• Explicit formalisation of goals.• Less of an idealisation gap.• Good tool support.

7 June 2004DIMACS


13

Syntax of CSP• aP prefix• P[]Q external choice• P Q non-deterministic choice• P||XQ parallel composition over X• P|||Q interleave (= P||{}Q)• P\A hide events A• P[R] renaming (relation R)• S/tr S after trace tr.• P=F(P) recursive definition

7 June 2004DIMACS


14

Semantics

• Several denotational semantics available:• Traces-a process denotes a set of

behaviours.• Fine for safety properties. Not rich enough

to handle livelock, non-determinism etc.• Failures-deals with livelock and non-

determinism.• Also operational semantics.

7 June 2004DIMACS


15

Specifications • Trace properties defined as a set of acceptable

behaviours (traces).• Specifications can given as abstract CSP

processes-essentially a process whose trace set equals (or subset of) the characteristic set of the property.

• Checking a putative implementation then reduces to a refinement check.

• Traces refinement checks set inclusion. • Refinement is monotonic and compositional.

7 June 2004DIMACS


16

Trustworthy agentsE.g., Yahalom:

1. AB: a, na

2. BS: b, {a, na, nb}Ksb

3. SA: {b, kab, na, nb}Ksa, {a, kab}Ksb

4. AB: {a, kab}Ksb, {nb}Kab

A, initiators view:1. A sends b: a, na

2. A receives: {b, kab, na, nb}Ksa, {a, kab}Ksb

3. A sends b: {a, kab}Ksb, {nb}Kab

7 June 2004DIMACS


17

As a CSP process

Initiator(a, na) =

Env?b: Agent send.a.b.a.na

[] kab Key, nb Nonce, m T

(receive.S.a. {b, kab, na, nb}Ksa.m

Send.a.b.m. {nb}Kab Session(a,b, kab, na, nb))

7 June 2004DIMACS


18

The AdversaryAdversary(X)=learn?a.b.m :

messagesAdversary(close(X{m}))

fake!a.b.m : X messages Adversary(X)

leak!m : X messages Adversary(X)

• X represents the adversary’s knowledge.• Close forms the closure under the inference

operators.

7 June 2004DIMACS


19

The System

• The system is then an appropriate composition of agents: legitimate principles, server, adversary.

• Often convenient to identify medium with adversary.

• System := (|||Agents)||Yves||[Jeeves]

7 June 2004DIMACS


20

Properties • Authentication

– Of origin.– Entity.– Injective.

• Secrecy.• (authenticated) key-exchange.• Anonymity.• Non-repudiation.• Robustness (against DoS attacks).• Fairness.

7 June 2004DIMACS


21

Secrecy • In protocol analysis, typically coded in terms of leakage

of secret terms.• Secrecy fails if the adversary can deduce a secret item

from M.System\(-leak.M) refinestraces Stop

• LHS: hide all events except leaking of sensitive terms.• If this refines Stop then no such events can occur.• If System can leak a term from M this refinement check

will be violated and FDR will provide a counter-example (attack).

7 June 2004DIMACS


22

Authentication of origin • An event b authenticates and event a if b can

only occur after a. For example:• Receives.a.b.m authenticates send.a.b.m if:

System||send.a.b.mStop refinestraces System||send.a.b.m,

recieves.a.b.mStop • LHS: prevents send events.• RHS: prevents both send and receive events.• If System violates this authentication, this

refinement will be violated.• Comes in various flavours.

7 June 2004DIMACS


23

Anonymity

• Can be formulated as the invariance, from an appropriate viewpoint, of the system under arbitrary permutations over the anonymity set, A say:

A Abs(System) traces Abs((System))• Various abstraction operators available:

eager or lazy hiding, projection (renaming) etc.

7 June 2004DIMACS


24

Non-repudiation

• Very similar to authentication but with a different threat model: “trustworthy” agents given adversary style capabilities, in particular ability to fake terms up to crypto limitations.

• Goal: to furnish agents with unfakeable evidence of certain actions.

7 June 2004DIMACS


25

FDR/model-checking• The FDR model-checker proved to be a powerful

tool for analysis.• Checks trace or failure refinement.• Provide a Spec and an Impl (both written in

CSP) and run refinement check.• Failures of refinement throw up counter-

examples which indicate attacks.• Drawback: models tend to blow up.

Considerable ingenuity needed to cope with this.• Various compressions available, e.g., chase.

7 June 2004DIMACS


26

Rank functions• Alternative line of attack proposed by Steve Schneider.• Rank function is a mapping from the message space into

{0, 1}. 0 assigned to terms that need to be kept private, 1 to terms that can be public.

• Show that agents are rank preserving.• Essentially an invariants approach.• Avoids state-space explosion. • Finding rank functions or demonstrating their non-

existence can be tricky, but (partially?) automated now.• Note: links to Abadi et al’s typing approaches.

7 June 2004DIMACS


27

Casper

• User-friendly interface to FDR.• Protocol specified in a fairly standard

notation (c.f. CAPSL).• % notation for encrypted terms.• Standard goals: secrecy, authentication.

7 June 2004DIMACS


28

Extensions

• Data-independence.• Induction.• Lazy compilation.• Partial order.• Simplifying transformations.• Simple algebra, e.g., Vernam encryption.

7 June 2004DIMACS


29

Other Approaches• NRL Analyser.• Interrogator.• FDM and Inajo.• The B-method.• Inductive approach (Isabelle).• Strand Spaces (Authentication tests, Athena,…)• Spi-calculus.• Multi-Set-Rewriting.• Automata.• Petri Nets (strand spaces, opacity, causality,…)

7 June 2004DIMACS


30

Beyond Dolev-Yao

• Richer adversary models:– Computational/complexity limitations.– Limits on capability to monitor and intercept– Richer inference capabilities:

• Algebraic identities• Typing• Guessing

– Game theoretic approaches

7 June 2004DIMACS


31

Faithful abstractions• Most FM approaches make sweeping

abstractions of underlying primitives:– Perfect cryptography.– Free algebra of terms.– Trace models.– Typing assumptions…

• Progress by crypto folk, e.g., universal composability, crypto libraries.

• Some by FM folk: incorporation of various algebraic identities in models and tools.

7 June 2004DIMACS


32

Trace formulations

• Note: usual to formulate goals in terms of traces (reachability).

• Fine for some properties, e.g. authentication of origin, but not for others, e.g., fairness.

• Often just an approximation, e.g., secrecy.• Really need ~non-interference.• What precisely is the approximation here?• Accept traffic analysis.• How safe is it?

7 June 2004DIMACS


33

Non-interference • Generalised, “possibilistic” formulation (PYAR, FOSAD

2000): tr, tr : traces(S)

tr ~ tr Abs(S/tr) Abs(S/tr ) denotes a suitable process equivalence, failures,

(weak)-bisimulation, testing, observational…• Abs Denotes an appropriate abstraction:

– Lazy/eager hiding, projection…• ~ is an appropriate equivalence over traces, traditionally

defined by:tr ~ tr purgeH(tr) = purgeH(tr )

• but more general equivalences are possible, e.g., under permutation of identities (anonymity).

7 June 2004DIMACS


34

Alternative formulation

U, U : ProcessesH U~U Abs(S||HU) Abs(S||H U)

• This seems rather elegant and appealing and appears to capture Wittbold and Johnson’s Non-deducibility on strategies (essentially the same as Gorrieri and Focardi’s NDC?).

• At first glance it seems to give an equivalent characterisation to the trace formulation given earlier, but actually weaker. Fails to distinguish different interleavings of H and L events.

7 June 2004DIMACS


35

Unification • Analogies between definitions of secrecy:• FM: (various flavours of ) process equivalence.• Crypto: (various flavours of) indistinquishability.• Note: FM definitions often assert equivalence as the

same level of abstraction. Crypto definitions usually assert simulation between levels of abstraction.

• Testing equivalence as adaptive, chosen plain/cipher-text attack?

• Lincoln, Mitchell2, Scedrov…• Bringing together crypto and FM approaches.• Composition results.

7 June 2004DIMACS


36

Novel Application Areas

• Group keying-unbounded protocols.• Key management modules.• Identity management.• E-voting

– Calls for novel properties:• Voter-verifiability.• Universal verifiability.

– Ensemble of protocols.• Quantum protocols and primitives?

7 June 2004DIMACS


37

Advances in tools

• Model checking:– Data independence– Parametric verification– Induction– Lazy evaluation– Partial order techniques

• Theorem proving• Hybrid

7 June 2004DIMACS


38

Novel techniques

• Protocol development techniques:• Refinement• Evolutionary algorithms• Automatic generation• Proof preserving transformations• Protocol interactions• Guessing attacks• Temporary secrets. Dynamic rank functions.

7 June 2004DIMACS


39

Conclusions • Scope to clarify existing goals, e.g., authentication.• Scope to create novel goals, applications and

environments.• Extend the power and scope of tools.• Need flexibility of models and tools.• Need to understand the roles of protocols in context

better.• Bridge the gap between crypto and FM communities.• The main challenge now is to turn all this into an

engineering discipline.

7 June 2004DIMACS


40

References • “Modelling and Analysis of Security Protocols” with S A

Schneider, A W Roscoe, G Lowe and M H Goldsmith. Pearson Education 2000.

• "Mathematical Modelling of Computer Security", chapter in Foundations of Security Analysis and Design (R.Focardi, R.Gorrieri eds), pp 1-62, volume 2172 of Lecture Notes in Computer Science, pp 1-62, Springer-Verlag 2001.

• A Logic of authentication, Burrows, Abadi, Needham. DEC report # 39, 1989

• On the security of public key protocols, Dolev, Yao, IEEE Trans ob Information Theory. 29(2), 1983

• Handbook of Applied Cryptography, A J Menezes, P C Van Oorschot, S A Vanstone, CRC Press 1996.

Formal Methods and Protocol Analysis

Documents

Transcript of Formal Methods and Protocol Analysis