Verifying cryptographic protocols in the pi calculus
Download
1 / 43

Verifying Cryptographic Protocols in the Pi Calculus - PowerPoint PPT Presentation


  • 252 Views
  • Updated 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

Related searches for Verifying Cryptographic Protocols in the Pi Calculus

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

PowerPoint Slideshow about 'Verifying Cryptographic Protocols in the Pi Calculus' - issac


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 l.jpg

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 l.jpg
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 l.jpg

Just Fast Keying ?

Application to a “real-world” protocol


Ip security ike and its successors l.jpg
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 l.jpg
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


Complications l.jpg
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


Design goals for jfk l.jpg
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 l.jpg
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 l.jpg
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


Just fast keying jfkr l.jpg
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



Just fast keying flexible pfs l.jpg
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 l.jpg
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 l.jpg
Just Fast Keying: Privacy

Identities are always encrypted

Identities are never signed



Identity protection l.jpg
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 l.jpg
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 l.jpg
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 l.jpg
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 l.jpg
Building blocks (review)

  • Shared-key encryption

  • Cryptographic hash (HMAC)

  • Tokens (or cookies)

  • Diffie-Hellman computation

  • Public-key signature


Public key signature l.jpg
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 l.jpg
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 l.jpg
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 l.jpg
Principals, Roles, and Control Actions

Principal A

Initiator

Responder

Principal B

a JFK run


Initiator responder configuration l.jpg
Initiator, Responder, Configuration


Initiator responder configuration29 l.jpg
Initiator, Responder, Configuration



From processes to proverif scripts l.jpg
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 l.jpg
Security Properties?

  • Resistance to DoS

  • Core Security: Key Secrecy, Mutual Authentication

  • Plausible deniability (hints)

  • Identity protection (skipped)


Resistance to denial of service l.jpg

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 l.jpg
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 l.jpg
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.


Core security secrecy and authenticity l.jpg

Core Security:Secrecy and Authenticity



Operational correctness38 l.jpg
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 l.jpg
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 l.jpg
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


Questions l.jpg
Questions?

See also http://research.microsoft.com/~fournet/