Language-Based Information-Flow Security

1. Language-Based Information-Flow Security Andrei Sabelfeld Andrew C. Myers Presented by Shiyi Wei

2. About the paper • Literature review • Information flow security • Static program analysis to enforce information-flow • Confidentiality • Year: 2003 • Jif (Java information flow) project • Active since 1997 • More than 34 publications • System, language, security • SOSP, POPL, CCS, Oakland • Other work based on Jif

3. Overview • Introduction • Background • Covert channels • Mandatory access control • Basics of language-based information flow • Research trends • Open challenges

4. Introduction • Protect data confidentiality • End-to-end security • Enforcement of confidentiality policies • Information cannot flow to where policy is violated • Challenges • Concurrency • Covert channels • Applications • Military, medical, financial information systems • Web-based services: mail, shopping, social network

5. Introduction • Standard security mechanisms • Discretionary access control • Access files/objects based on privilege • Prevent processes not authorized by file owner from reading • Place restrictions on the release of information, but not its propagation • Does not control how the data is used after reading from file • To soundly enforce confidentiality • Grant access privilege only to processes that will not leak confidential data • A much stronger information-flow policy! • Access control cannot identify these processes

6. Introduction • Standard security mechanisms • Encryption • Secure an information channel • Only the communicating endpoints have access • However, no assurance that once the data is decrypted • Antivirus software • Offers limited protection against new attacks • Firewall • Protects confidentiality by preventing communication • Checking confidentiality violation lies outside its scope

7. Introduction • Language-based approach • security-typed language • Use of type systems for information flow • Augmented with annotations • Specify policies on the use of the typed data • Compile-time type checking • Add little or no run-time overhead • E.g. Jif[1], SLam calculus[2], … References [1] A.C.Myers and B. Liskov, “A decentralized model for information flow control,” in Proc. ACM Symp. on Operating System Principles, Oct. 1997, pp. 129-142 [2] N. Heintze and J. G. Riecke, “The Slam calculus: programming with secrecy and integrity,” in Proc. ACM Symp. on Principles of Programming Languages, Jan. 1998, pp. 365-377

8. Introduction • Integrity: a dual to confidentiality • “Confidentiality requires that information be prevented from flowing to inappropriate destinations” • “Integrity requires that information be prevented from flowing from inappropriate sources”

9. Background: Covert Channels • Implicit flows • Signal information through the control structure of a grogram • Termination channels • The termination/nontermination of a computation • Timing channels • Signal information through the time at which an action occurs rather than through the data • E.g. total execution time of a program while secret=1 do skip

10. Background: Covert Channels • Probabilistic channels • Signal information by changing the probability distribution of observable data • Resource exhaustion channels • Signal information by the possible exhaustion of a finite, shared resource • Power channels • Signal information in the power consumed by the computer

11. Background: Mandatory Access control • Mandatory access control • Label each data with a security level • Run-time enforcement mechanism • Problem: implicit flow • Process sensitivity label • Label creep • Monotonically increase label • Too restrictive h := h mod 2; l := 0; if h = 1 h := h mod 2; l := 0; if h = 1 then l :=1 else skip l := 1 skip

12. Basics of Language-Based Information Flow • Noninterference policy • “a variation of confidential(high) input does not cause a variation of public(low) output” • The attacker cannot observe any difference between two executions that differ only in their confidential input • Security-type system • A collection of typing rules • Let’s build one!

13. Basics of Language-Based Information Flow Language syntax: C ::= skip | var:= exp | C1;C2 | if exp then C1 else C2 | while exp do C

14. Basics of Language-Based Information Flow Language syntax: C ::= skip | var:= exp | C1;C2 | if exp then C1 else C2 | while exp do C := := := :=

15. Basics of Language-Based Information Flow C ::= skip | var:= exp | C1;C2 | if exp then C1 else C2 | while exp do C • if then else • if then else • if then else • if then else • if then else • if then else • if then else • if then else

16. Basics of Language-Based Information Flow Language syntax: C ::= skip | var:= exp | C1;C2 | if exp then C1 else C2 | while exp do C

17. Research Trends static certification noninterference sound security analysis expressiveness concurrency covert channels security policies

18. Language Expressiveness static certification noninterference procedures sound security analysis functions exceptions objects concurrency covert channels security policies expressiveness

19. Language Expressiveness • Procedures • Polymorphism[3] • The type of commands or expressions may be generic • Functions • Slam calculus[4] • A functional language References [3] D. Volpano and G. Simth, “A type-based approach to program security,” in Proc. TAPSOFT’ 97. Apr. 1997, vol. 1214 of LNCS, pp. 607-621 [4] N. Heintze and J. G. Riecke, “The Slam calculus: programming with secrecy and integrity,” in Proc. ACM Symp. on Principles of Programming Languages, Jan. 1998, pp. 365-377

20. Language Expressiveness • Exceptions • Nonlocal transfer of control; implicit flow • Path labels[5] • Fine-grained tracking of implicit flows caused by exceptions • Objects • Java-like imperative object-oriented language[6] • JFlow[5] References [5] A. C. Myers, “JFlow: Practical mostly-static information flow control,” in Proc. ACM Symp. on Principles of Programming Languages, Jan. 19999, pp. 228-241 [6] A. Banerjee and D. A. Naumann, “Secure information flow and pointer confinement in a Java-like language,” in Proc. IEEE Computer security Foundations Workshop, June 2002, pp. 253-267

