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