Stale-Safe Security Properties for Secure Information Sharing

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

5
g-SIS
Subject Attributes
Time of Join NULL
Join-TS Leave-TS
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) gt 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

GA
Group Subjects
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
Was never authorized
RT Refresh Time
Request (s, o2, r)
Add (o1)
Join (s)
Add (o2)
RT1
RT2
RT3
RT4
RT0
Leave (s)
Request (s, o1, r)
Was authorized at recent RT
Authz (s,o,r) Add-TS(o) gt 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 ec / a e Event c
Condition a Action
idle
Request Authz !timeout
Request timeout /refreshReq
!Authz /Reject /refresh
Authz !timeout /Perform
timeout /refreshReq
authorized
refreshing
Authz /refresh
Authz Add-TS gt Join-TS Leave-TS NULL o
NotIn ORL
14
Stale-Safe TRM
Transition Notation ec / 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 gt Refresh-TS
Authz Add-TS gt 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)
Add
RT
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