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

2. 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. 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. 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. 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 Canc. rules Canc. rules Free algebra Free algebra Crypto mocel. Crypto mocel.

6. 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. 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?