TOWARDS A HIERARCHY OF CRYPTOGRAPHIC PROTOCOL MODELS

1. TOWARDS A HIERARCHY OF CRYPTOGRAPHIC PROTOCOL MODELS • Catherine Meadows • Naval Research Laboratory • Code 5543 • Washington, DC 20375 • Meadows@itd.nrl.navy.mil

2. HOW THIS TALK CAME ABOUT • People who work in analysis of crypto protocols can make a variety of assumptions about the level of detail they want to model • Epistemic logic • Crypto models • All sorts of things in between • I personally usually work somewhere near the top story • Explicit model of attacker • Cryptosystems modeled in algebraic terms • A little more detail than most: cancellation properties of encryption modeled explicitly as rewrite rules • I’m often asked • Why do you choose the level you do? • What is the relationship with other levels? • Growing amount of research on these questions

3. STANDARD FORMAL MODEL FOR CRYPTO PROTOCOLS • Assume small number of operations available • Concatenation, encryption, digital signatures, etc. • Assume terms of well-defined types • Keys, data, names, nonces, etc. • Assume intruder with well-defined capacities as follows • Read traffic • Destroy traffic • Create or alter traffic using following: • Concatenation or decryption if knows components • Deconcatenation of concatenated data • Decryption if knows encrypted message and keys encrypted with

4. SOME UNSUPPORTED ASSUMPTIONS • Black box behavior of cryptosystems • Strong typing of data • Principal knows whether or not a datum is a random nonce, a key, a name, etc., without any help • System failures only coarsely modeled • Nodes either completely honest or completely dishonest • Usually don’t model compromise of keys, etc. • Usually don’t model intruders who will perform some actions but not others • No explicit model of decryption or checking of signatures • If principal knows message M encrypted with key K, an knows K, can produce key K • Don’t model application of decryption operator explicitly • Can’t model, e.g., application of decryption operator to unencrypted data • If principal knows message M signed with A’s private key, and A’s public key, then can verify M came from A • No explicit representation of verification function • Etc., etc., etc.

5. EXAMPLE OF ATTACK NOT COVERED • RSA public key cryptosystem Public key used for encryption, private key used for signing • Rewrite rules: • PKA(SKA(X)) --> X • SKA(PKA(X)) --> X • Rule for signing • If server asked to sign message X , then produces signed message SKS(X) • Suppose that somebody sends the server an encrypted message PKS(X) • Intruder intercepts and sends it to server as message to be signed • Server produces SKS(PKS(X)) = X • Can use protocol as oracle for decrypting encrypted messages • Standard free algebra model does not capture this kind of problem

6. BUT … • Common recommendations for good protocol hygiene rule out this kind of attack • Use different key pairs for signing and encryption • Sign hash of message instead of message itself MORAL • There are a number of attacks that go beyond the standard model for protocol security • Common (and syntactically checkable) recommendations for sound protocol design can prevent them CONJECTURE • There are commonly recommended and syntactically checkable conditions on crypto protocols that make a more abstract model sound with respect to a more detailed model • A number of different results bear this out

7. EMERGING WORK THAT ADDRESSES THIS • Cryptographic models • Mitchell, Scedrov, et al. • Probabilistic poly-time model • Incorporates crypto and logical elements • Abadi-Rogaway, Backes-Pfitzman-Waidner, Canetti, Warinschi • Develop crypto model and high-level model • Show that high-level model sound wrt. crypto model • Typing • Heather, Schneider, Lowe, • Strongly typed model and untyped model w. labels • Show typed model sound wrt labelled model • Explicit decryption operator/cancellation rules • Millen • Shows implicit decryption model sound wr. explicit encryption model if certain syntactic conditions hold • Lynch, Meadows • Similar results for public key • Limitations on intruder • Cervesato, Syverson, Meadows • Under certain circumstances, model in which intruder won’t reveal its own keys sound wrt to model in which it will

8. WHAT’S GOING ON HERE? • In many cases, able to construct • More abstract model, or model in which intruder has less power • More detailed model, or model in which intruder has more power • Show that, if certain conditions met, then certain statements true in more abstract model also true in more detailed model

9. WHAT CAN WE DO WITH THIS? • Aiming towards • Hierarchy of models • Collections of theorems saying that, if specification handles certain properties, then, for a certain class of statements, model X is sound with respect to model Y • When verifiying a protocol, pick the most abstract model that it is safe to use

