1

Types and Effectsfor Asymmetric Cryptographic Protocols

Andy Gordon, Microsoft Research

Joint work with Alan Jeffrey, DePaul University

Imperial College, March 6, 2002

Progress report on the Cryptyc Projecthttp://research.microsoft.com/~adg/cryptyc.htm

http://cryptyc.cs.depaul.edu

2

The Cryptyc Project

Cryptyc verifies security properties of cryptographic protocols by typing

Our earlier work focuses on simple crypto and freshness handshakes

Our new work is an extension to deal with asymmetric cryptography:

Public-key encryption and digital signatures

Richer repertoire of freshness handshakes

This talk reviews earlier work, then describes three significant features of our new type system

3

The Cryptyc Approach

Review of our earlier work (MFPS’01, CSFW’01) on types for correspondence assertions and symmetric-key crypto

4

The Problem

Crypto protocols are communication protocols that use crypto to achieve security goalsPioneered by Needham & Schroeder (1978)

Widely deployed, e.g., Kerberos, SSL, …

The basic crypto algorithms (e.g., DES, RSA) may be vulnerable, e.g., if keys too short

But even assuming perfect building blocks, crypto protocols are notoriously error prone

Suffer from replay attacks and confusions of identity

Bugs turn up decades after invention

5

A Typeful Solution

Our approach to checking crypto protocols Program protocols in the -calculus Assert event-based authenticity properties Type-check the assertions with Cryptyc

Builds on earlier work (by Abadi and Gordon) on a version of the -calculus with abstract crypto primitives

6

The Spi-Calculus in One Page

The statement decrypt M is {x}N;P means:

“if M is {x}N for some x, run P”

Decryption evolves according to the rule:

decrypt {L}N is {x}N;P P{xL}

Decryption requires having the key N

Decryption with the wrong key gets stuck

There is no way to extract N from {L}N

7

Cryptyc in One Page

Assertion 1 A begins (A sending msg to B)

Message 1 B A: NB

Message 2 A B: {msg,NB}KAB

Assertion 2 B ends (A sending msg to B)Each end-assertion to have distinct, preceding begin-

assertion with same label

Attacks (replays, impersonations) show up as violations of these assertions

By type-checking, Cryptyc prevents such attacks, even in presence of untyped attacker

8

9

Assessment

BenefitsFamiliar program/type-check/debug cycleLittle human effort per protocolNo bound on size of opponent or protocolNaturally handles control flowTypes are meaningful documentation

LimitationsNo automatic discovery of attacksNo insider attacksUsual Dolev-Yao perfect encryption

assumptionsOnly symmetric crypto, public nonces

THIS THIS TALK!TALK!

NEXTNEXTTALK?TALK?

10

Recasting with Subtypes

A review of the type system for symmetric crypto

It will help to recast this previous work in terms of a subtype relation…

11

Review: Opponent Typability

As usual, the protocol opponent is an arbitrary participating process of the spi-calculus.

Type Un represents data known to the opponent.

Our system enjoys an Opponent Typability property:

Thm For any opponent process O with free names x1, …, xn

we have: x1:Un, …, xn:Un O

If data published to the opponent belongs to type Un, type-based properties hold in spite of any opponent,

because we can compose systems and opponents

12

Jargon: Public versus Tainted

We introduce a subtype order TUIf MT and TU then MU

Hence, we characterize data that may flow to or from the opponent:

Let a type T be public iff TUn

Let a type T be tainted iff UnT

Ex: Un is both public and tainted

Ex: Top is tainted but not public

13

Typing Symmetric Crypto

Terms of type Key(T) are names used as symmetric keys for encrypting type T

If M:T and N:Key(T) then {M}N:Un.

If M:Un and N:Key(T) and x:T P well-typed, then so is decrypt M as {x:T}N;P

Subtyping has axioms to allow Opponent Typability and to allow key publication…

14

Subtyping Symmetric Keys

Constructor Key(T) neither co- nor contravariant.

But, by axiom, Key(Un) is both tainted and public.

Given UnKey(Un) we can obtain Opponent Typability by deriving:

If M:Un and N:Un then {M}N:Un.

If M:Un and N:Un and x:Un P well-typed, then so is decrypt M as {x:Un}N;P

Given Key(Un)Un we can publish keys for communicating outside our system

15

Feature One

A type system for asymmetric encryption and decryption

16

Abstracting Asymmetric Crypto

Terms Enc k and Dec k extract the two parts of a asymmetric key-pair, the name k

Term MN is M encrypted with key N

Process decrypt M is xN;P attempts to decrypt M with key N decrypt MEnc k is xDec k;P P{xL}

Fairly standard model (Dolev-Yao 1984); has known limitations

Same operational semantics models both public-key crypto and digital signature applications

17

Typing Asymmetric Crypto

Names of type KeyPair(T) represent a key-pair for transforming T data.

Terms of type EncKey(T) and DecKey(T) are encryption and decryption keys, respectively.

If pKeyPair(T) then Enc pEncKey(T).

If pKeyPair(T) then Dec pDecKey(T).

If M:T and N:EncKey(T) then MN:Un.

If M:Un and N:DecKey(T) and x:T P well-typed, then so is decrypt M as xN;P.

18

Subtyping Asymmetric Keys

Variance rules reminiscent of types for input and output channels

