restricted delegation and revocation in language based security
Download
Skip this Video
Download Presentation
Restricted Delegation and Revocation in Language-Based Security

Loading in 2 Seconds...

play fullscreen
1 / 28

Restricted Delegation and Revocation in Language-Based Security - PowerPoint PPT Presentation


  • 102 Views
  • Uploaded on

Restricted Delegation and Revocation in Language-Based Security. Mohammad Mousavi TU/Eindhoven École Polytechnique , May 2010. (Based on joint work with Doaa Hassan and Michel Reniers ). Outline. Motivation Language-Based Security: General Notions Extension to Delegation and Revocation

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

PowerPoint Slideshow about ' Restricted Delegation and Revocation in Language-Based Security' - kyria


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.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
restricted delegation and revocation in language based security

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)

outline
Outline
  • Motivation
  • Language-Based Security: General Notions
  • Extension to Delegation and Revocation
  • Secure Flow Properties
  • Conclusions
revocation
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
restricted delegation
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
information flow security
Information-Flow Security
  • Confidentiality: only good guys learn about secrets
  • Integrity:only good guys influence trusted content
principals
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
policies
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.

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

a simple programming language
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;
typical issues in information flow sensitive semantics
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}

typical issues in information flow sensitive semantics1
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.

typical issues in information flow sensitive semantics2
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.
a simple programming language1
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
semantics of delegation
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

typical issues in information flow sensitive semantics3
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.
semantics of revocation
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

semantics of revocation1
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

revocation revisited
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
delegation and revocation semantic issues
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.
secure information flow
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]
conclusions
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
honorable mentions
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.
future work
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.

slide28

Merci beaucoup

Questions?

ad