1 IBM 2003 -2004 Michael Backes IBM

1 © IBM, 2003 -2004 Michael Backes IBM Research Gmb. H, Rüschlikon, Switzerland joint work with Birgit Pfitzmann and Michael Waidner Formal Methods and Cryptography FOSAD, September 2004

2 © 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 • Symmetric Primitives in the Library, Overview of Other Results for Secure Reactive Systems • Cryptographic Notions of Non-Interference • Enterprise Privacy Policies

3 © IBM, 2003 -2004 PART 1 A Reactively Secure Dolev-Yao-style Cryptographic Library

4 © IBM, 2003 -2004 Building Systems on Open Networks E-Government Hospital Bank

5 © IBM, 2003 -2004 Cryptography: The Details xobloo. T-otpyr. C Encryption Hashfunction Signature Key establishment

6 © IBM, 2003 -2004 Cryptography: The Details xobloo. T-otpyr. C Encryption Hashfunction Signature Key establishment

7 © IBM, 2003 -2004 Formal Methods: The Big Picture o ypt Cr d ize ure n l dea ignat ptio ion I t ent S ncry unc t ishm E shf tabl Ha y es Ke D CA y d b CAV ne sig ed by De ifi Ver But can we justify ?

8 © IBM, 2003 -2004 Overview of Our Approach • Precise system model allowing cryptographic and abstract operations • “As secure as” with composition theorem • Preservation theorems for security properties • Concrete pairs of idealizations and secure realizations • In particular: Dolev-Yao style cryptographic library • Detailed Proofs • Poly-time, cryptographic bisimulations with static information flow analysis, …

9 © IBM, 2003 -2004 Automatic Proofs of Security Protocols

10 © IBM, 2003 -2004 Why Formal Methods? • Automation if • • Repetitive Tedious Prone to human errors Critical application • A top candidate: Distributed protocols • Security variants for 20 years

11 © IBM, 2003 -2004 Protocol Proof Tools HOL Provers Theory 1 Theory n Special security provers ¥ state • Almost anything • Much human interaction • Special logic fragments for security • Approximations: correct, not complete Data indep/ Model Checkers • Fully automatic • State exploration

12 © IBM, 2003 -2004 Automating Security Protocol Proofs • Even simple protocol classes & properties undecidable • Robust protocol design helps • Full arithmetic is out • Probability theory just developing So how do current tools handle cryptography?

13 © IBM, 2003 -2004 Dolev-Yao Model • Idea [DY 81] • Abstraction as term algebras, e. g. , Dx(Ex(Ex(m))) • Cancelation Rules, e. g. , Dx. Ex = e • Well-developed proof theories • Abstract data types • Equational 1 st-order logic • Important for security proofs • Inequalities! (Everything that cannot be derived. ) • Known as “initial model” Important goal: Justify or replace

14 © IBM, 2003 -2004 Dolev-Yao Model – Variants [Ours] • Operators and equations • sym enc, pub enc, nonce, payload, pairing, sigs, MACs, . . . • Inequalities assumed across operators! • Untyped or typed • Destructors explicit or implicit • Abstraction from probabilism • Finite selection, counting, multisets • Surrounding protocol language • Special-purpose, CSP, picalculus, . . . [any] sign pk’ E pk (, ) N m

15 © IBM, 2003 -2004 Other Work on DY Justification • [AR 00, AJ 01, L 01]: symmetric encryption, passive • [HLM 03]: public-key encryption, passive • [MW 04]: public-key encryption, much more restricted, slightly “purer” • [L 04]: Active symmetric encryption (earlier than ours).

Cryptography 16 © IBM, 2003 -2004

17 © IBM, 2003 -2004 Example: Encryption, passive A 1, A 2 PPT: P(b* = b : : (Attacker success) (sk, pk) gen(k); (Keys) (m 0, m 1, v) A 1(k , pk); (Message choice) b R {0, 1}; c : = enc(pk, mb); (Encrypt) b* A 2(v, c) ) (Guess) 1/2 + 1/poly(k) (Negligible)

18 © IBM, 2003 -2004 Reactive Simulatability (“as secure as”)

19 © IBM, 2003 -2004 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

20 © IBM, 2003 -2004 Indistinguishability [Yao_82] Families of random variables: (vk)k IN poly (v'k)k IN D (prob. poly. in first input): | Pr(D(1 k, vk) = 1) – Pr(D(1 k, v'k) = 1) | 1 / poly(k).

