Embed Size (px)
Citation preview
1
TOWARDS A HIERARCHY OF TOWARDS A HIERARCHY OF CRYPTOGRAPHIC PROTOCOL MODELSCRYPTOGRAPHIC PROTOCOL MODELS
TOWARDS A HIERARCHY OF TOWARDS A HIERARCHY OF CRYPTOGRAPHIC PROTOCOL MODELSCRYPTOGRAPHIC PROTOCOL MODELS
Catherine MeadowsNaval Research Laboratory
Code 5543Washington, DC 20375
2
HOW THIS TALK CAME ABOUTHOW THIS TALK CAME ABOUTHOW THIS TALK CAME ABOUTHOW 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 STANDARD FORMAL MODEL FOR CRYPTO PROTOCOLSCRYPTO PROTOCOLS
STANDARD FORMAL MODEL FOR STANDARD FORMAL MODEL FOR CRYPTO PROTOCOLSCRYPTO 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 ASSUMPTIONSSOME UNSUPPORTED ASSUMPTIONSSOME UNSUPPORTED ASSUMPTIONSSOME UNSUPPORTED ASSUMPTIONS
Black box behavior of cryptosystemsStrong 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
othersNo 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 COVEREDEXAMPLE OF ATTACK NOT COVEREDEXAMPLE OF ATTACK NOT COVEREDEXAMPLE 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)) = XCan use protocol as oracle for decrypting encrypted messages
Standard free algebra model does not capture this kind of problem
6
BUT …BUT …BUT …BUT …
Common recommendations for good protocol hygiene rule out this kind of attack1. Use different key pairs for signing and encryption2. 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 themCONJECTURE
• 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 EMERGING WORK THAT ADDRESSES THISTHIS
EMERGING WORK THAT ADDRESSES EMERGING WORK THAT ADDRESSES THISTHIS
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 modelExplicit 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 keyLimitations 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?WHAT’S GOING ON HERE?WHAT’S GOING ON HERE?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
powerShow 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?WHAT CAN WE DO WITH THIS?WHAT CAN WE DO WITH THIS?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 WHAT KIND OF STATEMENTS CAN WE GUARANTEE SOUND?WE GUARANTEE SOUND?
WHAT KIND OF STATEMENTS CAN WHAT KIND OF STATEMENTS CAN WE GUARANTEE SOUND?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 WHAT KIND OF CONDITIONS CAN WE PUT ON SYSTEMPUT ON SYSTEM
WHAT KIND OF CONDITIONS CAN WE WHAT KIND OF CONDITIONS CAN WE PUT ON SYSTEMPUT ON SYSTEM
Best when simple syntactic conditionsBest when follow standard best practiceHeather, 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, CONDITIONS FOR BACKES, PFITZMANN, WAIDNERPFITZMANN, WAIDNER
CONDITIONS FOR BACKES, CONDITIONS FOR BACKES, PFITZMANN, WAIDNERPFITZMANN, 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 ANOTHER SUGGESTION -- SESSION KEY COMPROMISEKEY COMPROMISE
ANOTHER SUGGESTION -- SESSION ANOTHER SUGGESTION -- SESSION KEY COMPROMISEKEY COMPROMISE
Standard model does not include compromise of session key, but consider Needham-Schroder shared key protocol
1. A -> S : A, B, Na2. S -> A : {Na, B, Kab, {Kab, A}Kbs}Kas3. A -> B : {Kab,A}Kbs4. B -> A : {Nb}Kab5. A -> B : {Nb -1}Kab
Suppose that old Kab’ learned by intruder
3. IA -> B : {Kab’,A}Kbs4. B -> IA : {Nb}Kab’5. IA -> B : {Nb -1}Kab’
14
HOW TO GUARANTEE SOUNDNESS?HOW TO GUARANTEE SOUNDNESS?HOW TO GUARANTEE SOUNDNESS?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 MORE TRIES AT A SYNTACTIC CONDITIONCONDITION
MORE TRIES AT A SYNTACTIC MORE TRIES AT A SYNTACTIC CONDITIONCONDITION
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 keyThis 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 ATSOME OTHER MODELS TO LOOK ATSOME OTHER MODELS TO LOOK ATSOME 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 COMBINING THIS ALL INTO A HIERARCHYHIERARCHY
COMBINING THIS ALL INTO A COMBINING THIS ALL INTO A HIERARCHYHIERARCHY
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 EXAMPLE OF AN INTERMEDIATE MODEL (Lynch and Meadows)MODEL (Lynch and Meadows)
EXAMPLE OF AN INTERMEDIATE EXAMPLE OF AN INTERMEDIATE MODEL (Lynch and Meadows)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 exponentsReplace 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 WHAT CAN’T REWRITE RULE MODEL CAPTURE?CAPTURE?
WHAT CAN’T REWRITE RULE MODEL WHAT CAN’T REWRITE RULE MODEL CAPTURE?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 SOME OPEN QUESTIONS ABOUT INTERMEDIATE MODELSINTERMEDIATE MODELS
SOME OPEN QUESTIONS ABOUT SOME OPEN QUESTIONS ABOUT INTERMEDIATE MODELSINTERMEDIATE 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 AN OBSERVATION ABOUT ORGANIZATIONORGANIZATION
AN OBSERVATION ABOUT AN OBSERVATION ABOUT ORGANIZATIONORGANIZATION
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
CONCLUSIONCONCLUSIONCONCLUSIONCONCLUSION
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
REFERENCESREFERENCESREFERENCESREFERENCES
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
