Secure Reactive Systems, Day 3: Reactive Simulatability Property Preservation and Crypto. Examples

Transcription

1 Michael Backes, Germany joint work with Birgit Pfitzmann and Michael Waidner Secure Reactive Systems, Day 3: Reactive Simulatability Property Preservation and Crypto. Examples Tartu, 03/01/06

2 Recall the Big Picture Crypto alized Id e S gnature i E cryption shfunction n H a K e y establishment But can we justify? CAD d by CAV signe D e by rified V e

3 Recall the RS Framework Precise system model allowing cryptographic and abstract operations Reactive simulatability with composition theorem Preservation theorems for security properties Concrete pairs of idealizations and secure realizations Sound symbolic abstractions (Dolev-Yao models) that are suitable for tool support Sound security proofs of security protocols: NSL, Otway-Rees, ikp, etc. Detailed Proofs (Poly-time, cryptographic bisimulations with static information flow analysis, )

4 Composition One System Given: Then this holds:

5 Proof Idea (Single Composition) H A # H 0 H A 0 = A # H A* = A' 0 H 0 H A' 0

6 Recall the RS Framework Precise system model allowing cryptographic and abstract operations Reactive simulatability with composition theorem Preservation theorems for security properties Concrete pairs of idealizations and secure realizations Sound symbolic abstractions (Dolev-Yao models) that are suitable for tool support Sound security proofs of security protocols: NSL, Otway-Rees, ikp, etc. Detailed Proofs (Poly-time, cryptographic bisimulations with static information flow analysis, )

7 Abstraction of one-step Public-Key Encryption On the board

8 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, m b ); (Encrypt) b* A 2 (v, c) ) (Guess) 1/2 + 1/poly(k) (Negligible)

9 Cryptographic Idealization Layers Symbolic abstractions Larger abstractions Small real abstractions Low-level crypto (not abstract) VSS [GM95] Secure channels [PW00, PW01, CK02, BJP02,...] Encryption as E(pk, 1 len ) [LMMS98, PW00, C01,...] Dolev-Yao Model Certified mail [PSW00] Credentials [CL01] Auth/sigs as statement database [BPW03...] Related: [SM93,P93] Real auth/sig s + integrity lookup [LMMS98, C01,...] Normal cryptographic definitions

