Enforcing Confidentiality in Lowlevel Programs Andrew Myers Cornell

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

End-to-end security? • • Complex computations, untrusted components Security mechanisms: access control encryption static verification • firewalls digital signing mandatory controls Security guarantees: limited, not compositional 2

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 3

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 H 1 L 1 H 3 L 1 L H 2 L 2 H 4 L 2 4

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{L 1} x; int{L 2} y; x = y; requires L 2 L 1 Also need program-counter label to catch implicit flows 5

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 – 6 k semis – Nate Nystrom, Lantian Zheng, Steve Zdancewic 6

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

Declassification • Declassification (downgrading) : reduction of the confidentiality level of data • Allows the intentional release of confidential information (relax noninterference) L 1 L 3 L 1 declassify L 3 L 2 8

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

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

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 11

A simple system model • A system S is: S is a set of states: s 1, s 2, … is a transition relation in S S 12

Views • • • view of (S, ) : equivalence relation on S Captures what a viewer (user, attacker) can see directly about a state s Generalization of “security level” 13

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

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

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

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

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 18

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

Laundering attack A A secret A yes A no password data 20

Laundering attack A S[ A] secret A yes S[ A] no password data 21

Effect of laundering attack A (S A)[ A] secret A yes S[ A] no password data Observation of attacked system gives more information: Not robust 22

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” 23

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

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

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; if (b) { x = true. H; } 26

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) 27

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

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 e : : = let x = prim in e | if v then e 1 else e 2 • First proof of language-based | let x = refls v in e enforcement of noninterference | set v 1 : = v 2 in e (for any language with state and | letlin y = lv in e higher-order control) | goto v 1 (v 2, lv) | lgoto lv 1 v 29

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

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