Information Flow, Security and Programming Languages

1. Information Flow, Security and Programming Languages Steve Zdancewic

2. What is Security? • Resources? • Protection? • Trust & Integrity? • Policy? • Principals? • Threats?

3. Information Flow • Resource = Data • Protection = Access Control • Threat = Malicious Programs • "leak" private information • Policy? Principals? Trust?

4. Why Do We Want It? • Untrusted code • Applets/Plugins/Extensible Systems • E-Commerce & Privacy • Shared Resources • Files on a network • Access Control (i.e. Unix permissions) not enough

5. Outline La.a->t • Lattice-model • Non-interference • SLam • Modeling Dependency • Extensions • JFlow & Other Approaches • Conclusions SLam JFlow

6. Principals & Privileges • Associate security levels with data • Specifies who can "see" the data • What happens when data is merged? x = a +b

7. k1 k2 k3 The Lattice Model • Elements represent levels of privilege • kk'is ordering • kk' is join • Bell & LaPadula '75 Denning'75,'76,'77 H k4 k5 k6 L

8. Non-Interference • Low security data can't depend on high security data. • No information flows from high security values to low security ones.

9. low := hi if hi then low := true else low := false Explicit vs. Implicit

10. SLam • Heintze & Riecke POPL '98 • Lambda Calculus • Security annotations on types • Well-typed programs have non-interference property • Proof uses logical relations

11. Types k  Security Lattice t ::= b | s  s s ::= (t, k)

12. kk' (b, k)  (b, k') s3  s1 s2  s4 kk' (s1  s2, k)  (s3  s4, k') Subtyping

13. SLam Expressions bv ::=#t | #f | (lx:s. e) v ::= bvk e ::= x | v | (e e) | (protk e) | (if e then e else e)

14. G, x:s1 e : s2 G (lx:s1. e)k : (s1 s2, k) Typing Rules G #tk : (b, k)

15. G e1 : (s1 s2, k) G e2 : s1 G (e1 e2) : s2 k Typing Rules II (t, k')k = (t, k' k)

16. G e : (b, k) G ei : s G if e then e1 else e2 : sk G e : s1 s1 s2 G e : s2 Typing Rules III

17. Typing Rules IV G e : s G protk e : s k

18. Example #fL : (b, L) #tH : (b, H) #tL : (b, L) if #tH then #tL else #fL : (b, L)H (b, L)H = (b, L  H) = (b, H)

19. Operational Semantics ((lx:s1. e)k e')  protk e[e'/x] (if #tk then e1 else e2)  protk e1 protk bvk'  bvk k'

20. Proving Non-interference? • Suppose lattice is LH • Functions of the type: (bHbL bL)L “look” like a. a bb

21. Modeling “Views” • Give a denotational semantics for Slam • Instead of just CPO’s, also include binary relations to capture the “view” • Functions must preserve the “view”

22. Concrete View C#t #f #t 1 0 #f 0 1 Abstract View A#t #f #t 1 1 #f 1 1 Binary Relations as Views If (x,y)R then x and y "look the same".

23. Semantics of Types (b, k) = {#t, #f} (s1 s2, k) = s1 ps2 R(s, k) = "view of s at level k" R(s, k)  s  s

24. View Relations • Abstract View: s = (t, k') k' k R(s, k) = s  s • Concrete View (bool): k' k R((b,k'), k) = C

25. View Relations II • Concrete view (functions) k' k R((s1 s2, k'), k) = {(f,g) | "(x,y)R(s1,k). (f(x),g(y)) R(s2 k',k)}

26. Adequacy • Theorem (Plotkin): Ife : sthen e : shis defined iff e *v.

27. Related Environments • G = x1:s1, x2:s2, ... , xn:sn G = s1 s2 ... sn • Theorem: Suppose Ge : s and h, h' G are related environments at k, then (Ge : s h, Ge : s h') R(s,k)

28. Contexts & Equivalence • C[ ] is a context (expression with hole) • Write e e' if whenever e*v and e'*v'it is the case that v=v' • C[e]  C[e']

29. Non-interference • Theorem: Suppose e1, e2 : (t, k) and C[e1] : (b,k') where k  k' then C[e1]  C[e2]. let s = (t,k)

30. Proof I • Consider open term: y:sC[y] : (b,k') • di = ei : s() • Lemma: Since k  k' (d1, d2)  R(s, k') Proof: R(s,k') is abstract.

31. Proof II • fi= y:sC[y] : (b,k') di • By Related Environments theorem, we have: (f1,f2)  R((b,k'), k') = C • Thus, f1=f2, easy to show that fi= v : (b,k')() since vv,we're done.

32. Recursion • Need to show that R's are "directed complete" • Need to finesse termination issues in contexts • y:units C[y ()] : (b,k') • CBN vs. CBV • Strong vs. Weak non-interference

33. Extending SLam • Products, Sums, Recursive Types (Pitts '96) • State • “No read up, no write down” • Globally track dependency • Integrity • The more people who touch data, the less trustworthy it is.

34. Core Calculus of Dependency • Abadi, Banerjee, Heintze, Riecke (POPL '99) • Use type constructors Tk • Can translate SLam, Binding-time calculi, Smith&Volpano's calculi, etc., into DCC.

35. Recap • SLam provides language based information-flow protection • Non-interference proved by logical relations • ...but you wouldn't want to program in it.

36. JFlow • Myers (POPL ‘99) • Emphasis on usable language • Java extension • Decentralized label model • Very large, fine grained lattice • Security level polymorphism • First class labels, principals

37. Threads & Concurrency • Smith & Volpano (POPL '98) • Simple, imperative language with threads • Can't loop on high-variables • Assumes non-deterministic thread scheduling • Clock is high-security • Subject to Probabilistic attacks

38. Non-Interference? • Too strong: • No encryption • No password lookup • Need declassification • Everything ends up at H • Hard to define in concurrent setting

39. Alternatives? • What you really care about is leakage of "useful" information? ...or... • What you care about is the rate of leakage of information?

40. Problems • Compilation in information-flow setting: • Compiler should preserve flow properties • CPS translation/code-motion not valid: • f (if x then y else z) (if x then f(y) else f(z))

41. Covert Channels • Threads/Concurrency • Timing attacks • Probabilistic attacks • "Semantic" channels - i.e. order of initialization, aliasing • and more...

42. Conclusions (Security) • Information flow is a useful tool for security. • Non-interference is a strong policy (too strong?) • Programming language technology can help • Lots left to be done...

43. Conclusions (PL) • Non-interference expressed in terms of dependency • Polymorphism, Binding Time Analysis, Slicing • Denotational techniques useful • Still lots to be done...