10. WHAT KIND OF STATEMENTS CAN WE GUARANTEE SOUND? • Simplest case: secrecy • If an data item not learned by intruder in more abstract model, not learned in more detailed model • Simplest to formulate • Examples: • Abadi-Rogaway, Heather et al. • Safety properties for traces • If a trace containing a trace S as a subtrace can’t be found in the more abstract model, then can’t be found in the more detailed model • Usually related to secrecy properties • For an event to appear in a trace, must accept a certain type of message • E.g. A won’t send SA(B,NA) until she receives SB(A,NB) • Instead of proving system can’t produce secret, prove that it can’t produce expected message under certain conditions • Other properties?

11. WHAT KIND OF CONDITIONS CAN WE PUT ON SYSTEM • Best when simple syntactic conditions • Best when follow standard best practice • Heather, et. al for typing: • Each term in authenticated message preceded by label giving type • Similar to standard way of formatting messages, except • Each concatenation has its own “pair” tag • Message and term length not given • Millen for explicit decryption operator: • Explicit decryption not used in protocol spec • Corresponds to requirement that discard result of decryption unless it’s recognizable data • Encryption of variable term doesn’t appear in protocol spec • Corresponds to requirement that principal won’t encrypt term knows nothing about • Lynch and Meadows for public/private key encryption cancellation rules • Separate public/private key pairs for encryption and decryption • Case 1 • Encryption or signing of variable term doesn’t appear in protocol spec • No private key from an encryption pair of public key from a signing pair appears • Case 2 • Neither encryption or signing of variable or of term rooted in public key operator appears • Cervesato et. al Machiavellian intruder who doesn’t reveal long-term key: • Longterm keys don’t appear in protocol messages (encrypted or not)

12. CONDITIONS FOR BACKES, PFITZMANN, WAIDNER • Construct crypto library that can be used to implement provably security protocols • Conditions that must be satisfied • Randomized encryption • Two encrypted terms always different, even when same term is encrypted with same key • Guarantees that cancellation of encryption and decryption won’t occur unless intended • Randomized signatures • Tagging of data with type field • Signatures tagged with public key needed to verify them • Message can’t contain encrypted keys • All of the above conditions can be checked syntactically • Also a number of cryptographic conditions on cryptosystems themselves

13. ANOTHER SUGGESTION -- SESSION KEY COMPROMISE • Standard model does not include compromise of session key, but consider Needham-Schroder shared key protocol • 1.  A -> S :  A, B, Na • 2.  S -> A :  {Na, B, Kab, {Kab, A}Kbs}Kas • 3.  A -> B :  {Kab,A}Kbs • 4.  B -> A :  {Nb}Kab • 5.  A -> B :  {Nb -1}Kab • Suppose that old Kab’ learned by intruder • 3.  IA -> B :  {Kab’,A}Kbs • 4.  B -> IA :  {Nb}Kab’ • 5.  IA -> B :  {Nb -1}Kab’

14. HOW TO GUARANTEE SOUNDNESS? • Want to show protocol spec w/o key compromise is sound wrt protocol spec with key compromise • What seems to open up protocol to vulnerability to key compromise is that session key is used in protocol for authentication • Conjecture: if session key not used for authentication in the protocol used to distribute it, then no need to model key compromise • Not quite a syntactic condition: how to you tell a session key is being used for authentication? • For example, suppose I send you a message encrypted with your public key, and include session key in it • You could conclude message is from me because session key is in it • *Not* a reccomended method of authentication, by the way • Or, it could just be a means of getting the session key to you

15. MORE TRIES AT A SYNTACTIC CONDITION • Try this • Session key never used in authentication operator (e.g. message authentication code) in protocol run • Session key never used for encryption in protocol run • Session key sent only once in protocol run • Would seem to guarantee session key not used for authentication, but too restrictive • Next try: • If session key used to authenticate or encrypt message, that message is also authenticated with long-term key • Corresponds with Station-to-Station protocol and its descendants such as IKE • If session key appears in body of message, that message authenticated with long-term key • This seems to work • If include assumption that authenticators checked by recipients whenever possible, becomes simple syntactic condition on protocol messages

16. SOME OTHER MODELS TO LOOK AT • System size • Number of executions • Number of parallel executions • Size of messages -- bounded or unbounded • Much of this already examined • Intruder model • Other limitations on intruder besides unwillingness to share keys • Economic models of intruders • When does it pay to act like Dolev-Yao intruder? • Combinations of different types of intruders • Environmental model • What kinds of protocols is the protocol expected to interact with • Representing system failures • Compromise of master keys • Compromise of other secrets • What other system failures?

