Transcript Enforcing Confidentiality in Low
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 H1 L1 H3 L1 L H2 L2 H4 L2 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 restrictive as L 1 int{L1} x; is at least as int{L2} y; x = y; requires L2 L1 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 – 6k semis – Nate Nystrom, Lantian Zheng, Steve Zdancewic 6
Challenges
1.
• Real computations must leak information must go beyond noninterference •
robust declassification
2.
• Enforcement for low-level programs
first-class linear control
3.
4.
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 2 L 3 8
Password Example
declassification inside
public query confidential password Password Checker public result 9
Laundering Attack
declassification inside
public query 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 SS 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 "integer component is visible" i = j ("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 t 1 = ("x",1) ("y",1) ("z",2) ("z",3) through view I 1 1 2 3 t 2 t 2 = ("a",1) ("b",2) ("z",2) ("c",3) through view I 1 2 2 3 …these traces are equal modulo stuttering 15
Observational Equivalence
observational equivalence : S[ ] s 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 S[ ] s ' if the traces from as the traces from s ' s look the same through the view .
S[ ] 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[ intentional information release when S contains declassification ] captures 18
Attacks
• • Passive attack : observation Active attack : modification An A attack is a system such that A A = ( S , A ) = A[ A ] A A A : the attacker's view : a set of additional transitions = A[ A ] : “attacker can’t construct attack that uses information he can’t observe” 19
Laundering attack
A A A secret A password data yes no 20
Laundering attack
S[ A ] A A S[ A ] secret password data yes no 21
Effect of laundering attack
A (S A)[ A ] A S[ A ] yes no secret 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 [CSFW01] Next step: formulate static typing rules that enforce robustness (as well as noninterference) 24
Verifying programs
Jif program jif Java program annotations javac bytecode JIT annotations machine code annotations
Secure?
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 i f (b) { x = true H ; } = false L ; 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 ; /* pc = L */ /* pc = L */ /* pc = H */ /* pc = L */ High-level: safe MOV x, 0 CMP b, 0 JZ skip CALL f skip: MOV x, 1 H ; pc = L ; pc = L ; pc = H ; pc = H ; pc = 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 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
s v in e | set v 1 | goto v := v | letlin y = lv in e 1 | lgoto lv 1 (v
v
2 2 in e , lv) 29
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 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