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 U1 and U2”
End-to-end integrity policy:
“This information is trusted and should only be
affected by users U1 and U2”
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
L1  L2 means policy L2 is at least as
restrictive as L1
int{L1} x;
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
•
•
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)
L1
L3 L1 declassify
L3
L2
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: s1, s2, …
 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:
t1 = ("x",1)("y",1)("z",2)("z",3)
t1 through view I
1123
t2 = ("a",1)("b",2)("z",2)("c",3)
t2 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 s look the same
as the traces from s' 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[] 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
[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
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 = falseL;
if (b) { x = trueH; }
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 = falseL;
if (b) { f() }
x = trueL;
MOV x, 0
CMP b, 0
JZ skip
CALL f
skip: MOV x, 1H
; pc
; pc
; pc
; pc
; pc
/* pc
/* pc
/* pc
/* pc
=L
=L
=H
=H
=H
= L */
= L */ High-level: safe
= H */
= L */
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 e1 else e2
• First proof of language-based
| let x = refls v in e
enforcement of noninterference
| set v1 := v2 in e
(for any language with state and
| letlin y = lv in e
higher-order control)
| goto v1 (v2, lv)
| lgoto lv1 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