1 / 58

How to Cook a Secure Semantics

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). Outline. Motivation Warming up: A toy language Language-Based Security Extension to Delegation and Revocation

gaura
Download Presentation

How to Cook a Secure Semantics

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. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  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)

More Related