TOWARDS A HIERARCHY OF CRYPTOGRAPHIC PROTOCOL MODELS

1. TOWARDS A HIERARCHY OF CRYPTOGRAPHIC PROTOCOL MODELS • Catherine Meadows, NRL • Joint work with Chris Lynch, Clarkson/NRL

2. WHAT’S THE PROBLEM? • Formal analysis of cryptographic protocols based upon sand • We use discrete methods to analyze systems that use algorithms whose security is based on probability and complexity theory • Results are good for finding bugs, but any “proof” of security limited • Emerging trend in research • Security models amenable to discrete analysis that can be proven sound with respect to more detailed cryptographic models • Abadi-Rogaway • Backes-Pfitzmann • Perhaps there is also a middle ground • Intermediate points at which one proves that a less detailed model is sound with respect to a more complex and detailed model • Leads to a hierarchy of cryptographic models

3. HOW OUR WORK GOT STARTED • Arose out of two things: • Desire to have equational unification rules for different theories to use with NRL Protocol Analyzer • An argument with Jon Millen as to whether this was even necessary • I favored cancellation rules, and had examples of protocols where they were necessary • Jon favored free algebras, as being more efficient, and adequate in most cases • Jon subsequently proved a result giving conditions under which free algebra model sound with respect to cancellation model for shared key case • Left public key case an open question

4. WHAT’S NEXT? • Other Cryptosystems • Diffie-Hellman • Know how to model a non-commutative version of DH • When is it safe to use? • Have some conjectures on this, and are working on them • Extended Diffie-Hellman • Multiple exponentations • What can we abstract away from here? • Specific public or shared key cryptosystems • Exclusive-or • RSA - has homormorphic properties • Other models • NRL Protocol Analyzer model similar to Millen’s put perhaps more expressive, even when uses same cancellation rules • Soundness with respect to other properties than secrecy • Millen’s results apply to authenticaton properties too, but not clear which ones • Efficient equational unification rules • For use when protocol does not satisfy restrictions

5. WHAT WILL WE DO WITH THIS? • Wind up with • 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 Free algebra Canc. rules Crypto mocel.

6. SUGGESTIONS FOR OTHER COMPONENTS OF HIERARCHY • Representing system failures • Compromise of old session keys • Compromise of master keys • Failure of servers • These are often ignored in formal analysis of crypto protocols • Are there cases where safe to do so • Ambiguous Messages • Attacks involving passing off message of one type as message of another • Heather, Schneider, Lowe show how in certain circumstances possible to guarantee security of typing attacks if unambiguous formatting is used • How does this fit in the model hierarchy • Cryptographic models • Will they always be in the bottom of the hierarchy? • Physical models • Power attacks, etc.

7. SOME OTHER QUESTIONS • What will conditions on specifications be? • For the work we’ve been doing, it’s easy-to-check syntactic conditions • Same for Heather-Lowe-Schneider • What about lower level of granularity • What about conditions on properties we’re checking? • Much works in this area concentrates on secrecy alone • For Millen’s and our results, it’s absence of certain subsequence of traces • Other properties (authentication properties) can be formulated as conditions on presence of subsequences • If X happened, then Y happened before it • Are there general classes of properties it will make sense to look at? • What levels of granularity make sense? • How low should we go?