1 / 23

TOWARDS A HIERARCHY OF CRYPTOGRAPHIC PROTOCOL MODELS

TOWARDS A HIERARCHY OF CRYPTOGRAPHIC PROTOCOL MODELS. Catherine Meadows Naval Research Laboratory Code 5543 Washington, DC 20375 Meadows@itd.nrl.navy.mil. HOW THIS TALK CAME ABOUT.

tayten
Download Presentation

TOWARDS A HIERARCHY OF CRYPTOGRAPHIC PROTOCOL MODELS

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  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

More Related