17. COMBINING THIS ALL INTO A HIERARCHY • Work now usually concentrates on maintaining a flat hierarchy: • When does more expressive model implement the most abstract possible model • Usually Dolev-Yao with free algebra • Sometimes might make sense to use intermediate model • Example: protocol secure against guessing attacks would probably not be able to make use of strong typing • Want to be able to prove it secure without going all the way down to the cryptographic level • Example: protocol that makes explicit use of timing or probabilistic behavior, probably would not be able to abstract these away • Example:, protocol might satisfy conditions for ruling out key compromise, but not for implicit decryption, or vice versa? • Consider a protocol that makes use of implicit decryption and cancellation rules, but never uses session key for authentication • Example: a protocol that satisfies rules for implicit decryption for shared key, but not for public key • Would be more efficient to analyze for hybrid implicit/cancellation model rather than using all cancellation rules

18. EXAMPLE OF AN INTERMEDIATE MODEL (Lynch and Meadows) • Diffie-Hellman -- based on difficulty of discrete logarithms • A --> B: XNA mod P B computes XNA*NB • B --> A: XNB mod P A computes XNB*NA • Because of commutativity of exponentiation, A and B share a secret • But, commutativity expensive to reason about • In systems based on unification, number of mgu’s is exponential in number of exponents • Replace by rewrite rules • Exponentiation not commutative • Initiator applies transformation h1, responder applies h2 • h1(XNA*NB) = h2(XNB*NA) • “commutativity only where you need it”

19. WHAT CAN’T REWRITE RULE MODEL CAPTURE? • Suppose intruder tricks two initiators into talking to each other, each one thinking that the other is a responder • In commutative model • A computes XNA*NB • B computes XNB*NA) = XNA*NB • In rewrite rule model • A computes h1(XNA*NB) = h2(XNB*NA) • B computes h1(XNB*NA) = h2(XNA*NB) • Solution: put syntactic conditions on protocol that guarantee the initiator and responder messages can’t be confused

20. SOME OPEN QUESTIONS ABOUT INTERMEDIATE MODELS • What are the best ways of constructing these intermediate models? • Will there by standard ways of generating them? • How do we deal with the fact that cryptographic best practice (on the most detailed level) seems best to support the most abstract models • Probabilistic cryptosystems support free algebra model • Tagging data supports strong typing • What cryptographic primitives (if any) support intermediate models? • How to organize the hierarchy

21. AN OBSERVATION ABOUT ORGANIZATION • Commonly, more abstract models thought of in terms of equivalence relations on more concrete models • For crypto protocol models, free algebra, at the top of the abstraction hierarchy, has no equivalence relations • Equivalence relations introduced as you proceed downwards in the hierarchy • From free algebra to rewrite rules • From rewrite rules to commutative rules • From strong typing to type confusion • Can we make use of this duality?

22. CONCLUSION • Have outlined a theory for cryptographic protocol analysis based on hierarchy of models • Showed how different work by different people in different areas takes a common approach • Question: What’s the best way this can all be brought together to give a usable hierarchy?

23. REFERENCES • M. Abadi and P.l Rogaway, Reconciling Two Views of Cryptography (The Computational Soundness of Formal Encryption) Journal of Cryptology 15, 2 (2002), 103-127. Available at http://www.cse.ucsc.edu/~abadi/allpapers.html#jsds • M. Backes, B. Pfitzmann, M. Waidner: A Composable Cryptographic Library with Nested Operations; 10th ACM Conference on Computer and Communications Security (CCS), Oct 2003. Long version: IACR ePrint Archive, Report 2003/015, Jan. 2003, http://eprint.iacr.org/, short version available at http://www.zurich.ibm.com/security/publications/2003.html • I. Cervesato, C. Meadows, and P. Syverson. Dolev-Yao is no better than Machiavelli, First Workshop on Issues in the Theory of Security - WITS'00 (P. Degano, editor), Geneva, Switzerland, 8-9 July 2000. Available at http://theory.stanford.edu/~iliano/byYear.htm • J. Heather, G. Lowe, S. Schneider. How to avoid type flaw attacks on security protocols, Proceedings of the 13th IEEE Computer Security Foundations Workshop, June 2000 • C. Lynch and C. Meadows, “On the relative soundness of the free algebra model for public key encryption,” Workshop on Issues in the Theory of Security ‘04, April 2004. • C. Lynch and C. Meadows, “Sound approximation to Diffie-Hellman using rewrite rules,” submitted for publication • Jonathan Millen, On the freedom of decryption, Information Processing Letters, 86(6), June 2003, pp. 329-333. Availableat http://www.csl.sri.com/users/millen/capsl/ • J.C. Mitchell, A. Ramanathan, A. Scedrov, V. Teague, A probabilistic polynomial-time calculus for the analysis of cryptographic protocols, submitted for publication, available at http://theory.stanford.edu/people/jcm/publications.htm