Restricted Delegation and Revocation in Language-Based Security

1. Restricted Delegation and Revocation in Language-Based Security Mohammad Mousavi TU/Eindhoven ÉcolePolytechnique,May 2010 (Based on joint work with Doaa Hassan and Michel Reniers)

2. Outline • Motivation • Language-Based Security: General Notions • 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. General Notions

7. Information-Flow Security • Confidentiality: only good guys learn about secrets • Integrity:only good guys influence trusted content

8. 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

9. 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.

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

11. A Simple Programming Language • 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;

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

13. Typical Issues in Information-Flow-Sensitive Semantics • Assignment: the label of the assigned variable is more restrictive than the static label of the assigned label • Conditional: check for implicit-flow covert channelsbool{Bob:} x; bool {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.

14. Typical Issues in Information-Flow-Sensitive Semantics • Assignment: the static label of the assigned variable is more restrictive than the static label of the assigning expression • Conditionals: check for implicit-flow covert channels • Loops: check for termination covert channelSolution: Condition not only influences PC for the body, but also for the continuation.

15. Delegation and Revocation

16. A Simple Programming Language • 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

17. 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

18. Typical Issues in Information-Flow-Sensitive Semantics • Assignment: the static label of the assigned variable is more restrictive than the meet of the static and dynamic label of the assigning expression • Conditionals: check for implicit-flow covert channels • Loops: check for termination covert channelSolution: Condition not only influences PC for the body, but also for the continuation.

19. 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

20. 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

21. Revocation (Revisited) • 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 access Alice’s credit card information

22. Delegation and Revocation:Semantic Issues • Information-flow content: principals influenced a variable so far • Assignment: • Either the static label of the assigned variable is more restrictive than the static label of the assigning expression and the information flow of the assigning expression is more restrictive than its static integrity label • Or the static label of the assigned variable is more restrictive than the meet of the static and dynamic label of the assigning expression and the information flow of the assigning expression is more restrictive than the meet of the static and dynamic integrity labels.

23. Secure Information Flow • Non-interference: changing the secret data does not influence publicly observable behavior • Delegation and revocation: secret and public change dynamically • Solutions: • Bisimulation-based non-interference [Sabelfeld&Sands, CSFW’00] • Piecewise parameterized non-interference [Sabelfeld&Myers, ISSS’03 and Barthe et al., CSFW’04] • Coercion, abstract flow semantics, type system [Hicks et al., Buodol, FAST’08]

24. Conclusions

25. Conclusions • Extended the language with restricted delegation and revocation • Main novelties • Restricting possible future delegations • Disallowing “delegated flows” after revocation • Extending the setting to integrity labels

26. Honorable Mentions • M. Hicks, S. Tse, B. Hicks, and S. Zdancewic. Dynamic updating of information-flow policies. In Proc. of FCS'05, pp. 7-18, 2005. • G. Boudol. Secure information flow as a safety property. In Proc. FAST'08, pp. 20-34, 2008. • N. Broberg and D. Sands. Paralocks: role-based information flow control and beyond. In Proc. POPL'2010, pp. 431-444, ACM, 2010.

27. Future Work • Allowing for expressions checking the possibility of a flow in the conditional statement • Defining a suitable notion of secure information flow and proving our semantics correct (ongoing) • Implementation and application in a secure server-side scripting language (ongoing) For more information, please see: D. Hassan, M.R. Mousavi and M.A. Reniers. Restricted Delegation and Revocation in Language-Based Security (Position Paper). Proc. of PLAS 2010.

28. Merci beaucoup Questions?