TOWARDS A HIERARCHY OF
CRYPTOGRAPHIC PROTOCOL MODELS
Catherine Meadows
Naval Research Laboratory
Code 5543
Washington, DC 20375
Meadows@itd.nrl.navy.mil
1
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
2
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
3
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.
4
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
5
BUT …
Common recommendations for good protocol hygiene rule out this
kind of attack
1. Use different key pairs for signing and encryption
2. 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
6
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
7
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
8
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
9
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?
10
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)
11
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
12
ANOTHER SUGGESTION -- SESSION
KEY COMPROMISE
Standard model does not include compromise of session key, but
consider Needham-Schroder shared key protocol
1.
2.
3.
4.
5.
A
S
A
B
A
->
->
->
->
->
S
A
B
A
B
:
:
:
:
:
A, B, Na
{Na, B, Kab, {Kab, A}Kbs}Kas
{Kab,A}Kbs
{Nb}Kab
{Nb -1}Kab
Suppose that old Kab’ learned by intruder
3.
4.
5.
IA -> B
B -> IA
IA -> B
:
:
:
{Kab’,A}Kbs
{Nb}Kab’
{Nb -1}Kab’
13
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
14
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
15
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?
16
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
17
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”
18
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
19
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
20
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?
21
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?
22
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
23