Information Flow, Security and Programming Languages Steve Steve Zdancewic

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

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

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

Outline Lattice-model –Non-interference SLam –Modeling Dependency –Extensions JFlow & Other Approaches Conclusions

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

The Lattice Model Elements represent levels of privilege    ' is ordering      ' is join Bell & LaPadula '75 Denning'75,'76,'77 L H 1111 2222 3333 4444 5555 6666

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

Explicit vs. Implicit low  hi if hi then low  true else low  false

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

Types  b   Security Lattice 

Subtyping   '  '  b  b  '             '             '

SLam Expressions bv  #t | #f | ( x: . e) v  bv  e  x | v | (e e) | (prot  e) | (if e then e else e)

Typing Rules    #t  : (b,  )   ( x:  . e)  : (     ,  )  x:     e :  

Typing Rules II   (e  e  ) :       e  : (     ,  )   e  :    '     '   

Typing Rules III   if e then e  else e  :       e : (b,  )   e i :    e :           e :  

Typing Rules IV   e :    prot  e :  

Example  if #t H then #t L else #f L : (b, L)  H  #t H : (b, H)  #t L : (b, L) (b, L)  H  (b, L  H)  (b, H)  #f L : (b, L)

Operational Semantics (( x:  . e)  e ' )  prot  e[e ' /x] (if #t  then e  else e  )  prot  e  prot  bv  '  bv    '

Proving Non-interference? Suppose lattice is L  H Functions of the type:  b H   b L  b L  L “look” like  b  b

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”

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

Semantics of Types  (b,  )   #t  #f   (     ,  )         p      R  "view of  at level  " R        

View Relations Abstract View:  '   '    R         Concrete View (bool):  '    R  b  '  C

View Relations II Concrete view (functions)  '    R((     ,  '   f,g  x,y  R     f  x ,g  y  R     ' 

Adequacy Theorem (Plotkin): If   e :  then    e :    is defined iff e  *v.

Related Environments  x     x     x n  n                 n  Theorem: Suppose   e :  and  '      are related environments at , then      e :        e :    '  R(  )

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 ' ]

Non-interference Theorem: Suppose    e , e  :  and    C[e  ] :  b  '  where    ' then C[e  ]  C[e  ]. let 

Proof I Consider open term: y:    C[y] :  b  '  d i      e i :    Lemma: Since    ' (d 1, d 2 )  R(  ') Proof: R(  ') is abstract.

Proof II f i   y:    C[y] :  b  '    d i By Related Environments theorem, we have:  f 1, f 2  R  b  '  ')  C Thus, f 1 = f 2, easy to show that f i      v :  b  '    since v  v,we're done.

Recursion Need to show that R 's are "directed complete" Need to finesse termination issues in contexts – y:unit    C[y ()] :  b  '  CBN vs. CBV –Strong vs. Weak non-interference

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.

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

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

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

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

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

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

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

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

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...

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