10 Real System (send, m, r) (received, s, m) M s M r in s : (send, m, r): enc r (sign s (s,, m, r)) net r,s : ( enc r (sign s,c (s,, m, r)): 1. Decrypt, check signature, s, r abort at failure 2. Output (received, s, m)

11 Recall Naive Approach E.g., secure channel m m Not a good abstraction since not enough information for the simulator: Who is sender? Who is recipient? Length of m? No availability

12 Better Abstraction TH send msg receive send in s : (send, m, r): msg s,r := msg s,r & m, output (i, l, s, r) to Adversary from_adv r : (send,i,s( send,i,s): m:= msg msg s,r s,r [i], output (received, s, m) Tolerable imperfection s A

13 Proof Idea Real Secure Channels H H Ideal Secure Channels H L M r M s A TH SecCh A view real (H) view ideal (H) M* r M* s Simulator A 1. Proof by probabilistic bisimulation possible for most cases 2. Collect remaining traces in error sets (e.g., for forged signatures) 3. Show reduction proof of error sets against underlying crypto-primitive (e.g., against security of the signature scheme)

14 Explicit Security Requirements in the Model

15 Recall Prior Result as secure as (reactive simulatability) for certain versions of and

16 Specification Styles Is what people want? Often yes, in particular together with E.g., secure channels (see also spi calculus), certified mail But not always...

17 Alternative: Property-based spec. E.g., I want a tight roof on top : integrity Preserved by : Roof on top... Roof on top...

18 Characterization Integrity (e.g., temporal logic) Privacy (e.g., information flow, noninterference) Liveness: (Something good eventually happens) Termination Starvation freedom Guaranteed service

19 Integrity

20 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

21 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 Integrity Preservation Theorem: Simulatability preserves : Sys 1 Sys 2 and Sys 2 = Req Sys 1 = poly Req implies

22 Example: Ordered Secure Channels over Unordered Ones H H TH ord A = M 1 M 2 A TH SecMess Application: Composition Validate Formally THtheorem verified ord Bisimulation Transitivity (receivelist u,v sendlist u,v ) Preservation theorem H M 1 M 2 Real SecMess A

23 Cryptographic Non-Interference (Transitive)

24 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 [De76,De77] Confinement: trusted program leaks information through covert channels Renewed importance with extensible systems: applets, kernel extensions, mobile agents, etc.

25 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 [Gr92] 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.

26 Prior work (cont d) Deterministic Cryptographic Nondeterministic Probabilistic Non- Interference GM 82 Many Gray 92 New

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

28 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 Sys 2 = NIReq H_L Sys 1 = NIReq H_L

29 Cryptographic Non-Interference (Intransitive)

30 A Scenario for Intransitive Non-Interference CEO

31 Prior work (cont d) Deterministic Cryptographic Nondeterministic Probabilistic Non- Interference GM 82 Many Gray 92 New Intransitive GM 84 Rushby 92, Pinsky 95, RG 99, SRS+ 00 New New

32 Definition 1: Blocking Non-Interference Secretary can prevent the flow b b* Bad Sec CEO Sys Bad CEO Sec: all poly-time Bad / CEO Prob(b* = b :: r run conf ; b := r b_in...; b* := r b_out ) ½ + ε 0 Small Negl

33 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

34 Arbitrary Flow Graphs Bad Sec / VP CEO Friend B Friend CEO Bad CEO cuts Cut-Distinguisher

35 Preservation under Simulatability Theorem: Sys sec IdealSys Bad / Sec CEO Bad / Sec CEO

36 Implementation with Cryptographic Firewall Bad Sec CEO Bad Sec CEO Filtering rules Secure channels Fil 1 Fil 2 Fil 3 SC 1 SC 2 SC 3 sec Ideal Firewall Prove recognition NI

37 Michael Backes, Germany joint work with Birgit Pfitzmann and Michael Waidner Secure Reactive Systems, Day 4: Justifying Symbolic Abstractions of Cryptography Tartu, 03/02/06

38 Recall the RS Framework Precise system model allowing cryptographic and abstract operations Reactive simulatability with composition theorem Preservation theorems for security properties Concrete pairs of idealizations and secure realizations Sound symbolic abstractions (Dolev-Yao models) that are suitable for tool support Sound security proofs of security protocols: NSL, Otway-Rees, ikp, etc. Detailed Proofs (Poly-time, cryptographic bisimulations with static information flow analysis, )

39 Recall the RS Framework Precise system model allowing cryptographic and abstract operations Reactive simulatability with composition theorem Preservation theorems for security properties Concrete pairs of idealizations and secure realizations Sound symbolic abstractions (Dolev-Yao models) that are suitable for tool support Sound security proofs of security protocols: NSL, Otway-Rees, ikp, etc. Detailed Proofs (Poly-time, cryptographic bisimulations with static information flow analysis, )

40 Automatic Proofs of Security

41 Automation if Repetitive Tedious Why Formal Methods? Prone to human errors Critical application A top candidate: Distributed protocols Security variants for 20 years

42 Protocol Proof Tools HOL Provers Theory 1 Theory n Special security provers state Data indep/ Model Checkers Almost anything Much human interaction Special logic fragments for security Approximations: correct, not complete Fully automatic State exploration

43 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?

44 Dolev-Yao Model Idea [DY81] Abstraction as term algebras, e.g., D x (E x (E x (m))) Cancellation rules, e.g., D x E x = ε 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

45 Dolev-Yao Model Variants [Ours] Operators and equations pub enc, sym enc, nonce, payload, pairing, sigs,... Inequalities assumed across operators! Untyped or typed Destructors explicit or implicit Abstraction from probabilism Finite selection, counting, multisets Surrounding protocol language Special-purpose, CSP, pi calculus,... [any] [EG82, M83, EGS85...] pk sign pk E N (, ) m

46 The BPW Model (Ideal Dolev-Yao Style Library)

47 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?

48 Ideal Cryptographic Library U V No crypto outputs! Deterministic! Commands, payloads, terms? handles Payloads / test results, terms? handles For U: For V: For A: Term 1 T u,1 Term 2 T u,2 Term 3 T u,3 Not globally known - T v,1 - - T a,1 - E E A pk pk m pk m TH

49 Ideal Cryptographic Library (2) U V T u,4 encrypt(t u,1, T u,3 ) get_type(t v,2 ) send(v, T u,4 ) received(u, T v,2 ) T v,3 := decrypt(...) For U: For V: For A: Term 1 Term 2 Term 3 T u,1 - - T u,2 T v,1 T a,1 E T u,3 - - E pk Term 4... E E A pk pk m pk m pk m TH

50 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 Most imperfections avoidable for more restricted cases

51 Main Additions to Given Cryptosystems Type tags Tagging with keys Additional randomization (e.g., needed when correct machines use A s keys)

52 The Simulator

53 Proof of Correct Simulation (1) Rewrite Idealize, comp/ theorem S H M H M' u H M' v A Enc sim, H

54 Proof of Correct Simulation (2) Combined system Reduction proofs for collisions, guesses, forgeries Probabilistic bisimulations With error sets (of runs) With info-flow analysis H S H M H M' u M' v A Enc sim, H

55 Related Work (until first half of 2005) Attacks Operators Protocols Properties DY version & impl AR00, AJ01, L01 Passive 1 (pke or ske) differs Equivalences Simple BPW02, BPW03, BP04 Active Many Arbitrary Simulatability, Int., non-interf, now nonce, key & payload secrecy More complex but see L05, BB06 MW04 Active 1 (pke) Restricted Integrity Simple L04 Active 1 (ske) Restricted Equivalences Simple CW05 Active pke, sig Restricted Nonce secrecy Simple CH05 Active 1 (pke) Restricted Key secrecy Simple All simple ones come with tool: Specific for equivalences, any standard DY tool otherwise

56 New General Framework for Symbolic Analysis Automata framework Our Sound DY-Model Different Logics Protocol Instantiations Lemmas and Theories