1 IBM 2003 -2004 Michael Backes with

1 © IBM, 2003 -2004 Michael Backes with Birgit Pfitzmann, Michael Waidner IBM Research, Zurich Cryptographic Protocols and Formal Methods FOSAD, September 2004

2 © IBM, 2003 -2004 Formal Methods: The Big Picture o ypt Cr d ize ure n l dea ignat ptio tion ent I S ry nc hm h Enc sh futablis Ha y es Ke D CA y d b CAV ne sig ed by De ifi Ver But can we justify ?

3 © IBM, 2003 -2004 Lecture Overview • A Reactively Secure Dolev-Yao-style Cryptographic Library • Proving the Needham-Schroeder-Lowe Protocol with the Dolev-Yao-style Library • Key Exchange Protocols on the Library, Overview of Other Results for Secure Reactive Systems, Compositionality • Cryptographic Notions of Non-Interference • Enterprise Privacy Policies

4 © IBM, 2003 -2004 Recall: Ideal Cryptographic Library U V Commands, payloads, terms? handles Term 1 For U: For V: For A: Term 2 Tu, 1 - Payloads / test results, terms? handles Term 3 Tu, 2 Tv, 1 Ta, 1 pk Tu, 3 - E pk E m No crypto outputs! Deterministic! Not globally known A pk TH m

5 © IBM, 2003 -2004 Recall: Reactive Simulatability H M 1 M 2 A H TH A’ Real system Idea: Whatever happens with real system viewreal with view system. could also happen (H) ideal(H) Indistinguishability of random variables

6 © IBM, 2003 -2004 PART 3 Overview of other Results

7 © IBM, 2003 -2004 The Otway-Rees Protocol • Proposed by Otway and Rees 87 u v: M, EK_u. T(Nu, M, u, v) v T: M, EK_u. T(Nu, M, u, v), EK_v. T(Nv, M, u, v) T v: M, EK_u. T(Nu, Kuv), EK_v. T(Nv, Kuv), v u: M, EK_u. T(Nu, Kuv) • Multiple proofs over Dolev-Yao (Paulson, Guttman, Schneider, …) • No prior cryptographic proof • All formal methods (and crypto) need refined protocol definition; sometimes automated

8 © IBM, 2003 -2004 The Otway-Rees Protocol over Our DY-Style Library Refining u v: M, EK_u. T(Nu, M, u, v) OR 1 OR 2 OR 3 Crypto. Lib-TH OR 1 OR 2 OR 3 CL 1 CL 2 CL 3 For ORu: 1. nuhnd gen_nonce(); 2. Mhnd gen_nonce(); 3. Nu, v : = Nu, v {(nuhnd, Mhnd, v, 1)} 4. uhnd store(u); 5. vhnd store(u); 6. lhnd list(nuhnd, Mhnd, uhnd , vhnd); 7. chnd symencrypt(Ku. Thnd, lhnd ); 8. mhnd list(Mhnd, chnd); 9. send_i(v, mhnd )

9 © IBM, 2003 -2004 Recall: Sound Abstract Protocol Proofs Formalize with given interface Ideal DYstyle library Abstract primitives Part 1 “≥” OR protocol uses Real DYstyle library uses Clear Key Secrecy Abstract fulfils protocol replace primitives Concrete primitives Prove for OR “≥” Abstract goals Comp/ theorem General defs Concrete fulfils Concrete protocol goals Pres/ theorem

10 © IBM, 2003 -2004 Notions of Key Secrecy • • Symbolic notion: Adversary never learns the key symbolically, i. e. , in our model D[i]. hnda = Cryptographic Notion: Every adversary has a negligible advantage over pure guessing in the following game: 1. 2. 3. The adversary observes the interaction with the protocol and subsequently selects a key that has been shared been two honest users A bit is chosen at random, and the adversary is either given the correct key or a freshly generated key The adversary has to guess whether the key was the actual protocol key or whether it is fresh

11 © IBM, 2003 -2004 Key Secrecy for Otway-Rees in Our Model § “Whenever u established a shared key with user v then the adversary never learns this key, i. e. , it never gets a handle to this key. ” • Here • “successful termination” as output for u t 1 t 2 : t 1: KS_outu!(ok, Otway-Rees, v, Mhnd, skhnd) t 2: D[hndu = skhnd]. hnda = -

12 © IBM, 2003 -2004 Key Secrecy for Otway-Rees in Our Model (Cryptographic) § “Whenever u established a shared key with user v then the adversary cannot distinguish this key from a fresh key. ” • Here t 1 t 2 : t 1: KS_outu!(ok, Otway-Rees, v, Mhnd, skhnd) No adv. can distinguish D[hndv = skhnd]. word and a fresh key sk*

13 © IBM, 2003 -2004 Property Preservation theorems over „³ “ for • Integrity properties • Some confidentiality properties: • Non-interference • Key Secrecy (specific for DY) • „Polynomial liveness“ Each time: • Define cryptographic fulfilment • Prove For the Otway. Rees protocol

14 © IBM, 2003 -2004 Composition Theorems

15 © IBM, 2003 -2004 Composition – One System Given: ³ Then this holds: ³

16 © IBM, 2003 -2004 Proof Idea (Single Composition) H A# H 0 H A 0 = A# H A* = A'0 H A'0

17 © IBM, 2003 -2004 Composition – Multiple Systems Given: ³ Also this holds: ³