21 © IBM, 2003 -2004 Interesting Secure Abstactions

22 © IBM, 2003 -2004 Cryptographic Idealization Layers Small real abstractions VSS Certified mail Credentials [GM 95] Larger abstractions [PSW 00] [CL 01] Secure channels [PW 00, PW 01, CK 02, BJP 02, . . . ] Low-level crypto (not abstract) Encryption as E(pk, 1 len) [LMMS 98, PW 00, C 01, . . . ] . . . Auth/sigs as statement database . . . [BPW 03. . . ] Related: [SM 93, P 93] Real auth/sig’s + integrity lookup [LMMS 98, C 01, . . . ] Normal cryptographic definitions . . .

23 © IBM, 2003 -2004 Ideal Dolev-Yao Style Library

24 © IBM, 2003 -2004 Dolev-Yao-style Crypto Abstractions • Recall: Term algebra, inequalities • Major tasks: • Represent ideal and real library in the same way to higher protocols • Prevent honest users from stupidity with real crypto objects, but don’t restrict adversary • E. g. , sending a bitstring that’s almost a signature • What imperfections are tolerable / must be allowed?

25 © IBM, 2003 -2004 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

26 © IBM, 2003 -2004 Ideal Cryptographic Library (2) U V Tu, 4 encrypt(Tu, 1, Tu, 3) received(U, Tv, 2) send(V, Tu, 4) Term 1 For U: For V: For A: Term 2 Tu, 1 - Term 3 pk Tu, 3 - E pk Tu, 2 Tv, 1 Ta, 1 E m get_type(Tv, 2) Tv, 3 : = decrypt(. . . ) Term 4. . . E A pk TH pk m E pk m

27 © IBM, 2003 -2004 Main Differences to Dolev-Yao Tolerable imperfections: • Lengths of encrypted messages cannot be kept secret • Adversary may include incorrect messages inside encryptions • Signature schemes can have memory • Slightly restricted key usage for symmetric encryption

28 © IBM, 2003 -2004 Real Dolev-Yao Style Library

29 © IBM, 2003 -2004 Real Cryptographic Library U V Commands, payloads, handles No crypto outputs! Payloads / test results, handles pk c 1 E(pk, m) c 2 E(pk, m) c 1 A Bitstrings Real system

30 © IBM, 2003 -2004 Main Additions to Given Cryptosystems • Type tags • Tagging with keys • Additional randomization (e. g. , needed when correct machines use A’s keys)

31 © IBM, 2003 -2004 Proof Sketch of Dolev-Yao Style Library

32 © IBM, 2003 -2004 The Simulator

33 © IBM, 2003 -2004 Proof of Correct Simulation (1) Rewrite Idealize, comp/ theorem

34 © IBM, 2003 -2004 Proof of Correct Simulation (2) Reduction proofs for collisions, guesses, forgeries Combined system Probabilistic bisimulations • With error sets (of runs) • With info-flow analysis

35 © IBM, 2003 -2004 Proof of Correct Simulation (3) Probabilistic bisimulation Indistinguishable by hybrid argument • Commitment problem • Key cycles Probabilistic bisimulation

36 © IBM, 2003 -2004 Summary (Part 1) • Dolev-Yao model Next: • Needham-Schroeder-Lowe

37 © IBM, 2003 -2004 More Information • {mbc, bpf, wmi}@zurich. ibm. com • http: //www. zurich. ibm. com/security/models/ • Read just one paper? ACM CCS 2003.

38 © IBM, 2003 -2004 PART 2 Proving the Needham-Schroeder-Lowe Protocol with the Dolev-Yao-style

39 © IBM, 2003 -2004 Recall Summary & Outlook Part 1 • • Dolev-Yao

40 © IBM, 2003 -2004 In Other Words: Sound Abstract Protocol Proofs Formalize with given interface Ideal DYstyle library Abstract primitives Part 1 “≥” NLS-PK protocol uses Real DYstyle library uses Clear Entity authentication Abstract fulfils protocol replace primitives Concrete primitives Prove for NLS “≥” Abstract goals Comp/ theorem General defs Concrete fulfils Concrete protocol goals Pres/ theorem

41 © IBM, 2003 -2004 Composition as Needed Here Given: ³ Then this holds:

