Recent Methods and Problems in Authentication Protocol Analysis

1. Recent Methods and Problems inAuthentication Protocol Analysis Jonathan Millen SRI International Menlo Park, CA, USA millen@csl.sri.com WADIS '03 December 6, 2003

2. Outline • Background • What is cryptographic protocol analysis • Why is it a hard problem • Overview of analysis approaches • Recent Work • Strand spaces • Digression - group management protocol analysis • The constraint solver • Continuing research problems

3. Resources • CAPSL Web Site • www.csl.sri.com/users/millen/capsl • Bibliography • capsl/protsec.bib (references like [AB99]) • Clark-Jacob Library • www.cs.york.ac.uk/security/Publications.html • capsl/library.html • SPORE Library (Comon) • www.lsv.ens-cachan.fr/spore • Constraint solver tutorial and Prolog code • capsl/constraints.html • Ryan-Schneider text, Crypto. Protocol Analysis: CSP

4. Cryptosystems • Cryptosystem: algorithm for encrypting plaintext into ciphertext, and decrypting, using keys. • Cryptographic protocol: exchange of messages for distributing keys or applying a cryptosystem to data. • Symmetric-key cryptosystem: the same key is used for encrypting and decrypting. • Examples: DES, IDEA, Skipjack, Blowfish, RC4, AES (Rijndael) • Public-key cryptosystem: different keys are used for encrypting and decrypting. The encryption key may be made public. • Examples: RSA, El Gamal, Elliptic curve • Diffie-Hellman (key agreement)

5. Cryptographic Protocols • For key distribution: provide two parties with keys suitable for private or authenticated communication • For authentication: to provide one party with assurance that a message was sent by another party in the same session. • For other purposes: fair exchange, auctions, voting,… • Examples • SSL - in browsers (now TLS) • Kerberos - remote unitary login • EKE, SRP - password based • Cybercash - electronic commerce • IKE, ISAKMP, JFK – by IETF • New ones are continually proposed

6. The Security Threat:Active Attacker Attacker can: -intercept all messages -modify addresses and data Attacker cannot: -encrypt or decrypt without the key

7. Protocol Vulnerabilities - Ground Rules • "Attacker" synonyms: • intruder, spy, saboteur, penetrator, enemy, adversary • Attacker can intercept any message • Ability to read, record, misdeliver any message • Method: sniffers, and intrusions in firewalls or routers • Attacker can introduce new messages • Construct messages using primitive operations • Falsify (unencrypted) source, destination addresses • Strong encryption assumption: an attacker cannot decrypt any message without the key. • Attacker is a legitimate network user with a name, key, etc. • Other users follow the protocol • This is often called the “Dolev-Yao” model [DY83]

8. Example - Needham-Schroeder • The Needham-Schroeder symmetric-key protocol [NS78] • A  S: A, B, Na • S  A: {Na, B, Kc, {Kc, A}K(B) }K(A) • A  B: {Kc, A}K(B) • B  A: {Nb}Kc • A  B: {Nb-1}Kc • A, B are “principals;” S is a trusted key server • K(A) is a secret key shared by A and S • {X, Y}K means: X concatenated with Y, encrypted with K • Na, Nb are “nonces;” fresh (not used before) • Kc is a fresh connection key • Denning-Sacco replay attack in 1981 [DS81]

9. Denning-Sacco Attack • Assume that the attacker has recorded a previous session, and compromised the connection key Kc used in that session. • … first part omitted • A  B: {Kc, A}K(B) attacker replay of old message • B  A: {Nb}Kc • A  B: {Nb-1}Kcforged by attacker • B now believes he shares a fresh secret key Kc with A. • Denning-Sacco moral: use a timestamp (calendar clock value) to detect replay of old messages. • Better use of nonces could also work

10. Folklore - Attack Terms • Replay: record and later re-introduce a message or part • Masquerading: pretending to be another party • Forge source address • Man-in-the-middle: pass messages through to another session A  X  B • Oracle: take advantage of normal protocol responses as encryption and decryption “services” • Type confusion: substitution of a different type of message field (e.g., key vs. nonce) • Parallel attack: takes advantage of two or more concurrent protocol runs of the same role, different sessions

11. Design Principles • Abadi-Needham “prudent engineering practice” paraphrased • See [AN94]; also Anderson and Needham [AN95] • 1. Every message should say what it means. • 2. The conditions for a message to be acted on should be clearly set out. • 3. Mention the principal’s name explicitly in the message if it is essential to the meaning. • 4. Be clear as to why encryption is being done. • 5. Don’t assume a principal knows the content of encrypted material that is signed by that principal. • 6. Be clear on what properties you are assuming about nonces. • 7. Predictable quantities used for challenge-response should be protected from replay.