18 © IBM, 2003 -2004 General Composition Proof via Hybrid Systems H H M 1 ³ A M 3 TH 1 TH 3 A Sim 3 M 2 TH 2 Sim 3 H TH 1 Sim 1 H Sim 1 M 3 A ³ TH 1 Sim 1 M 3 M 2 TH 2 Sim 3 A

19 © IBM, 2003 -2004 Composability Types Constant many identical prot. General Universal Blackbox Constant many different prot. [PW 00, PW 01] [L 03] [PW 00, PW 01] [C 01] [PW 00, PW 01] Poly many identical prot. Poly many different prot. [C 01] [BPW 04] [PW 00, PW 01] [BPW 04]

20 © IBM, 2003 -2004 Different Security Requirements in the Model

21 © IBM, 2003 -2004 Characterization Integrity (e. g. , temporal logic) Privacy (e. g. , information flow, noninterference) Liveness: (Something good eventually happens) • Termination • Starvation freedom • Guaranteed service

Integrity 22 © IBM, 2003 -2004

23 © IBM, 2003 -2004 Integrity Abstract formulation: e. g. , temporal logic over the interface of a system (ports to the user) Cryptographic semantics: For all with linear-time semantics (set of permitted traces) Example: “If m is input at p? at time t, then there exists a future time s such that m is output at port q!” ( Reliability) A trace tr is contained in Req if t: t: p? m s > t: s: q!m

24 © IBM, 2003 -2004 Fulfillment of Integrity Different kinds of fulfillment: • Perfect: Requirement always holds • Computational: For polynomial-time adversary and users only and up to negligible error probability Preservation Theorem: Simulatability preserves “ ”: Sys 1 Sys 2 and Sys 2 |= Req Sys 1 |=poly Req Preservation theorem enables meaningful proofs on the abstract layer

25 © IBM, 2003 -2004 Cryptographic Non-Interference (Transitive)

26 © IBM, 2003 -2004 Privacy • No single well-established type of privacy properties in formal methods • Most common type here: Non-interference • Lots of application areas: • Secure operating systems [De 76, De 77] • Confinement: trusted program leaks information through covert channels • Renewed importance with extensible systems: applets, kernel extensions, mobile agents, etc.

27 © IBM, 2003 -2004 Some Prior Approaches Non-probabilistic Reactive systems: [Many] • Based on process calculi • Definitions are the main issue, different types of non-interference. • Main problem here: refinement Probabilistic Reactive systems [Gr 92] • Gray‘s definition „Probabilistic Non. Interference“ stands out • For all high-level environment behaviours same probability distribution of the low-events. • Perfect fulfillment only, not yet suited for real cryptography introduce error probabilities, etc.

28 © IBM, 2003 -2004 Prior work (cont’d) Deterministic Non. Interference Nondeterministic Probabilistic Cryptographic GM 82 Many Gray 92 New

29 © IBM, 2003 -2004 Cryptographic Non-Interference Bit Out b {0, 1} b* H L TH Want to express: No information can flow from H to L A Idea: Whatever P(b=b*) 1/2 + Negl H does, L will not recognize it + Now error probabilities, computational restrictions + „Guessing a bit“ is a typical concept in cryptography Closely related to cryptographic definitions

30 © IBM, 2003 -2004 Preservation under Simulatability • Preservation Theorem (Informal): Whenever an abstractions fulfills a cryptographic non-interference requirement, then every secure implementation of it also fulfills this requirement. • Formally: Sys 1 Sys 2 = NIReq. H_L Sys 1 = NIReq. H_L

31 © IBM, 2003 -2004 Cryptographic Non-Interference (Intransitive)

32 © IBM, 2003 -2004 A Scenario for Intransitive Non-Interference CEO

33 © IBM, 2003 -2004 Prior work (cont’d) Deterministic Nondeterministic Probabilistic Cryptographic Non. Interference GM 82 Many Gray 92 New Intransitive GM 84 Rushby 92, Pinsky 95, RG 99, SRS+ 00 New

34 © IBM, 2003 -2004 Definition 1: Blocking Non-Interference Secretary can prevent the flow b Bad b* Sec CEO Sys " Bad " CEO $ Sec: Bad ® CEO / all poly-time Prob(b* = b : : r ¬ runconf; b : = r éb_in. . . ; b* : = r éb_out) ½+e 0 Small Negl

35 © IBM, 2003 -2004 Definition 2: Recognition Non-interference Secretary sees what’s going on b’ b D b* view Bad Sec CEO Sys CEO gets b Þ Sec gets b. " Bad " CEO " Sec $ D

36 © IBM, 2003 -2004 Arbitrary Flow Graphs Sec / Bad CEO VP Friend.

37 © IBM, 2003 -2004 Preservation under Simulatability Theorem: sec Sys Ideal. Sys Bad

38 © IBM, 2003 -2004 Implementation with Cryptographic Firewall Bad Sec CEO Filtering rules Fil 1 Fil 2 Fil 3 Secure channels SC 1 SC 2 Bad sec Sec CEO Ideal Firewall SC 3 Prove recognition NI

39 © IBM, 2003 -2004 Summary of Secure Reactive Systems • Reactive simulatability: core definition to link cryptography and formal methods • Justifying Dolev-Yao-style abstraction as the most important task • Composition and property preservation theorems enable usage • First cryptographically sound proofs of Needham. Schroeder-Lowe and Otway-Rees