1 / 23

Stale-Safe Security Properties for Secure Information Sharing

Stale-Safe Security Properties for Secure Information Sharing. Ram Krishnan (GMU) Jianwei Niu (UT San Antonio) Ravi Sandhu (UT San Antonio) William Winsborough (UT San Antonio). Presentation Outline. Concept Stale-Safety Group-Based Secure Information Sharing (g-SIS) Staleness in g-SIS

lamis
Download Presentation

Stale-Safe Security Properties for Secure Information Sharing

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. Stale-Safe Security Properties for Secure Information Sharing Ram Krishnan (GMU) Jianwei Niu (UT San Antonio) Ravi Sandhu (UT San Antonio) William Winsborough (UT San Antonio)

  2. Presentation Outline • Concept • Stale-Safety • Group-Based Secure Information Sharing (g-SIS) • Staleness in g-SIS • Formal Specification using Linear Temporal Logic • Weak Stale-Safe Security Property • Strong Stale-Safe Security Property • Modeling g-SIS • Verification of g-SIS Stale-Safety using Model Checking

  3. Concept of Stale-Safety Update AIP: Authorization Information Point AIP AIP AIP AIP ADP: Authorization Decision Point ADP ADP ADP AEP: Authorization Enforcement Point AEP

  4. Group-Based Secure Information Sharing (g-SIS) • Share sensitive information within a group • Allows offline access • Assumes a Trusted Reference Monitor (TRM) • Resides on group subject’s access machine • Enforces group policy • Synchronizes attributes periodically with server • Objects available via Super-Distribution

  5. g-SIS Subject Attributes Join-TS Leave-TS Time of Join NULL Time of Join Time of Leave Object Attributes Add-TS Remove-TS Time of Add Time of Remove Time of Add NULL Join Add Never Group Subject Current Group Subject Past Group Subject Never Group Object Current Group Object Past Group Object Join Leave Add Remove Authz (s,o,r) Add-TS(o) > Join-TS(s) & Leave-TS(s) = NULL & Remove-TS(o) = NULL

  6. g-SIS Architecture CC: Control Center GA: Group Administrator 3.2 Set Leave-TS (s) 4.2 Add o to ORL CC 4.1 Object Remove (o) 5.1 Request Refresh 5.2 Update Attributes 3.1 Subject Leave (s) 1. Read Objects … Group Subjects GA TRM TRM TRM • Subject Attributes: {id, Join-TS, Leave-TS, • ORL, gKey} • ORL: Object Revocation List • gKey: Group Key Object Attributes: {id, Add-TS} Refresh Time (RT): TRM contacts CC to update attributes

  7. Staleness in g-SIS RT: Refresh Time Was never authorized Request (s, o2, r) Add (o1) Join (s) Add (o2) RT1 RT2 RT3 RT4 RT0 Request (s, o1, r) Leave (s) Was authorized at recent RT Authz (s,o,r) Add-TS(o) > Join-TS(s) & Leave-TS(s) = NULL & o NotIn ORL

  8. FormalIzation of Stale-Safety

  9. Linear Temporal Logic • Precise, Concise expression of state sequence properties • Uses temporal operators and logical connectives • Enables automated verification of properties • Future Operators • p: formula p holds in current and all future states • Past Operators • p S q (p Since q): means q held sometime in the past and p held since that state to the current • p (previous): means p held in the previous state

  10. Stale-Safe Security Properties • Weak Stale-Safety • Allows (safe) authorization decision to made without contacting the CC • Achieved by requiring that authorization was TRUE at the most recent refresh time • Strong Stale-Safety • Need to obtain up to date authorization information from CC after a request is received • If CC is not available decision cannot be made

  11. Properties Stale-unsafe Decision RT Perform Join Add Authz Request Perform Request Perform Formula Formula Weak Stale-Safety: Strong Stale-Safety:

  12. Modeling Trusted Reference monitor (TRM)

  13. Stale-Unsafe TRM Transition Notation: e[c] / a e : Event c : Condition a : Action idle Request [Authz& !timeout] Request [timeout] /refreshReq [Authz & !timeout] /Perform [!Authz] /Reject /refresh [timeout] /refreshReq authorized refreshing [Authz] /refresh Authz Add-TS > Join-TS & Leave-TS = NULL & o NotIn ORL

  14. Stale-Safe TRM Transition Notation: e[c] / A e : Event c : Condition a : Action idle Request [timeout | stale] /refreshReq Request [Authz& !timeout & !stale] [Authz & !timeout] /Perform [!Authz & !timeout] /Reject [AuthzE] /Reject /refresh [timeout] /refreshReq authorized refreshing [Authz] /refresh stale: Add-TS >= Refresh-TS Authz Add-TS > Join-TS & Leave-TS = NULL & Remove-TS = NULL

  15. Stale-Safety Verification • Model Checkers • Cadence: http://www.kenmcmil.com/ • NuSMV: http://nusmv.irst.itc.it/ • Language: Symbolic Model Verifier (SMV) • Verification of Weak Stale-Safety • UnSafe TRM • Safe TRM

  16. Stale-Unsafe TRM

  17. Stale-Safe TRM

  18. Conclusions • Staleness is inherent to distributed systems • Impossible to eliminiate time-delayed attributes • Possible to limit impact of time-delayed attributes • Weak Stale-Safe Property • Characterizes safe decisions using time-delayed attributes • Strong Stale-Safe Property • Characterizes a decision that can be made only with up to date attributes (infeasible in many applications such as g-SIS) • Formal Specification using LTL allows automated verification using model checking

  19. Questions/Comments Thanks!

  20. Backup

  21. Formalization of Authz Join Add AuthzCC Case (a) Join Add RT AuthzTRM Case (b) RT Add Join AuthzTRM Case (a) Case (b)

  22. Stale-Safe Systems • Strong Stale-Safety • Safe for Confidentiality and Integrity systems • Main trade-off is usability/practicality • E.g. Not applicable for g-SIS • Weak Stale-Safety • Risky for Integrity systems • Maliciously updated objects may be consumed by others before modifications can be undone • E.g. Malicious code injected by unauthorized subjects may be executed on a critical system by another subject

  23. Temporal Operators

More Related