Formal Methods and Protocol Analysis

1. Formal Methods and Protocol Analysis Peter Y A Ryan University of Newcastle P Y A Ryan Formal Methods and Protocol Analysis

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,…) P Y A Ryan Formal Methods and Protocol Analysis

3. 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) P Y A Ryan Formal Methods and Protocol Analysis

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

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

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

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

8. AB: {A, na}PKb BA: {na, nb}PKa AB: {nb}PKa 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 Lowe attack on NSPK P Y A Ryan Formal Methods and Protocol Analysis

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

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

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

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

13. Syntax of CSP • aP 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 P Y A Ryan Formal Methods and Protocol Analysis

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

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

16. Trustworthy agents E.g., Yahalom: • AB: a, na • BS: b, {a, na, nb}Ksb • SA: {b, kab, na, nb}Ksa, {a, kab}Ksb • AB: {a, kab}Ksb, {nb}Kab A, initiators view: • A sends b: a, na • A receives: {b, kab, na, nb}Ksa, {a, kab}Ksb • A sends b: {a, kab}Ksb, {nb}Kab P Y A Ryan Formal Methods and Protocol Analysis

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

18. The Adversary 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. P Y A Ryan Formal Methods and Protocol Analysis

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

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

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

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

23. Anonymity • Can be formulated as the invariance, from an appropriate viewpoint, of the system under arbitrary permutations over the anonymity set, A say: AAbs(System) tracesAbs((System)) • Various abstraction operators available: eager or lazy hiding, projection (renaming) etc. P Y A Ryan Formal Methods and Protocol Analysis

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

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

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

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

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

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,…) P Y A Ryan Formal Methods and Protocol Analysis

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

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

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

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

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

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

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

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

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

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

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