Download presentation

Presentation is loading. Please wait.

Published byCole Cooke Modified over 4 years ago

1
1 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

2
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
3 The Cryptyc Approach Review of our earlier work (MFPS01, CSFW01) on types for correspondence assertions and symmetric-key crypto

4
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
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
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{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
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
8

9
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 THIS TALK! NEXT TALK?

10
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
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 x 1, …, x n we have: x 1 :Un, …, x n :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
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
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
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: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
15 Feature One A type system for asymmetric encryption and decryption

16
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 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

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

18
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
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
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
21 Authentication using Certificates 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 -- As verification key (initially unknown) KA -1 Enc pKA -- As private signing key Server A authenticates to client B via certificate from CA

22
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
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
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,NB KB Assertion 2 B ends( A sending msg to B ) Encryption with Bs public key

25
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. 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 )

26
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
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
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
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: x 1 :Un, …, x n :Un P : [] implies robust safety

30
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
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
32 Q&A

Similar presentations

Presentation is loading. Please wait....

OK

AUTHENTICATION AND KEY DISTRIBUTION

AUTHENTICATION AND KEY DISTRIBUTION

© 2018 SlidePlayer.com Inc.

All rights reserved.

To make this website work, we log user data and share it with processors. To use this website, you must agree to our Privacy Policy, including cookie policy.

Ads by Google