information flow security and programming languages l.
Download
Skip this Video
Download Presentation
Information Flow, Security and Programming Languages

Loading in 2 Seconds...

play fullscreen
1 / 43

Information Flow, Security and Programming Languages - PowerPoint PPT Presentation


  • 99 Views
  • Uploaded on

Information Flow, Security and Programming Languages. 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

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

PowerPoint Slideshow about 'Information Flow, Security and Programming Languages' - cloris


Download Now An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
what is security
What is Security?
  • Resources?
  • Protection?
  • Trust & Integrity?
  • Policy?
  • Principals?
  • Threats?
information flow
Information Flow
  • Resource = Data
  • Protection = Access Control
  • Threat = Malicious Programs
    • "leak" private information
  • Policy? Principals? Trust?
why do we want it
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
Outline

La.a->t

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

SLam

JFlow

principals privileges
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

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

non interference
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

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

k  Security Lattice

t ::= b | s  s

s ::= (t, k)

subtyping

kk'

(b, k)  (b, k')

s3  s1 s2  s4 kk'

(s1  s2, k)  (s3  s4, k')

Subtyping
slam expressions
SLam Expressions

bv ::=#t | #f | (lx:s. e)

v ::= bvk

e ::= x | v | (e e) | (protk e)

| (if e then e else e)

typing rules

G, x:s1 e : s2

G (lx:s1. e)k : (s1 s2, k)

Typing Rules

G #tk : (b, k)

typing rules ii

G e1 : (s1 s2, k) G e2 : s1

G (e1 e2) : s2 k

Typing Rules II

(t, k')k = (t, k' k)

typing rules iii

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
typing rules iv
Typing Rules IV

G e : s

G protk e : s k

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

operational semantics
Operational Semantics

((lx:s1. e)k e')  protk e[e'/x]

(if #tk then e1 else e2)  protk e1

protk bvk'  bvk k'

proving non interference
Proving Non-interference?
  • Suppose lattice is LH
  • Functions of the type:

(bHbL bL)L

“look” like

a. a bb

modeling views
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

Binary Relations as Views

If (x,y)R then x and y

"look the same".

semantics of types
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

view relations
View Relations
  • Abstract View:

s = (t, k')

k' k R(s, k) = s  s

  • Concrete View (bool):

k' k R((b,k'), k) = C

view relations ii
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)}

adequacy
Adequacy
  • Theorem (Plotkin):

Ife : sthen e : shis defined iff e *v.

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

contexts equivalence
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 interference29
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)

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

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

recursion
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
extending slam
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
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.
recap
Recap
  • SLam provides language based information-flow protection
  • Non-interference proved by logical relations
  • ...but you wouldn't want to program in it.
jflow
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
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 interference38
Non-Interference?
  • Too strong:
    • No encryption
    • No password lookup
  • Need declassification
    • Everything ends up at H
  • Hard to define in concurrent setting
alternatives
Alternatives?
  • What you really care about is leakage of "useful" information?

...or...

  • What you care about is the rate of leakage of information?
problems
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
Covert Channels
  • Threads/Concurrency
  • Timing attacks
  • Probabilistic attacks
  • "Semantic" channels - i.e. order of initialization, aliasing
  • and more...
conclusions security
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
Conclusions (PL)
  • Non-interference expressed in terms of dependency
    • Polymorphism, Binding Time Analysis, Slicing
  • Denotational techniques useful
  • Still lots to be done...