Formal Methods and Protocol Analysis Peter Y A

Formal Methods and Protocol Analysis Peter Y A Ryan University of Newcastle 7 June 2004 DIMACS P Y A Ryan Formal Methods and Protocol Analysis 1

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 2004 DIMACS P Y A Ryan Formal Methods and Protocol Analysis 2

BAN logic • P | X P “believes” X • P K Q 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 | (P K Q), P {X}K P | (Q|~ X) 7 June 2004 DIMACS P Y A Ryan Formal Methods and Protocol Analysis 3

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 2004 DIMACS P Y A Ryan Formal Methods and Protocol Analysis 4

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 2004 DIMACS P Y A Ryan Formal Methods and Protocol Analysis 5

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 2004 DIMACS P Y A Ryan Formal Methods and Protocol Analysis 6

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 2004 DIMACS P Y A Ryan Formal Methods and Protocol Analysis 7

Lowe attack on NSPK • A B: {A, na}PKb • B A: {na, nb}PKa • A B: {nb}PKa 7 June 2004 DIMACS • • • A Y : {A, na}PKy Y(A) B : {A, na}PKb B A[Y] : {na, nb}Pka Y A : {na, nb}PKa A Y : {nb}PKy Y(A) B : {nb}PKb P Y A Ryan Formal Methods and Protocol Analysis 8

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 2004 DIMACS P Y A Ryan Formal Methods and Protocol Analysis 9

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))= m And, where appropriate: E(k, D(k, m)) = m 7 June 2004 DIMACS P Y A Ryan Formal Methods and Protocol Analysis 10

Adversary Model • Adversary can construct terms using an inference system, e. g. : k, m |- {m}k, k-1 |- m (m, n) |- m m, n |- (m, n) m |- hash(m) 7 June 2004 DIMACS P Y A Ryan Formal Methods and Protocol Analysis 11

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 2004 DIMACS P Y A Ryan Formal Methods and Protocol Analysis 12

Syntax of CSP • • • a P P[]Q P Q P||XQ P|||Q PA P[R] S/tr P=F(P) 7 June 2004 DIMACS prefix external choice non-deterministic choice parallel composition over X interleave (= P||{}Q) hide events A renaming (relation R) S after trace tr. recursive definition P Y A Ryan Formal Methods and Protocol Analysis 13

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 nondeterminism. • Also operational semantics. 7 June 2004 DIMACS P Y A Ryan Formal Methods and Protocol Analysis 14

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 2004 DIMACS P Y A Ryan Formal Methods and Protocol Analysis 15

Trustworthy agents E. g. , Yahalom: 1. 2. 3. 4. A B: a, na B S: b, {a, nb}Ksb S A: {b, kab, na, nb}Ksa, {a, kab}Ksb A B: {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 2004 DIMACS P Y A Ryan Formal Methods and Protocol Analysis 16

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 2004 DIMACS P Y A Ryan Formal Methods and Protocol Analysis 17

The Adversary(X)= learn? a. b. m : messages Adversary(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 2004 DIMACS P Y A Ryan Formal Methods and Protocol Analysis 18

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 2004 DIMACS P Y A Ryan Formal Methods and Protocol Analysis 19

Properties • Authentication – Of origin. – Entity. – Injective. • • • Secrecy. (authenticated) key-exchange. Anonymity. Non-repudiation. Robustness (against Do. S attacks). Fairness. 7 June 2004 DIMACS P Y A Ryan Formal Methods and Protocol Analysis 20

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 2004 DIMACS P Y A Ryan Formal Methods and Protocol Analysis 21

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. m. Stop refinestraces System||send. a. b. m, recieves. a. b. m. Stop • 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 2004 DIMACS P Y A Ryan Formal Methods and Protocol Analysis 22

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 2004 DIMACS P Y A Ryan Formal Methods and Protocol Analysis 23

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 2004 DIMACS P Y A Ryan Formal Methods and Protocol Analysis 24

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 counterexamples which indicate attacks. • Drawback: models tend to blow up. Considerable ingenuity needed to cope with this. • Various compressions available, e. g. , chase. 7 June 2004 DIMACS P Y A Ryan Formal Methods and Protocol Analysis 25

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 nonexistence can be tricky, but (partially? ) automated now. • Note: links to Abadi et al’s typing approaches. 7 June 2004 DIMACS P Y A Ryan Formal Methods and Protocol Analysis 26

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 2004 DIMACS P Y A Ryan Formal Methods and Protocol Analysis 27

Extensions • • • Data-independence. Induction. Lazy compilation. Partial order. Simplifying transformations. Simple algebra, e. g. , Vernam encryption. 7 June 2004 DIMACS P Y A Ryan Formal Methods and Protocol Analysis 28

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 2004 DIMACS P Y A Ryan Formal Methods and Protocol Analysis 29

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 2004 DIMACS P Y A Ryan Formal Methods and Protocol Analysis 30

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 2004 DIMACS P Y A Ryan Formal Methods and Protocol Analysis 31

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 2004 DIMACS P Y A Ryan Formal Methods and Protocol Analysis 32

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 purge. H(tr) = purge. H(tr ) • but more general equivalences are possible, e. g. , under permutation of identities (anonymity). 7 June 2004 DIMACS P Y A Ryan Formal Methods and Protocol Analysis 33

Alternative formulation U, U : Processes. H U~U Abs(S||HU) Abs(S||H U ) • This seems rather elegant and appealing and appears to capture Wittbold and Johnson’s Nondeducibility 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 2004 DIMACS P Y A Ryan Formal Methods and Protocol Analysis 34

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/ciphertext attack? Lincoln, Mitchell 2, Scedrov… Bringing together crypto and FM approaches. Composition results. 7 June 2004 DIMACS P Y A Ryan Formal Methods and Protocol Analysis 35

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 2004 DIMACS P Y A Ryan Formal Methods and Protocol Analysis 36

Advances in tools • Model checking: – Data independence – Parametric verification – Induction – Lazy evaluation – Partial order techniques • Theorem proving • Hybrid 7 June 2004 DIMACS P Y A Ryan Formal Methods and Protocol Analysis 37

Novel techniques • • Protocol development techniques: Refinement Evolutionary algorithms Automatic generation Proof preserving transformations Protocol interactions Guessing attacks Temporary secrets. Dynamic rank functions. 7 June 2004 DIMACS P Y A Ryan Formal Methods and Protocol Analysis 38

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 2004 DIMACS P Y A Ryan Formal Methods and Protocol Analysis 39

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. 7 June 2004 DIMACS P Y A Ryan Formal Methods and Protocol Analysis 40