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) 1

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 2

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

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 subjects access machine – Enforces group policy – Synchronizes attributes periodically with server Objects available via Super-Distribution 4

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

6. g-SIS Architecture CC GA Group Subjects TRM … 1. Read Objects 5.1 Request Refresh 5.2 Update Attributes 3.1 Subject Leave (s) 4.1 Object Remove (o) 3.2 Set Leave-TS (s) 4.2 Add o to ORL 6 CC: Control Center GA: Group Administrator 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 0 RT 1 RT 2 RT 3 Join (s) Add (o1) Add (o2) Leave (s) Request (s, o1, r) Request (s, o2, r) Authz (s,o,r) Add-TS(o) > Join-TS(s) & Leave-TS(s) = NULL & o NotIn ORL Was authorized at recent RT Was never authorized 7 RT: Refresh Time RT 4

8. FORMALIZATION OF STALE-SAFETY 8

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 9

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 10

11. Properties RTPerform Stale-unsafe Decision RequestPerform Request Perform Weak Stale-Safety: Strong Stale-Safety: 11 Formula JoinAdd Authz

12. MODELING TRUSTED REFERENCE MONITOR (TRM) 12

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

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

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

16. Stale-Unsafe TRM 16

17. Stale-Safe TRM 17

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 18

19. Questions/Comments Thanks! 19

20. Backup 20

21. Formalization of Authz JoinAddAuthz CC JoinAdd RT Authz TRM Join AddRT Authz TRM Case (a) Case (b) 21 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 22

23. Temporal Operators 23