Types and Effects
for Asymmetric
Cryptographic Protocols
Andy Gordon, Microsoft Research
Joint work with Alan Jeffrey, DePaul University
Imperial College, March 6, 2002
Progress report on the Cryptyc Project
http://research.microsoft.com/~adg/cryptyc.htm
http://cryptyc.cs.depaul.edu
1
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
2
The Cryptyc Approach
Review of our earlier work (MFPS’01,
CSFW’01) on types for correspondence
assertions and symmetric-key crypto
3
The Problem
Crypto protocols are communication protocols
that use crypto to achieve security goals
Pioneered 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
4
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
5
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{xL}

Decryption requires having the key N

Decryption with the wrong key gets stuck

There is no way to extract N from {L}N
6
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
7
8
Assessment
Benefits
Familiar program/type-check/debug cycle
Little human effort per protocol
No bound on size of opponent or protocol
Naturally handles control flow
Types are meaningful documentation
Limitations
THIS
TALK!
NEXT
No automatic discovery of attacks
TALK?
No insider attacks
Usual Dolev-Yao perfect encryption assumptions
Only symmetric crypto, public nonces
9
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…
10
Review: Opponent Typability
As usual, the protocol opponent is an arbitrary
process of the spi-calculus.
participating
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
11
Jargon: Public versus Tainted
We introduce a subtype order TU
If MT and TU then MU
Hence, we characterize data that may flow to or
from the opponent:
Let a type T be public iff TUn
Let a type T be tainted iff UnT
Ex: Un is both public and tainted
Ex: Top is tainted but not public
12
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…
13
Subtyping Symmetric Keys
Constructor Key(T) neither co- nor contravariant.
But, by axiom, Key(Un) is both tainted and public.

Given UnKey(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
14
Feature One
A type system for asymmetric
encryption and decryption
15
Abstracting Asymmetric Crypto
Terms Enc k and Dec k extract the two parts of a
asymmetric key-pair, the name k
Term MN is M encrypted with key N
Process decrypt M is xN;P attempts to decrypt M
with key N
decrypt MEnc k is xDec k;P  P{xL}
Fairly standard model (Dolev-Yao 1984); has known
limitations
Same operational semantics models both public-key
crypto and digital signature applications
16
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 pKeyPair(T) then Enc pEncKey(T).
If pKeyPair(T) then Dec pDecKey(T).
If M:T and N:EncKey(T) then MN:Un.
If M:Un and N:DecKey(T) and x:T  P well-typed,
then so is decrypt M as xN;P.
17
Subtyping Asymmetric Keys
Variance rules reminiscent of types for input and output
channels
If TU then EncKey(U)EncKey(T) (contravariant)
If TU 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.
18
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 TUn, beware!
19
Example
Authentication using certificates: beyond scope of
our earlier work
Shows new types for digital signature together with
existing types for a nonce handshake
20
Authentication using Certificates
Server A authenticates to client B via certificate from CA
Assertion 1 A begins (A sending msg to B)
Message 1
B  A:
NB
Message 2
A  B:
A,KAKCA-1,msg,B,NBKA-1
Assertion 2 B ends
(A sending msg to B)
pKCA, pKA
-- key-pairs
KCA  Dec pKCA -- CA’s verification key (known to B)
KCA-1  Enc pKCA -- CA’s private signing key
KA  Dec pKA -- A’s verification key (initially unknown)
KA-1  Enc pKA -- A’s private signing key
21
Types for the Key-Pairs
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)))
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
22
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.
23
Public Nonces Insufficient
Assertion 1
A begins
Message 1
B  A:
Message 2
A  B:
(A sending msg to B)
Encryption with
NB
B’s public key
A,msg,NBKB
Assertion 2
B ends
(A sending msg to B)
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
payload type is public but untainted
since
24
Fix: Encrypt Outgoing Nonce
Assertion 1
A begins
(A sending msg to B)
Message 1
B  A:
NBKA
Message 2
A  B:
A,msg,NBKB
Assertion 2
B ends
(A sending msg to B)
Now, B reasons that since only A can obtain NB from
NBKA, 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.
25
Typing Private, Tainted Nonces
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))
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
26
Feature Three
Our private nonce types verify correspondence
assertions, but the PK payload remains tainted.
New trust effects let nonces endorse tainted data.
27
Adding Trust Effects
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))
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
28
The Delta in One Page
Type Un represents data known to the opponent
If TUn, T is public, data may flow to opponent
If UnT, 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
29
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
30
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
31
Q&A
32