1 Enforcing Confidentiality in Low-level Programs Andrew Myers Cornell University

2 End-to-end security? Complex computations, untrusted components Security mechanisms: access controlfirewalls encryptiondigital signing static verificationmandatory controls Security guarantees: limited, not compositional

3 End-to-end policies End-to-end confidentiality policy: “The information in this file is confidential and should only be released only to users U 1 and U 2 ” End-to-end integrity policy: “This information is trusted and should only be affected by users U 1 and U 2 ” Not access control — information flow control

4 Noninterference “High” inputs cannot affect “low” observables –Confidentiality: high = confidential, low = public –Integrity: low = trusted, high = untrusted Can enforce using static type system : cheap, relatively accurate H1L1 L2 H2 H3L1 L2H4 LL

5 Static checking Expressions have associated static label Label captures part of security policy for labeled data L 1  L 2 means policy L 2 is at least as restrictive as L 1 int{L1} x; int{L2} y; x = y;  requires L2  L1 Also need program-counter label to catch implicit flows

6 Demo: Jif Java + Information Flow –security-typed language –fine-grained information flow checking –full-featured language: objects, classes, exceptions –genericity with respect to security –declassification –static and dynamic security policies Implemented using JLtools extension toolkit –6k semis –Nate Nystrom, Lantian Zheng, Steve Zdancewic

7 Challenges 1. Real computations must leak information must go beyond noninterference robust declassification 2. Enforcement for low-level programs first-class linear control 3. Distributed computation/untrusted hosts 4. Timing channels/multithreaded programs

8 Declassification Declassification (downgrading) : reduction of the confidentiality level of data Allows the intentional release of confidential information (relax noninterference) L1L1 L2L2 L3L3 declassify L 3  L 1

9 Password Example Password Checker public query confidential password public result declassification inside

10 Laundering Attack Password Checker public query confidential password leaked secret copy Secret copied into password is leaked! declassification inside

11 Robust declassification Intuition: a system is robust against attackers if declassification only releases information intentionally Goal: –Characterize the end-to-end security of a system containing declassification –Define conditions that prevent unintentional leaks

12 A simple system model A system S is:  is a set of states:  1,  2, …  is a transition relation in 

13 Views view of ( ,  )  : equivalence relation on  Captures what a viewer (user, attacker) can see directly about a state  Generalization of “security level” 

14 Example views "integer component is visible" ("attack at dawn", 3)  I ("retreat", 3) ( x, i )  I ( y, j ) iff i = j ("attack at dawn", 3)   I ("retreat", 4)  = String × Integer ( x, i )   ( y, j ) iff ( x, i ) = ( y, j ) “complete view (no secrets)”

15 Trace equivalence A view induces an observation of a trace:   = ("x",1)  ("y",1)  ("z",2)  ("z",3)   through view  I 1  1  2  3   = ("a",1)  ("b",2)  ("z",2)  ("c",3)   through view  I 1  2  2  3 …these traces are equal modulo stuttering

16 Observational Equivalence observational equivalence : S[  ]  S[  ]  ' if the traces from  look the same as the traces from  ' through the view . 

17 Observational Equivalence observational equivalence : S[  ]  S[  ]  ' if the traces from  look the same as the traces from  ' through the view . S[  ]  S[  ]

18 Secure Systems The view S[  ] captures what can be learned by observing execution of S through view  S is  -secure if  = S[  ] –“Nothing more is learned from observing what the program does” –simple formulation of noninterference Difference between  and S[  ] captures intentional information release when S contains declassification

19 Attacks Passive attack : observation Active attack : modification An  A - attack is a system A = ( ,   ) such that  A = A[  A ]  A : the attacker's view   : a set of additional transitions  A = A[  A ] : “attacker can’t construct attack that uses information he can’t observe”

20 Laundering attack AA AA   password datasecret yes no

21 Laundering attack S[  A ]  S[  A ]   password datasecret yes no

22 Effect of laundering attack  S[  A ]    (S  A)[  A ] Observation of attacked system gives more information: Not robust password datasecret yes no

23 Robustness A system is secure against a passive attack A if S[  A ] =  A A system is robust against an active attack A if (S  A)[  A ]  S[  A ] “The attacker learns at most as much from observing the attacked system as from passive observation”

24 Summary, part 1 Robustness: new building block for characterizing end-to-end system security in presence of declassification and active attack [CSFW01] Next step: formulate static typing rules that enforce robustness (as well as noninterference)

25 Verifying programs Jif program Java program jif bytecode machine code javac JIT Secure? annotations

26 Implicit flows at source level boolean{H} b; boolean{L} x = false ; if (b) { x = true; /* not OK */ } Implicit flow: information carried through control structure Solution: introduce static approximation to implicit flow (pc) –Type of every expression acquires pc boolean{H} b; boolean{L} x = false L ; i f (b) { x = true H ; }

27 Implicit flow in low-level lang. High-level control structures (if, while, switch, function calls, returns)  indirect, direct jumps Less ability to reason about implicit flow Simple rule: pc at target of jump always more secret than at jump instruction –too restrictive –doesn’t handle indirect jumps (return, method call, switch)

28 Loss of precision boolean{H} b; /* pc = L */ boolean{L} x = false L ; /* pc = L */ if (b) { f() } /* pc = H */ x = true L ; /* pc = L */ MOV x, 0; pc = L CMP b, 0; pc = L JZ skip; pc = H CALL f; pc = H skip:MOV x, 1 H ; pc = H High-level: safe Low-level: apparently unsafe

29 Security-typed IL First low-level typed language with support for dynamic control transfers, static information flow control [ESOP’01] Continuations in A-normal form: close to assembly code Linear continuations preserve precision of high-level source analysis : first-class postdominators First proof of language-based enforcement of noninterference (for any language with state and higher-order control) e ::= let x = prim in e | if v then e 1 else e 2 | let x = ref l  v in e | set v 1 := v 2 in e | letlin y = lv in e | goto v 1 (v 2, lv) | lgoto lv 1 v

30 Summary, part 2 Source language can be compiled to a low- level language without loss of precision Next step: information flow verification for machine code

31 Conclusions New practical and theoretical tools for enforcing end-to-end security Language-based approaches (type-checking) leverage progress in PL area for systems issues Next: validation of end-to-end security properties for large systems?