Types and Effects for Asymmetric Cryptographic Protocols

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 Project http://research.microsoft.com/~adg/cryptyc.htmhttp://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 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

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}Nfor some x, run P” Decryption evolves according to the rule: decrypt {L}Nis {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

7. Cryptyc in One Page 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

9. 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 No automatic discovery of attacks No insider attacks Usual Dolev-Yao perfect encryption assumptions Only symmetric crypto, public nonces NEXTTALK? THIS 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 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

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 andN: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 UnKey(Un) we can obtain Opponent Typability by deriving: If M:Unand N:Unthen {M}N:Un. If M:Un andN:Unand 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 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 kis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

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 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 andN:DecKey(T) and x:T  P well-typed, then so is decrypt M asxN;P.

18. 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.

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 TUn, 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 Server A authenticates to client B via certificate from CA 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’sverification key (initially unknown) KA-1  Enc pKA -- A’sprivate signing key

22. Types for the Key-Pairs AuthMsg(A)  (msg:T, B:Un, N:Nonce[(AsendingmsgtoB)] 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 typeNonce[(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

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 Encryption with B’s public key

25. Fix: Encrypt Outgoing Nonce 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.

26. Typing Private, Tainted Nonces AuthMsg(P)  msg1(N: PrivChall[])  msg2(msg:Top, Q:Un, N:PrivResp[(QsendingmsgtoP)]) 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

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 AuthMsg(P)  msg1(N: PrivChall[])  msg2(msg:Top, Q:Un, N:PrivResp[(QsendingmsgtoP), 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

29. 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

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