Programming Language Semantics for Secure Information Flows

1. How to Cook a Secure Semantics Mohammad Mousavi TU/Eindhoven SOS 2010, Paris (Based on joint work with Doaa Hassan, Michel Reniers and Jerry den Hartog)

2. Outline • Motivation • Warming up: A toy language • Language-Based Security • Extension to Delegation and Revocation • Secure Flow Properties • Conclusions

3. Motivation

4. Revocation • Alice visits a bookshop and buys a gift for Carol • Alice authorizes Bob (the Shopkeeper) to access her credit card information • the purchase transaction is completed and Alice leaves the shop • Bob tries to use Alice’s credit card information to buy a Rolex watch

5. Restricted Delegation • Bob (the patient) visits Alice (the physician) • Bob gives Alice access to his clinical record • Bob agrees to give Chuck (the specialist) access if Alice deems necessary • Alice delegates her access permission to Chuck • Chuck delegates his permissions to the insurance company

6. Our Order of Business Understand semantic issues involved in programming languages for • guaranteeing end-to-end information flow security • allowing for restricted delegation and revocation

7. Semantics

8. Mathematicians are like Frenchmen;whatever you say to themthey translate it into their own language and forthwith it is something totally different.Goethe

9. Syntax and Semantics Syntax Multiple Levels Semantics Semantic Domain Mathematical Objects → Formal Semantic (e.g., Sets, Relations, Lists, Functions)

10. A Simple Programming Language • Prog ::= VarDecl* Statement* • VarDecl ::= Type Var [= Val] ; • Statement ::= Var= Exp ;| if Exp then Body else Body fi ; while Exp do Body od;

11. Operational Semantics: Big Step Assumption: Variables are properly declared before use.

12. Operational Semantics: Big Step

13. Operational Semantics: Big Step

14. Is My Semantics Correct? Semantics: • is a definition; • is a choice; • can be counter-intuitive; • may have/lack interesting properties. To build confidence: • Simulate Programs; • Prove Properties of the Semantics

15. Information Flow Security

16. Information-Flow Security • Confidentiality: only good guys learn about secrets • Integrity:only good guys influence trusted content • Language-based security: guarantee security by providing / analyzing syntactic constructs See: A. Sabelfeld and A.C. Myers. Language-Based Information-Flow Security. IEEE Journal on Selected Areas in Communications. 21(1), 2003.

17. Principals • Principals: Alice, Bob, Employees, Managers • Have a hierarchy: Alice is a manager, each manager is an employee • Form a lattice by defining their meet and join

18. Policies • Policy: owner’s definition of confidentiality and integrity • int {Alice: Bob} x;Alice is the owner and allows Bob to read x • int {Alice : !Bob} x; Alice is the owner and allows Bob to write to x (Alternatively: Alice is the owner and only trusts the values written by herself or by Bob) See: P. Li, Y. Mao and S. Zdancewic, Information Integrity Policies. In Proc. of FAST 2003.

19. Labels • Labels: policies arranged in a lattice with join and meet • int {Alice: Bob, John} {Chuck: Bob} x; • Equipped with order (“less restrictive than” ): • more readers for confidentiality • less writers for integrity See: A. Myers and B. Liskov. Protecting Privacy using the Decentralized Label Model. ACM TOSEM 9(4): 410-442, 2000.

20. What to Label • Values: define policies for data items • Variables: define policies for containers

21. Static vs. Dynamic Flow Analysis • Static: Check at compile time whether flow conforms to policies Efficient, but over-estimates • Dynamic: Check at run-timeAccurate (potentially), but has overhead

22. A Simple Programming Language • Prog ::= VarDecl* Statement* • VarDecl ::= Type Var [= Val] ; • Label ::= Policy* • Policy ::= Principal [ : ([!]Principal)* ] • Statement ::= Var= Exp ; | if Exp then Body else Body fi ; while Exp do Body od; [ { Label } ]

23. Typical Issues in Information-Flow-Sensitive Semantics • Assignment: the label of the assigning expression is more restrictive than the static label of the assigned variablebool {Alice:Alice} x; bool {Alice:Alice,Bob} y; y = x; {Alice:Alice,Bob} {Alice:Alice}

24. Operational Semantics: Big Step (explicit flow)

25. Operational Semantics: Big Step