12. More Design Principles • 8. Timestamps must take into account local clock variation and clock maintenance mechanisms. • 9. A key may have been used recently, yet be old. • 10. If an encoding is used to present the meaning of a message, then it should be possible to tell which encoding is being used. • 11. The protocol designer should know which trust relations his protocol depends on. • Good advice, but… • Are you sure when you have followed all of them? • Is the protocol guaranteed to be secure then? • Is it optimal and/or minimal?

13. Formal Methods Crypto Protocol Analysis Formal Models Computational Models Dolev-Yao (ideal encryption) Probabilistic poly-time Random oracle (bit leakage) Belief Logics Model Checking Inductive Proofs State space exploration Specialized or general-purpose tools By hand or using verification tools BAN logic GNY, SvO, ... Authentication, Nonrepudiation

14. Why Protocol Analysis is Hard

15. Protocol Analysis is Undecidable • Several proofs • First undecidability proof by Even & Goldreich, [EG83] • Simpler use of Post Correspondence problem by Heintze & Tygar, [HT96] • Undecidability comes from unboundedness in the model • Number of protocol instances (runs, sessions) is unbounded • Messages from attacker are unbounded in structural depth • Number of possible values for some data fields is infinite

16. BAN Logic • Papers • Burrows, Abadi, Needham, “A logic of authentication,” ACM Trans. Computer Systems 8(1), 1990 (also DEC SRC Research Rpt 39) • Subsequent extensions, e.g., GNY logic • Gong, Needham, Yahalom, “Reasoning about belief in cryptographic protocols,” 1990 IEEE Symposium on Security and Privacy • Approach • Modal logic of belief plus specialized predicates and inference rules • Example: B believes A said (K is fresh) • Example: if A shares K with B and B sees {X}K then A said X • Protocol messages are “idealized” into logical statements • Objective is to prove that both parties share common beliefs • Logic of “authentication” • Elegant, popular

17. The Problem with BAN • Nessett noted problem [Nes90] • A  B: {T, K}KA-1 • Shared key K given away by encryption with private key of pair • A can still believe A shares K with B • Secrecy failures may be subtle • Secrecy analysis must be prior to authentication proof • Prove that good keys or shared secrets are not compromised during the protocol (due to an attack) • Logics like this address authentication, must use other techniques to verify confidentiality where assumed/needed

18. Early Specialized Model Checkers • Interrogator [MCF87, Mil95] • Prolog program • Backward state search for attack from goal state pattern • No guarantee of completeness or termination • NRL Protocol Analyzer [Mea91, Mea96a] • Prolog program • Backward state search, plus • Generation of "unreachable" languages • No guarantee of completeness or termination • Can sometimes prove a protocol correct

19. General-Purpose Model CheckerApplications • Application of software tools designed for hardware CAD • Verification by state space exploration - exhaustive on model • Like earlier Prolog tool approach, but • Special algorithms (BDD, SAT, etc.) • Require finite model • bounds on number of sessions, message structure, etc. • Fully automatic once protocol is encoded • Researchers: • Roscoe [Ros95], using FDR (the first) • Mitchell, et al, using Murphi [MMS97] • Marrero, et al, using SMV [MCJ97] • Denker, et al, using Maude [DMT98] • … and more

