Information Flows Analysis

1
Information Flows Analysis VSR

• Ganesh M. Narayan
• CASL

2
Agenda

• Protecting data
• Information Flow
• Policies Mechanisms
• VSR in Information flow
• Conclusions

3
Protecting Data

• How do I prevent any information leak ?
• or
• How do I enforce end-to-end security ?

4
Protecting Data

• Protecting secret/private information in
  computer systems is a well known and long
  standing problem
• Cryptographically secured secret
• Access controls to limit who sees what

5
Achilles Heel

• But these mechanisms are insufficient
• Access control does not prevent propagation of
  information
• Can not feasibly compute over encrypted data
• Clear text, but ought to control the flow of
  information

6
Information Flow

• Confidentiality (secrecy, privacy)
• Making sure information is not released
  improperly
• Identify information flows
• Integrity
• Making sure information only comes from right
  places
• Identify dependencies information flows

?
?
7
Information Flow

• Idea tag secret information and track
• how it is used by the system
• Tag the data Security Types
• Analysis determine whether program leaks
  information Consistency/Typability

8
Secure Information Flow

• Goal enforcement of end-to-end
• information security properties. Must
• track information flows dependencies

Secret
Public
9
Noninterference

• Low-security behavior of the program is not
  affected by any high-security data

?
?
Confidentiality high confidential,
low public Integrity, Availability low
trusted, high untrusted
10
Jif lt Java Information Flow

• Program types include security labels
• intL x // type of x is intL
• intsecret x
• intpublic y
• yx // not ok if secret ? public
• Jif statically checks information flows

11
Labels as Policy Language

• Labels as a policy language
• Principal
• Whose security is being enforced?
• Who can compromise security?
• Policy
• A restriction on the use of some information
• Pertains to a specific aspect of security
• Policy has form o t where
• o is the owner of the policy (a principal)
• t is the trustee of the policy (a principal)
• Label
• Combined policies governing an information
  resource

12
Labels

• Label is a set of zero or more policies
• label -gt o1 r1, r2 o2 r4
• Policies may govern different security aspects
• All policies equally enforced
• Lattice ordering ? is lifted from policy ordering
  
• Flow from l to l allowed when l ? l
• ...
• Confidentiality label
• intAlice a1 // a1 is Alices private int
• Integrity label
• int Alice a2 // Alice trusts a2
• Combined Labels
• intAlice Alice a3

13
Principal Hierarchy

• Delegations
• Directed graph, edges represent actsFor relation
• Taken as an input parameter by the type checker
• Affect the interpretation of labels
• Need to be explicitly consulted at runtime
• Changes rare and well defined

14
Good News

• Static label checking is type checking in a
  security type system
• Decidable, efficient witnesses
• Little or no run-time overhead
• constraint solving labels erased
• Compositional!

15
But, for VSR? - nCm

• Non interference is too restrictive
• One may not even be able to check the validity
  of the secret!
• let valid (if valid_syntax(dec(secret)) 1 0)
• Information should dribble, not leak
• Little or no assurance for declassification in
  most security-typed languages
• Gets trickier with VSR!
• public declassify (lag(s0 s1 s3 sm-2,
  m))
• secret declassify (lag(s0 s1 s3 sm-1, m))

16
nCm

• Static Analysis
• Analyses are conservative potential
  interference
• even if the desired system is noninterfereing it
  does not necessarily pass the test
• Type Systems need to distinguish roles
• Redistribution will kill the previous
  instance
• view sensitivity?
• ? valid si secret lag(s0 s1 s3 sm-1, m)
• ? invalid si public lag(s0 s1 s3 sm-1,
  m)

17
nCm

• Policies are not static
• Labels
• Encryption could make the data public, Decryption
  would do the reverse
• m shares would make data private!
• Principles
• Authentication, Verified Share lt m, Verified
  Share m, Trust
• Principle Hierarchy
• Principles may join or leave the system!

18
Information Flow proposal for VSR

• Relaxed form of non-interference
• Global property ratifies the entire evaluation
• let x intp2 (if (p1 p2) 1p1 3p2) in if (
  p2 p3) x 2p3
• Assume ?1 p1 p2, ?1 ? x intp2
• ?2 p2 p3, ?2 ? x intp2
• Neither of them are valid in ?1 ?2 !
• need to be tied to the notion of present
  context in VSR
• View sensitive non interference ?

19
Information Flow proposal for VSR

• Type Systems
• Natural security types are not expressive enough
• Cryptographic types Enc, Plain, Auth, Verified
• Dependent Types
• Types indexed/parameterized by term
• The witness is undecidable, in general
• let lst2 (if (null lst) (tail lst) lst)
• S ? T generalizes to ?x S ? T
• Dependency on m, auth, verify
• Invariants can be maintained, enforced
  exploited
• Dynamic
• Type information at runtime safe coersions

20
Information Flow proposal for VSR

• Safe Declassification
• Reasoning with Dependent Crypto Types
• Declassification over views
• Can declassification be safe?
• Handling Type directed covert channels
• Protecting programs from types using types
• Exceptions, sum types, pc/scope/context typing

21
Questions?
22
Jif Downgrading

• Declassify (confidentiality)
• intBob Alice x
• Y declassify (x, Bob Alice to Alice)
• Endorsement (integrity)
• intBob x
• y endorse (x, Bob to Bob Alice)