1 / 43

Verifying Cryptographic Protocols in the Pi Calculus

IISC Bangalore, Jan 25—Feb 4 2005 CIMPA-UNESCO-INDIA school on Security of Computer Systems and Networks Verifying Cryptographic Protocols in the Pi Calculus Cédric Fournet , Microsoft Research , Cambridge Verifying Crypto Protocols in Pi

issac
Download Presentation

Verifying Cryptographic Protocols in the Pi Calculus

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. IISC Bangalore, Jan 25—Feb 4 2005CIMPA-UNESCO-INDIA school onSecurity of Computer Systems and Networks Verifying Cryptographic Protocolsin the Pi Calculus Cédric Fournet, Microsoft Research, Cambridge

  2. Verifying Crypto Protocols in Pi • The applied pi calculus, a calculus for modelling cryptographic protocols: syntax, semantics, proof techniques, small examples • Private Authentication, a first detailed model of a protocol in applied pi ProVerif, a coarser model based on logic, with automated proofs and translations from applied pi • Just Fast Keying, a discussion and analysis of a state-of-the-art protocol for Internet security Web Services Security, a framework for flexible protocol design and its model in applied pi [Karthik]

  3. Just Fast Keying ? Application to a “real-world” protocol

  4. IP Security: IKE and its successors • IKE (Internet Key Exchange) • Session management for IPSEC • Quite secure • Some concerns • Too complicated • Inefficient • Poor resistance against denial of service • The IETF is considering a successor for IKE,now merging the different proposals into IKEv2—draft 13 • Just Fast Keying (JFK) is a simple, state-of-the-artproposal with several interesting improvements

  5. A Classic Setting for Protocols • Two parties want to open a secure session • IP tunnel (IPSEC, VPN) • Telnet (SSH) • Web connection (SSL, TLS) • Web Services • They need to • Generate a shared secret (or session key) • Verify each other’s identity • Agree on many parameters • (Needham-Schroeder) attackers might eavesdrop, delete, and insert messages, may impersonate principals, to • gain information • confuse or hinder the participants

  6. Complications • Configuration • Different security needs according to the application • Many cryptographic algorithms to choose from • Many flavours of authentication (PKIs) • Different modes • Concurrency • Parallel sessions • Various principals using several shared proxies • Efficiency concerns • Round-trips are expensive • Cryptography can be expensive • Session management • Key derivation • Rekeying • Dead peer detection

  7. Design Goals for JFK • Secure “The key should be cryptographically secure, according to standard measures of cryptographic security for key exchange” • Efficient Message roundtrips are expensiveCryptography can be expensive • Flexible perfect forward secrecy With potential reuse of exponentials • Simple: no negotiation, no rekeying • Resistant to Memory- and CPU-bound denials of service • Private Some identity protection and plausible deniability These goals are (sometimes) contradictory.

  8. An Overview of JFK • First, a Diffie-Hellman exchange creates a shared secretover a public network, using long modular exponentials: • JFK refines the Diffie-Hellman exchange with • Fresh nonces • An anti-DOS authenticator • Shared-key encryption & MACs • Identities and public-key signatures

  9. Two-round Diffie-Hellman initiator IP responder Diffie-Hellman exponentials:create a fresh shared secret protected signatures and IDs:verify each other’s identity protected session messages

  10. Just Fast Keying (JFKr) initiator IP responder fresh nonces to reuse Diffie-Hellman exponentials:create a fresh shared secret anti-DOS authenticator protected signatures and IDs:verify each other’s identity protected session messages

  11. Just Fast Keying, IETF style

  12. Just Fast Keying: Flexible PFS The pair of nonces is unique for this session Many keys can be derivedfrom the same exponentialsfor different usages

  13. Just Fast Keying: DoS Resistance The first message is small The responder uses an authenticator against DoS The responder can check thatthe contents of message 3 matches the contents of messages 1 and 2

  14. Just Fast Keying: Privacy Identities are always encrypted Identities are never signed

  15. Some minor problems

  16. Identity protection? • Two flavours • “JFKi protects id_i against active attacks” • “JFKr protects id_r against active attacksand protects id_i against passive attacks” • What is guaranteed? Does it make sense for the responder?This depends on relations between principals and roles • Various leaks: • An active attacker can get the initiator’s hint • A passive attacker can perform traffic analysis • A passive attacker can observe shared exponentials • if exponentials are re-used by a single principal,all these sessions involve the same principal • an active attacker (or an insider) may obtainthe identity for one of these sessions • …

  17. Identity protection (2) • An attack on identity protection in JFKr: An active attacker can test the equality of authenticator keys to test whether a pair of principals are communicating

  18. Non-negotiated? • Usually, the cryptographic algorithms are negotiated:hash, encryption, certificates, compression, … Some algorithms are weak (legacy, legal…), or even nil. • The protocol must (at least) authenticate the negotiation, and also relies on these operations for authentication! Cf. SSL • “JFK is non-negotiated”: the responder demands specific algorithms, the initiator takes it or leaves it. Still… • If the responder demands weak algorithms, no guarantees at all. • What if the attacker modifies the responder’s demands? • The session will fail, either immediately (the initiator rejects the demand) or after message 3 (the server detects the mismatch). Bad denial of service. • If the initiator accepts a bad demand, her message 3 is not protected, and may reveal her identity.Bad identity protection (in JFKi) • Fix in JFKi: sign the algorithm demand [Keromytis]

  19. Caching message 3? • The responder caches answers to identical message 3s • More precisely, the responder should answer just oncefor every valid token received in a message 3. • Otherwise, several attacks appear: • There is a “blind” DOS attack that defeats the purpose of the authentication • There is a (small) security failure:the same key may be used in many established sessions

  20. Modelling JFK in the Pi Calculus

  21. Building blocks (review) • Shared-key encryption • Cryptographic hash (HMAC) • Tokens (or cookies) • Diffie-Hellman computation • Public-key signature

  22. Public key signature • To model public-key signature, we construct the public verification key form the private signing key: • Using active substitutions, we can write a process that exports the public key, and keeps the signing key secret. • We can also add equations for the attacker, rather than the protocol, e.g. key- and message-recovery:

  23. Grammar for Processes (review) Processes are those of the plain pi calculus,equipped with a (mostly) standard semantics Values are terms, rather than just names

  24. Grammar for Terms (for JFK)

  25. Equations for Terms (for JFK)

  26. The Network and the Attacker • All IP messages are transmitted on a single free channel, c. • An arbitrary environment (an arbitrary context)represents an active attacker • We sometimes model a passive attacker using derived, “eavesdropping” transitions stands for

  27. Principals, Roles, and Control Actions Principal A Initiator Responder Principal B a JFK run

  28. Initiator, Responder, Configuration

  29. Initiator, Responder, Configuration

  30. Initiator, Responder, Configuration

  31. From Processes to ProVerif Scripts • ProVerif can automatically prove security properties [Blanchet] • Secrecy, authenticity, even some observational equivalences • Translates processes to Horn clauses (discarding linearity) • Uses resolution, carefully selects clauses towards termination • Extended and improved for JFK • The input syntax of ProVerif: a single applied-pi processJFKr: a 300-line script with cryptography and security goals • JFK configurations are families of processes parameterized by compliant principals, acceptable identities, and exponentials • We formally relate the script to JFK configurations • We program an API for the attacker to “unfold” new exponentialsand new principals, with their fresh control interface • We rely on observational equivalence lemmas (proved by hand)

  32. Security Properties? • Resistance to DoS • Core Security: Key Secrecy, Mutual Authentication • Plausible deniability (hints) • Identity protection (skipped)

  33. Resistance to Denial Of Service We focus on the mechanisms against two particular denials of service for the responder addressed in JFK (1) Memory DoS forces responder to keep state for bad sessions, so JFK moves state to the authenticator (2) CPU DoS triggers expensive cryptography at low attacker cost, so JFK checks round-trip authentication

  34. Getting Rid of the Authenticator • The use of a token is a refinement, modelled as an equivalence • JFKr responder is stateless after message 1, relies on authenticator • A simpler, linear variant relies on local state instead • This is much like a parallel law for CCS • ProVerif works best with the linear version of JFKr

  35. Correspondence Properties for DOS • We characterize “round-trip communication” as a trace property and show an injective correspondence property from “expensive” responder steps to round-trips.

  36. Core Security:Secrecy and Authenticity

  37. Operational correctness

  38. Operational correctness We start from any reachable configuration of the protocol (past & running sessions) The protocol uses four IP messages exporting fresh terms to the attacker, abbreviated [1,2,3, 4]

  39. Operational correctness Each party gets the other’s identity & parameters, plus a shared key. Finally, an observational equivalence replace shared keys and intercepted values with fresh distinct names We end up with the original configuration + fresh namesIn particular, Kv is a perfect key

  40. Correspondences, Abstractly

  41. Correspondences, Operationally

  42. Conclusions on JFK IETF Security Area director says “the core features of JFKare that it's small, simple and amenable to formal analysis” • Well-engineered, well-written, and thoroughly discussed • Still message-centric and sometimes ambiguous • Auxiliary properties are tricky We performed a first complete analysis in applied pi calculus • An operational model for JFK in context (not just messages) • All claimed properties defined within a single modelusing both trace properties and observational equivalences • An interesting mix of manual & automated proof techniques • An important benchmark, useful for comparisonswith other formalisms and tools

  43. Questions? See also http://research.microsoft.com/~fournet/

More Related