21. Concurrency static certification noninterference sound security analysis non-determinism threads distribution covert channels security policies expressiveness concurrency

22. Concurrency • Nondeterminism • Possibilistic security condition[7] • High inputs may not affect set of possible low inputs • Dependence analysis between variables[8] References [7] J. McLean, “A general theory of composition for a class of “possibilistic” security properties,” IEEE Transactions on Software Engineering, vol. 22, no. 1, pp. 53-67, Jan. 1996 [8] J. –P. Banatre, C. Bryce, and D. Le Metayer, “An approach to information security in distributed systems,” in Proc. European Symp. on Research in Computer Security. 1994, vol. 875 of LNCS, pp. 55-73, Springer-Verlag.

23. Concurrency • Thread concurrency • High part has to be protected at all times • Noninterference for a multithreaded language[9] • No while loop may have a high guard • No high conditional may contain a while loop in branch • Encode of a timing leak into a direct leak (thread1) h := 0; l := h; (thread2) h := h’ (if h = 1 then Clongelse skip); l :=1 || l := 0 References [9] G. Simth and D. Volpano, “Secure information flow in a multi-threaded imperative language,” in Proc. ACM Symp. on POPL, Jan. 1998, pp. 355-364

24. Concurrency • Distribution • The ability to exchange messages • These communications may be observed by attackers • Mutual distrust • Components can fail • Attempt to compromise the behavior of others • Secure program partitioning[10] • Sequential, security-typed program -> fine-grained communicating subgrams References [10] S. Zdancewic, L. Zheng, N. Nystrom, and A.C. Myers, “Untrusted hosts and confidentiality: Secure program partitioning,” in Proc. ACM Symp. on Operating System Principles, Oct. 2001, pp. 1-14

25. Covert Channels static certification noninterference sound security analysis termination timing probability security policies covert channels expressiveness concurrency

26. Covert Channels • Termination channels • Termination-sensitive noninterference[11] • Disallows high loops and requires high conditionals have no loops in the branches • Binding-time analysis[12] • Divides program terms into • Static: known at partial-evaluation time • Dynamic: to be supplied later • No static term depends on a dynamic variable while h = 1 do skip References [11] D. Vlpano and G. Smith, “Eliminating covert flows with minimum typings,” Proc. IEEE Computer Security Foundations Workshop, pp. 156-168, June 1997 [12] M. Abadi, A. Banerjee, N. Heintze, and J. Riecke, “A core calculus of dependency,” in Proc. ACM Symp. on Principles of Programming Languages, Jan. 1999, pp. 147-160

27. Covert Channels • Timing channels • Timing-sensitive noninterference[13] • High conditionals have no loops in the branches and wrapping each high conditional in a protect statement whose execution is atomic • Program transformation[14] • Cross-copy of the slices of the branches of a high if to equalize the execution time of the branches if h = 1 then Clongelse skip References [13] D. Volpano and G. Smith, “Probabilistic noninterference in a concurrent language,” J. Computer Security, vol. 7, no. 2-3, pp. 231-253, Nov. 1999 [14] J. Agat, “Transforming out timing leaks,” in Proc. ACM Symp. on Principles of Programming Languages, Jan. 2000, pp. 200-214

28. Covert Channels • Probabilistic channels • Probabilistic noninterference • Two behaviors are indistinguishable by the attacker iff the distribution of low output is the same • Example • []p: probabilistic choice operator • Selects the left-hand side command with the probability p • Selects the right-hand side with the probability 1-p • Varying PIN does not change set of possible outcomes • Secure for possibilistic condition l := PIN []9/10l := rand(9999)

29. Security Policies static certification noninterference declassification sound security analysis admissibility relative security quantitative security covert channels security policies expressiveness concurrency

30. Security Policies • Noninterference rejects downgrading • Decentralized model[1] • Selective declassification • Admissibility[15] • Explicitly states what dependencies between data are allowed in the program • Quantitative security[16] • Allow for a limited bandwidth of information leaks References [15] M. Dam and P. Giambiagi, “Confidentiality for mobile code: The case of a simple payment protocol,” in Proc. IEEE Computer Security Foundations Workshop, July 2000 [16] D. Clark, S. Hunt, and P. Malacaria, “Quantitative analysis of the leakage of confidential data,” in QAPL 2011.

31. Open Challenges • System-Wide Security • Computer systems are only as secure as their weakest point • Integration of language-based information flow and system-wide information-flow control • Certifying Compilation • Secure information flow of low-level languages • Useful information about program structure is lost

32. Open Challenges • Abstraction-violating attacks • The model of the attacker is an abstraction • Removes possibly important details about real attacker • E.g. cache attack • When h = 1, execution time is likely to be shorter • Dynamic Policies • Information-flow policies are not known statically • E.g. Jif compiler • Type label (if h =1 then h’ := h1 else h’ := h2); h’ := h1

33. Open Challenges • Practical issues • Improve the precision of type systems • Do not reject too many secure programs • Experience is needed • Variations of static analysis for security • Control- and data-flow analysis • More accurate than many type systems • E.g. (if h = 1 then l := 1 else l:= 0); l := 0