20. Model-Checking Observations • Very effective at finding flaws, but • No guarantee of correctness, due to artificial finite bounds • Bound on message structure depth later found unnecessary • Setup and analysis is quick when done by experts • Automatic translation from simple message-list format to model-checker input is possible [Lowe's Casper: Low98a] • Successful example: Lowe attack on Needham-Schroeder public-key protocol, using FDR [Low96]

21. Lowe Small-System Result • Theorem: if Assumptions 1-6 (below) are satisfied, then any secrecy breach can be demonstrated in a “small system” with only one instance of each role. [Low98b] • Functions that return keys are one-to-one (no key coincidence) • All short-term secrets are fresh • No long-term keys are (normally) sent (as data) in messages • Encrypted message components mention all roles • Encrypted message components are textually distinct • No temporary secrets (secrets must not be revealed after use) • Example: (Davis-Swick) • A  B: {B,T}sk(A,B) • B  A: {T,A}sk(B,A) • This satisfies the assumptions if • sk(A,B)  sk(B,A) (for 1) • T is a recognizably different type from principal (for 5)

22. Recent Specialized Methods • Athena • Song/Berezin/Perrig [SBP01] • ML program • Uses strand-space model (free algebra, atomic keys) • Special-purpose model checker • Very fast • Usually terminates, no fixed bound • Bounded-Process Decidable • Bounded set of legitimate processes • Decidable despite no bound on message term complexity • Shown NP-complete by Rusinowitch/Turuani [RT01] • Constraint solver is in this category

23. Inductive Proofs • Approach: like proofs of program correctness • Induction to prove “loop invariant” • State-transition model, objective is security invariant • General-purpose specification/verification system support • Kemmerer, using Ina Jo and ITP [Kem89] (the first) • Paulson, using Isabelle [Paul98] (the new wave) • Dutertre and Schneider, using PVS [DS97] • Bolignano, using Coq [Bol97] • Can also be done manually • Schneider, using CSP [Sch98] • Thayer et al, using Strand Spaces [THG98] • Spi calculus proofs (Abadi, Gordon, ...) • Full guarantee of correctness (with respect to model) • No bounds imposed • Proofs include secrecy • But they are usually hard work

24. Strand Spaces • Thayer, Herzog, Guttman [THG98] • Message: ground term in free algebra • over symbolic constants, with pairs and encryption • Message does not include "A  B" header • Strand: sequence of nodes Node is labeled with +/- message • Bundle: causal partial ordering of nodes in strands Penetrator strands, for primitive operations Examples: Example: NSPK “A” strand “B” strand +{n,a}kb -{n,a}kb x {x}k -{n,r}ka +{n,r}ka y k-1 +{r}kb {x,y} x Penetrator strands are universal

25. Bundles • A bundle combines strands into a partial ordering • Nodes are ordered by internal strand sequence • Nodes are also ordered by message delivery • Bundles are backward complete • Non-initial nodes have predecessor in strand • Every received message must have been sent {n,a}kx kx-1 Example: NSPK attack {n,r}ka {n,a} {r}kx kb {n,a}kb {n,r}ka

26. Parametric Strand Specification Suggested by [Son99] and [CDLMS00] A-role strand "A"(A,B,Na,Nb) Na is a nonce generated by "A" roles A, B, Na, Nb (initial capitals) are variables Addresses lost Protocol +{A,Na}pk(B) A  B: {A,Na}pk(B) B  A: {Nb,Na}pk(A) A  B: {Nb}pk(B) -{Nb,Na}pk(A) +{Nb}pk(B) There's also a B-role strand Semibundle: incomplete bundle, partially instantiated strands

27. Example Spec • Yahalom protocol "A"(A,B,S,Na,Nb,K) = • + {A,Na} • – {{B,K,Na,Nb}sk(A),{Nb}K} "B"(A,B,S,Na,Nb,K,T) = • – {A,Na} • + {B,{A,Na,Nb}sk(B)} • – {T,{A,K}sk(B)} • + {T,{Nb}K} "S"(A,B,S,Na,Nb,K) = • – {B,{A,Na,Nb}sk(B)} • + {{B,K,Na,Nb}sk(A),{A,K}sk(B)} A  B: A, Na B  S: B,{A,Na,Nb}sk(B) S  B: {B,K,Na,Nb}sk(A), {A,K}sk(B) B  A: {B,K,Na,Nb}sk(A), {Nb}K Term T encrypted for A is just passed on

28. Characteristics of Spec Style • Keys may be constructed • Symmetric key may be any term, not just constants • Public keys constructed with pk(A) • Secret keys sk(A) assumed to be shared with server • Free term algebra (no term reductions or relations) • Advantage: WYSIWYG simplicity • Can't specify decryption explicitly in protocol spec • Some loss of generality (EV-freedom discussion) • Untyped • Advantage or disadvantage? • Typing can be simulated with type-coercion functions • Don’t yet handle commutative operations (xor, exponentiation)

29. Free Term Algebra Question Suppose that a protocol is expressible (in parametric strand style) using a free term algebra to represent encryption. (Write e(X,K) for {X}K so we can introduce d(X,K) below) Example strand: S(A,B,X,K) = -e({X,A},K) +e({X,B},K) Assume that the attacker can perform decryption transformations as usual, such as: e(X,K), K  X Can new attacks be discovered by adding an explicit decryption operator with cancellation relations? d(e(X,K),K)  X e(d(X,K),K)  X

30. Counterexample “A” strand “B” strand -e(e(X,c),k) +e(s,k) +X Assumptions: s is a secret constant k is a secret key c is a compromised key X is a variable Observation: if e(s,k) is acceptable as e(e(X,c),k) then s = e(X,c) and X = d(s,c) so the attacker can get s. A free term algebra can't see this.

31. Remarks What's missing: ability to decrypt something that was not encrypted Generality is restored if e(X,K) is disallowed for any variable X Spec is "EV-free" if this restriction is satisfied (OK to have X in context, e.g., e({X,a},K)) "On the freedom of decryption," Millen, IPL 86(2003) All this applies to public key encryption too (Lynch) Why use free term algebra model? Analysis advantages: efficient constraint solving, proof of completeness and termination EV-freedom is realistic But free algebras still can't handle group management protocols...

32. Multicast Group Management • Multicast group members share a group key • A suite of protocols is used to perform different tasks • Addition of a new member to the group (rekey) • Deletion of a member from the group (rekey) • Merge two groups or split one into two • Distribute new group key • Application-dependent tasks • Different methods for key distribution • Group Diffie-Hellman, key hierarchy, … • Secrecy objectives • Backward access control: new members can't read old messages • Forward access control: deleted members can't read new messages

33. Group Diffie-Hellman Steiner-Tsudik-Waidner 1996 Finite-field arithmetic; uses exponentiation mod p Constant base g for exponentiations r1, r2, etc. are private random contributions Last party (M3 in this example) multicasts Group key gr1r2r3 computed by each party "upflow" gr2,gr1,gr1r2 g,gr1 M1 M2 M3 gr2r3,gr1r3 "downflow"

34. Need for Authentication • Attacker can misdeliver upflow message as downflow • Party computes wrong group key, something public • This is a problem for two-party Diffie Hellman also • First attempt at solution: AGDH (Authenticated) • Assume pairwise shared keys • Include key with downflow terms • gr2r3k13,gr1r3k23 • Insufficient: Pereira-Quisquater attack [PQ01] M1 g,gr1 Attacker g,gr1 M1 computes group key as gr1

35. Pereira-Quisquater Attack M2 M4 g,gr1 gr2,gr1,gr1r2 _,gr2,gr2,_ _,gr2r4k24,gr2r4k34 M3 gets gr2r4 Second round, M3 (malicious) has been deleted M2 g,gr2r4 gs2,gr2r4,gr2r4s2 s2 is new private contribution from M2 _,gr2r4k24 M2 computes new group key as gr2r4s2 (compromised) The analysis technique has not yet been put into tools.

36. Bounded-Process Decidable Case Crypto Protocol Analysis Formal Models Computational Models Dolev-Yao (ideal encryption) Probabilistic poly-time Random oracle (bit leakage) Belief Logics Model Checking Inductive Proofs Finite-state Bounded-process decidable Antti Huima, 1999 Symbolic states (extended abstract) Inspired subsequent work: Amadio-Lugiez Boreale Fiore-Abadi Rusinowitch-Turuani (NP-complete) Millen-Shmatikov Basin

37. Constraint Solving • Millen-Shmatikov [MS01] • Bounded-process decidable • Two-phase approach • Use the protocol spec to generate algebraic "constraint" sets • Use inference rules to solve constraint sets

38. Constraint Solving • Parametric strand specification for protocol • Choose N strand instances (small N) • Enumerate possible node orderings (strand interleavings) • Generate a constraint set for each ordering • Solve constraint set (finds attack) or prove unsolvable (N-secure) • No attack in any constraint set with N? Try N+1

39. Example Spec • NSPK protocol • "A"(A,B,Na,Nb) = • + {A,Na}pk(B) • – {Na,Nb}pk(A) • + {Nb}pk(B) • "B"(A,B,Na,Nb) = • – {A,Na}pk(B) • + {Na,Nb}pk(A) • – {Nb}pk(B) A  B: {A,Na}pk(B) B  A: {Na,Nb}pk(A) A  B: {Nb}pk(B) Caution: variable scope is local to a strand. The "A" strand value of A is not necessarily equal to the "B" strand value of A (in a bundle).

40. ma1 a1 mb1 ma2 b1 a2 mb2 ma3 b2 a3 mb3 b3 Choose Strand Instances A-role instances B-role instances Secrecy test strand ma1 mb1 s ? a1 b1 s is the secret If a bundle exists with this strand, s is compromised ma2 mb2 a2 b2 ma3 mb3 a3 b3 Zero, one, two, or more instances per role (not necessarily the same)

41. Constraint Set Generation 1. Enumerate all linear node orderings consistent with strands +ma1 -mb1 -m'b1 a1 b1 b'1 -ma2 +mb2 +m'b2 a2 b2 b'2 +ma3 -mb3 -m'b3 a3 b3 b'3 a1 b1 b'1 b'2 b2 a2 a3 b3 b'3 with message ordering +ma1 -mb1 -m'b1 +m'b2 +mb2 -ma2 +ma3 -mb3 -m'b3

42. Phase I: Constraint Set Generation 2. One constraint for each received message +ma1 -mb1 -m'b1 +m'b2 +mb2 -ma2 +ma3 -mb3 -m'b3 mb1: ma1 m'b1: ma1 ma2: ma1,m'b2,mb2 mb3: ma1,m'b2,mb2,ma3 m'b3: ma1,m'b2,mb2,ma3 Constraint m1: m2, m3, … means that m1 is derivable using available operations (by the attacker) from the messages m2, m3, … and from constants known to the attacker. These are term closure constraints.

43. Derivation Constraint Example A  B: A original protocol "A"(A) = +A; "B"(A) = -A strand spec {+a, -A} semibundle +a -A interleaving A: a the constraint

44. How Many Interleavings? • For two strands of sizes m and n nodes, there are choose(m+n,n) different orderings (binomial coefficient) • Send optimization: +m1, -m2,… has at least as many solutions as -m2, +m1, … Therefore always choose send nodes first (order doesn't matter) • Common path optimization (Corin, Etalle) • Constraint differentiation (Basin, et al. ACM CCS '03)

45. Common Path Optimization • Node orderings have common initial subsequences • Unsolvability of initial subsequence implies unsolvability of extensions • Test solvability at every step to avoid fruitless extensions • Implementation by Corin and Etalle, U. Twente, Holland • Significant speed improvement A +a1 -a2 +a3 -a4 B -b1 +b2 -b3 +a1-b1 +b2 -a2 +a3 -b3-a4 Failure at a2 eliminates second sequence +a1-b1+b2 -a2 +a3-a4-b3

46. Phase II: Constraint Set Solution Initial constraint set apply every possible transformation rule to firstm:Twheremis not a variable • • • • • • No rule is applicable var1 : T1 • • • varN : TN or Simple set: always satisfiable!

47. Some Transformation Rules Synthesis Analysis Other {x, y} : T ––––––– (pair) x : T y : T x : {y, z},T –––––––– (split) x : y, z, T x : z, T –––––– (unify)  unifies x, z partial solution {x}y : T –––––– (senc) x : T y : T x : {y}z, T ––––––––– (sdec) z : [{y}z], T x : y, z, T x : v, T –––––– (elim) x : T if v is a variable T is any set of terms [{y}z] is a marked encryption to prevent rule looping (elim) rule based on origination, monotonicity properties

48. Example CS Run in Prolog semibundle([Sa,Sb,St]) :- strand(roleA,A,B,na,Nb,Sa), strand(roleB,A,B,Na,nb,Sb), strand(test,nb,St). ?- semibundle(B),search(B,[]). Trace: recv([a,e]) send([a,na] * pk(e)) recv([a,na] * pk(b)) send([na,nb] * pk(a)) recv([na,nb] * pk(a)) send(nb * pk(e)) recv(nb * pk(b)) recv(nb)

49. AVISPA Tools and Interface AVISPA members ETH Zurich On-the-fly model checker (OFMC) constraint solver INRIA/CASSIS CASRUL (CL) U. Genova (SAT) model checker Also Siemens AG Spec in High Level Protocol Spec Language; three analyzers

50. Some New Directions • Extension of decidable protocol analysis to (group) Diffie-Hellman and other associative-commutative operations • At SRI and independently at INRIA • Application of type theory to authentication protocol proofs • Type-safe implies attacker-unsafe; dependent types • Abadi-Blanchet, Debbabi-Mejri, Jeffrey • Derivation/composition of secure protocols • Datta-Derek-Mitchell-Pavlovic • Composition/transformation/refinement of functional components • Proof rules based on cord calculus (something like strand space) • Use of computationally ideal crypto primitives • Backes-Pfitzmann-Waidner (IBM Zurich) • Special crypto interface with implementation proved "ideal" • Can we use these operations for Dolev-Yao analysis?