If TU then EncKey(U)EncKey(T) (contravariant)

If TU then DecKey(T)DecKey(U) (covariant)

KeyPair(T) neither co- nor contravariant.

For both Opponent Typability and to allow publication of keys for Un, both EncKey(Un) and DecKey(Un) are public and tainted.

19

Deriving Dual Applications

Can prove the following:

(PK) EncKey(T) public iff T tainted

(DS) DecKey(T) public iff T public

Application of key-pairs of type KeyPair(T)

If (PK) but not (DS): public-key crypto

If (DS) but not (PK): digital signature

If both (PK) and (DS): have TUn, beware!

20

Example

Authentication using certificates: beyond scope of our earlier work

Shows new types for digital signature together with existing types for a nonce handshake

21

Authentication using Certificates

Assertion 1

A begins

(A sending msg to B)

Message 1

B A: NB

Message 2

A B: A,KAKCA-1,msg,B,NBKA-1

Assertion 2

B ends (A sending msg to B)pKCA, pKA -- key-pairsKCA Dec pKCA -- CA’s verification key (known to B)KCA-1 Enc pKCA -- CA’s private signing keyKA Dec pKA -- A’s verification key (initially unknown)KA-1 Enc pKA -- A’s private signing key

Server A authenticates to client B via certificate from CA

22

Types for the Key-Pairs

As in earlier work, a name of type Nonce[(A sending msg to B)] bears witness to a distinct preceding begin-event labelled [(A sending msg to B)]

(DS) applies to both key-pairs, since AuthMsg(A) and DecKey(AuthMsg(A)) are public (assuming T public)

So verification keys public, signing keys private

Type-checking verifies that A can authenticate to B

AuthMsg(A) (msg:T, B:Un, N:Nonce[(A sending msg to B)]pKCA: KeyPair (A:Un, KA: DecKey(AuthMsg(A)))pKA: KeyPair (AuthMsg(A))KCA-1: EncKey (A:Un, KA: DecKey(AuthMsg(A)))

23

Feature Two

With symmetric-key protocols, nonces can be public.

With public-key, nonces may need to be private.

Hence, we need new nonce types.

24

Public Nonces Insufficient

Replaced symmetric encryption with asymmetric

B has now no reason to believe message 2 from A

Unsafe, and indeed fails to type-check

(DS) rather than (PK) holds since payload type is public but untainted

Assertion 1 A begins (A sending msg to B)

Message 1 B A: NB

Message 2 A B: A,msg,NBKB

Assertion 2 B ends (A sending msg to B)

Encryption Encryption with B’s public with B’s public

keykey

25

Fix: Encrypt Outgoing Nonce

Now, B reasons that since only A can obtain NB from NBKA, A must have sent Message 2.

This protocol is safe.

To type-check it, we need new secret but tainted types for the nonce challenge and response.

Assertion 1 A begins (A sending msg to B)

Message 1 B A: NBKA

Message 2 A B: A,msg,NBKB

Assertion 2 B ends (A sending msg to B)

26

Typing Private, Tainted Nonces

Names of type PrivChall[] are private but tainted challenges

Names of type PrivResp[L] are private but tainted responses, witness to a distinct begin-event L

With these typings, can verify the protocol by type-checking

For (PK), have to taint AuthMsg(P), by assuming msg:Top

AuthMsg(P) msg1(N: PrivChall[]) msg2(msg:Top, Q:Un, N:PrivResp[(Q sending msg to P)])KA: EncKey(AuthMsg(A))KB: EncKey(AuthMsg(B))

27

Feature Three

Our private nonce types verify correspondence assertions, but the PK payload remains tainted.

New trust effects let nonces endorse tainted data.

28

Adding Trust Effects

The effect msg:T asserts that the existing name msg has the type T

Before checking the nonce, B knows only that msg:Top

If the nonce-check fails, B knows nothing more about msg

It could be junk from the opponent

After checking the nonce, B can downcast msg to the type T

It could only come from A

AuthMsg(P) msg1(N: PrivChall[]) msg2(msg:Top, Q:Un, N:PrivResp[(Q sending msg to P), msg:T]KA: EncKey (AuthMsg(A))KB: EncKey (AuthMsg(B))

29

The Delta in One Page

Type Un represents data known to the opponent

If TUn, T is public, data may flow to opponent

If UnT, T is tainted, data may flow from opponent

Types for asymmetric encryption and decryption

If T tainted, KeyPair(T) suitable for PK encryption, EncKey(T) public, DecKey(T) private

If T public, KeyPair(T) suitable for digital signature, DecKey(T) public, EncKey(T) private

Types for private nonce challenges

Effects to restore trust in tainted data

Thm: x1:Un, …, xn:Un P : [] implies robust safety

30

Related Work

Many formalisms for asymmetric protocols, and many static analyses of secrecy levels…

Only prior work on types for asymmetric crypto is by Abadi and Blanchet (FoSSaCS01, POPL02)

Verifies secrecy but not authenticity

Double type-checking, instead of trust effects, to endorse tainted data

Decrypted T data type-checked twice; at types T and Un

31

Conclusions, Future Work

Authenticity types scale, somewhat

Cryptyc implementation being extended

Want to apply to contemporary protocols

Lots more to do… http://research.microsoft.com/~adg http://cryptyc.cs.depaul.edu

32

Q&A