42 © IBM, 2003 -2004 Property Preservation theorems over „³ “ for • Integrity properties • Some confidentiality properties: • Non-interference • Intransitive non-interference • „Polynomial liveness“ Each time: • Define cryptographic fulfilment • Prove Authenticity is one of these

43 © IBM, 2003 -2004 Integrity Preservation Theorem • Integrity property: Set of permitted traces at ports to the users • E. g. , semantics of temporal logic • Cryptographic semantics • Perfect / statistical / computational fulfillment • Poly: A PPT: P(run ports to the user Req) NEGL • Preservation Theorem: (Sysreal Sysideal) (Sysideal Req) Req poly testable (Sysreal poly Req) • Proof Idea: If this was different, build distinguisher that recognizes situation Events here

44 © IBM, 2003 -2004 The NSL Public-Key Protocol • Originally Needham and Schroeder 78 • Modified by Lowe 95 after MITM attack u v: Epk_v(Nu, u) v u: Epk_u(Nu, Nv, v) u v: Epk_v(Nv) • Multiple proofs over Dolev-Yao (Lowe, Meadows, Syverson, Schneider, …) • No prior cryptographic proof; concurrently by Warinschi (directly cryptographic) • All formal methods (and crypto) need refined protocol definition; sometimes automated

45 © IBM, 2003 -2004 The NSL Protocol over Our DYStyle Library Refining u v: Epk_v(Nu, u) NSL 1 NSL 2 NSL 3 Crypto. Lib-TH NSL 1 NSL 2 NSL 3 CL 1 CL 2 CL 3 For NLSu: 1. nuhnd gen_nonce(); 2. Nonceu, v : = Nonceu, v {nuhnd}; 3. uhnd store(u); 4. lhnd list(nuhnd, uhnd ); 5. chnd encrypt(pkeu, vhnd, lhnd ); 6. send_i(v, chnd )

46 © IBM, 2003 -2004 Informal Entity Authentication Property § “When v thinks it speaks with u, then it does. ” § “When v successfully terminates a session thinking to speak with u, then u indeed started a session with v. ” Remarks: § Entity authentication is weak: no session key, no time. § Mutual authentication and replay prevention possible.

47 © IBM, 2003 -2004 Entity Authentication in Our Model • Important for preservation theorem: Property expressed as user in-/outputs • Here • “successful termination” as output for v • “protocol start” as input from u t 1: EA_outv!(ok, u) t 0 < t 1: EA_inu? (new_prot, v)

48 © IBM, 2003 -2004 Proving that NSL Fulfills Entity Authentication EA definition NSL 1 NSL 2 Idea: NSL 3 Crypto. Lib-TH Proof via invariants. E. g. , nonce secrecy: • • v terminates protocol with u u sent 3 rd message u obtained 2 nd message v sent 2 nd message … 1. u v: Epk_v(Nu, u) 2. v u: Epk_u(Nu, Nv, v) 3. u v: Epk_v(Nv) Informal: Honest u created Nu for honest v Nu only known to u and v Formal: D[ j ]. hndu Nonceu, v (D[ j ]. hndw = for all w {u, v})

49 © IBM, 2003 -2004 The Other Invariants • Correct nonce owner (Nonceu, v handles) • Unique nonce use • Nonce list secrecy (List with Nu has handles for u, v only) • Correct list creator (for the 3 protocol messages) 1. u v: Epk_v(Nu, u) 2. v u: Epk_u(Nu, Nv, v) 3. u v: Epk_v(Nv) • Msg 1: If D[ j ]. type = list: Let xi : = D[ j ]. arg[ i ] and xihnd : = D[ xi ]. hndu: If x 1 hnd Nonceu, v and D[ x 2 ]. type = data then D[ j ] was created by user u in Step 4.

50 © IBM, 2003 -2004 Summary Part 2 • Needham-Schroeder-Lowe PK • First cryptographic proof NSL (one of two, the other direct). • Proof by hand, but symbolic • Invariants are quite similar to those in proof tools • Tagging from real crypto library still there • Like higher-level language vs. assembler • Still there may be room for optimization

51 © IBM, 2003 -2004 Summary • Reactive simulatability: core definition to link cryptography and formal methods • Composition and property preservation theorems enable usage • Justifying Dolev-Yao-style abstraction was particularly important • For large systems higher-level abstractions will be equally useful • Low-level ideal systems more important for cryptographic hand-proofs; not always more helpful than classical definitions • Formal methods won’t replace all hand-proofs for a long time, but see [LMMS. . . , IK 03]