verifying cryptographic protocols in the pi calculus l.
Skip this Video
Loading SlideShow in 5 Seconds..
Verifying Cryptographic Protocols in the Pi Calculus PowerPoint Presentation
Download Presentation
Verifying Cryptographic Protocols in the Pi Calculus

Loading in 2 Seconds...

play fullscreen
1 / 43

Verifying Cryptographic Protocols in the Pi Calculus - PowerPoint PPT Presentation

  • Uploaded on

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

I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
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.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.

- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
verifying cryptographic protocols in the pi calculus

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

verifying crypto protocols in pi
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]

just fast keying

Just Fast Keying ?

Application to a “real-world” protocol

ip security ike and its successors
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
a classic setting for protocols
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
  • 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
design goals for jfk
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.

an overview of jfk
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
two round diffie hellman
Two-round Diffie-Hellman




Diffie-Hellman exponentials:create a fresh shared secret

protected signatures and IDs:verify each other’s identity

protected session messages

just fast keying jfkr
Just Fast Keying (JFKr)




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

just fast keying flexible pfs
Just Fast Keying: Flexible PFS

The pair of nonces is unique for this session

Many keys can be derivedfrom the same exponentialsfor different usages

just fast keying dos resistance
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

just fast keying privacy
Just Fast Keying: Privacy

Identities are always encrypted

Identities are never signed

identity protection
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
identity protection 2
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

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]
caching message 3
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
building blocks review
Building blocks (review)
  • Shared-key encryption
  • Cryptographic hash (HMAC)
  • Tokens (or cookies)
  • Diffie-Hellman computation
  • Public-key signature
public key signature
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:
grammar for processes review
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

the network and the attacker
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

principals roles and control actions
Principals, Roles, and Control Actions

Principal A



Principal B

a JFK run

from processes to proverif scripts
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)
security properties
Security Properties?
  • Resistance to DoS
  • Core Security: Key Secrecy, Mutual Authentication
  • Plausible deniability (hints)
  • Identity protection (skipped)
resistance to denial of service

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

getting rid of the authenticator
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
correspondence properties for dos
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.
operational correctness38
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]

operational correctness39
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

conclusions on jfk
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

See also