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

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

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

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

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

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

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

FORMALIZATION OF STALE-SAFETY 8

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

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

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

MODELING TRUSTED REFERENCE MONITOR (TRM) 12

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

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

Stale-Safety Verification Model Checkers – Cadence: – NuSMV: Language: Symbolic Model Verifier (SMV) Verification of Weak Stale-Safety – UnSafe TRM UnSafe TRM – Safe TRM Safe TRM 15

Stale-Unsafe TRM 16

Stale-Safe TRM 17

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

Questions/Comments Thanks! 19

Backup 20

Formalization of Authz JoinAddAuthz CC JoinAdd RT Authz TRM Join AddRT Authz TRM Case (a) Case (b) 21 Case (a) Case (b)

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

Temporal Operators 23