26. Typical Issues in Information-Flow-Sensitive Semantics • Assignment: the label of the assigning expression is more restrictive than the static label of the assigned variable • Conditional: check for implicit flowsbool {Bob: Bob} x; bool {Alice: Alice} y; if x then y = true; else y = false; fi; PC {ᴛ} PC {Bob} {Alice} ᴛ {Bob} {Alice} {Bob} ᴛ Solution: add a fictitious variable PC which: - is influenced by the condition - influences the body of conditional See: D. Molnar, M. Piotrowski, D. Schultz, and D. Wagner. The program counter security model: Automatic detection and removal of control-flow side channel attacks. In Proc. of ICISC 2005.

27. Operational Semantics: Big Step (implicit flows)

28. Operational Semantics: Big Step (implicit flows)

29. Operational Semantics: Big Step (implicit flows)

30. Typical Issues in Information-Flow-Sensitive Semantics • Assignment: the label of the assigning expression is more restrictive than the static label of the assigned variable • Conditionals: check for implicit flows • Loops: check for implicit flows / termination covert channel bool {Bob: Bob} x=true; bool {Alice: Alice} y=false; …while x do x = true; od ; y = true;

31. Typical Issues in Information-Flow-Sensitive Semantics • Termination Covert Channel: Bad guys cannot learn about secret data by observing terminationSolution: Only allow for loops with the maximal (least secret) label in: • the PC and • the condition • Weak termination covert channel: possible (non-)termination due to secret data does not lead to anything observable on the public dataSolution: small-step semantics: propagate the updated PC along the computation

32. Is My Semantics Correct? (Recap) Semantics: • is a definition; • is a choice; • can be counter-intuitive; • may have/lack interesting properties. To build confidence: • Simulate Programs; • Prove Properties of the Semantics

33. Non-Interference Changing the initial secret data does not influence the final public data

34. Termination-Sensitive Non-Interference Changing the initial secret data does not influence the termination and the final public data

35. Theorem Our semantics is secure: if P can make a big step, then it is non-interfering

36. Type Systems for Information-Flow

37. Theorem If P is well-typed, then it can make a big step. What about only if? bool {Bob: Bob} x=true; bool {Alice: Alice} y=false; if x then x = 0 else x = y; od ;

38. Delimited Information Release

39. Delegation and Revocation

40. Introducing Delegation and Revocation • Prog ::= VarDecl* Statement* • VarDecl ::= Type Var [ { Label } ][= Val] ; • Label ::= Policy* • Policy ::= Principal [ : ([!]Principal)* ] • Statement ::= Var= Exp ; | if Exp then Body else Body fi ; while Exp do Body od;Principal delegates Var (? |! |(?,!) ) Chain ; Principal revokesVar ( ?| ! |(?,!) ) Chain ; • Chain ::= Principal | Principal → Chain

41. Semantics of Delegation • Add dynamic labels: how far the delegation chain (for each owner) has reached Alice delegates x ? Bob -> Chuck Alice : Bob -> Chuck Bob delegates x ? Chuck 0 1

42. Operational Semantics: Big Step (delegation) See: N. Swami, M. Hicks, S. Tse, and S. Zdancewic. Managing Policy Updates in Security-Typed Languages. In Proc. of CSFW 2006.

43. Typical Issues in Information-Flow-Sensitive Semantics • Assignment: the join of the static and dynamic label of the assigning expression is more restrictive than the join of the static and dynamic label of the assigned variable

44. Operational Semantics: delimited information release (first attempt)

45. Typical Issues in Information-Flow-Sensitive Semantics • Assignment: the join of the static and dynamic label of the assigning expression is more restrictive than the join of the static and dynamic label of the assigned variable bool {Bob: Bob} x=true; bool {Alice: Alice} y=false; bool {Chuck: Chuck} z=true; Alice delegates y ? Bob x = y; Bob delegates x ? Chuck z = x;

46. Operational Semantics: delimited information release (second attempt)

47. Operational Semantics: Big Step (delegation-revisited)

48. Semantics of Revocation • Revocation by an owner: remove the (part of) delegated dynamic label Alice delegates x ? Bob -> Chuck Bob delegates x ? Chuck Alice : Bob Alice revokes x ? Chuck -> Chuck 0 1

49. Semantics of Revocation • Revocation by a grantor: push the delegation index back Alice delegates x ? Bob -> Chuck Bob delegates Chuck Alice : Bob -> Chuck Bob revokes x * Chuck 0 1

50. Operational Semantics: Big Step (revocation)