Secure Information Flow by Self-Composition

Transcription

1 Secure Information Flow by Self-Composition Paper by Gilles Barthe, Pedro R. D Argenio, and Tamara Rezk Slides by Isaac Sheff

2 Background Noninterference Type Systems new features and policies require extensions to Type System and proof Logical Verification and Proof-Carrying Code Hoare Logic {Precondition} Code {Postcondition}

3 Program Logic Idea: let s encode Secure Information Flow as a logically provable property Andrews and Reitman extended Hoare Logic Darvas, Hähnle and Sands used dynamic logic Problem: reasoning about only one process Pottier s Pi Calculus work: 2 processes reduced to 1

4 2-Safety Prove that if you run program P twice, and the starting conditions each time are lowequivalent, then the finishing conditions are low-equivalent. high:7 low:3 P high:2 low:0 =L high:6 low:3 P =L high:1 low:0

5 Self-Composition From program P, create P just like P, but all new variable names New Program: P;P Need only consider single program high:7 high:2 high:2 low:3 P P low:0 low:0 =L high :6 =L high :1 low :3 low :0

6 Memory state: μ Notation Read variable foo from memory μ: μ(foo) Program Termination: Configuration: (Program, Memory state) Stick two (non-overlapping) memories together: S, starting with memory μ, doesn t terminate: (S, μ) Get all variable names in a memory: var(μ) Get abstract data structure at variable foo: v(μ, foo) Small Step transition: Any number of steps:

7 Par nondeterminism! Parallelism!

8 Implies var(s) is deep.

9 Definitely not true for all programs (or languages) Pointer logic messes with this

10 Given These Assumptions... Program S won t change anything not in var(s) Stuff not in var(s) won t affect S s termination Changing a variable name doesn t affect termination S, run on an identical set of values in different memories, has the same termination

11 More Notation φ : Var Var injective functions from one set of variables to another Indistinguishable variable sets: Indistinguishable memories: things that act like S 1;S2 (including parallelism): S1 S2

12 Non-Interference, Formalized S1 is termination sensitive (TS) non interferent with program S2 S1 is termination insensitive (TI) non interferent with program S2

13 Non-Interference, Formalized Different pre-condition and post-condition variable renaming and indistinguishability Extremely flexible Security: a program is non-interferent with itself Maybe indistinguishability is just low-equivalence

14 Composition If the memory state was indistinguishable from itself to begin with, then after running S1 S2, it remains indistinguishable form itself

15 The Big One For programs with non-overlapping sets of variables, our non-interference for two programs on different memories is the same as for two composed programs

16 Proof: TS is commutative, so Since programs don t affect variables not in the program: Therefore And so:

17 Proof: TI Because variables not in var(s) don t affect the termination of S:

18 But What if the Programs Share Variables? Let ξ be a function mapping the variables of one program to a new set. Noninterference of two programs is the same as noninterference of those programs, with one of their variables all renamed via ξ.

19 Theorem 2 Proof? Idea: prove that changing one variable s name does not alter noninterference Induct over all the variables in the program It s not very concise.

20 The Cool Part Now we can check of a program S is secure, by analyzing single executions of the program S S[ξ].

21 Analyzing Single Executions This is what verification logics are for Sections 5-9 are characterizations of security with some such logics

22 A Neat Example (5) xl: public yh: private We can show xl := xl + yh; xl := xl - yh is non-interferent

23 Deterministic We can actually check the security of a program by analyzing only the I/O (start and finish memories) of a self-composed program, e.g. S;S[ξ].

24 Deterministic Language While: a version of Par without nondeterminism (if can have only if... else... fi and get rid of parallelism) Consider memory that only stores integers, which is conveniently separable by

25 Hoare Logic {Precondition} Code {Postcondition}

26 Indistinguishability Criterion Shorthand µ I(I) i µ I µ (i (v(µ, ~x),v(µ, (~x))) 2 I)

27 TI Security in Hoare Logic Proof (recall that we re in a deterministic setting, and have a sequential composition operator ; )

28 Example Proof Original Program: xl := xl + yh; ξ: xl xl, yh yh xl := xl - yh Self-Composed Version: xl := xl + yh; xl := xl - yh; xl := xl + yh ; Indistinguishability: =L Meaning the low (really just xl) values must be the same xl := xl - yh

29 Example Proof {xl = xl } {xl + yh - yh = xl } xl := xl + yh; {xl - yh = xl } xl := xl - yh; {xl = xl } {xl = xl + yh - yh } xl := xl + yh ; {xl = xl - yh } xl := xl - yh {xl = xl } ((v(μ,xl), v(μ,yh)), (v(μ,xl ), v(μ,yh ))) =L In both the before and after states, since the xl values are equal.

30 Conclusions General Noninterference Formulation Self-composition for Security Analysis Need only analyze one program Determinism: only I/O analysis Various logics applied Future Work: characterizations for other non-interference notions other security properties prove secure type systems with these logics automation of such proofs in real languages