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 AIP AIPAIP

ADP ADP 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 subject’s 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 SubjectJoin

Add

Join

Never Group Object

Current Group Object

Past Group ObjectAdd Remove

Leave

Time of JoinNULL

Join-TSLeave-TS

Time of JoinTime of LeaveTime of Add

NULL

Add-TSRemove-TS

Time of AddTime of Remove

Authz (s,o,r) Add-TS(o) > Join-TS(s) & Leave-TS(s) = NULL & Remove-TS(o) = NULL

5

Subject AttributesObjectAttributes

g-SIS Architecture

CC

GA

Group Subjects

TRM TRM TRM…

1. Read Objects

5.1 Request R

efresh

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 CenterGA: 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

RT0RT1 RT2 RT3

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

RT4

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

RT Perform

Stale-unsafe Decision

Request Perform Request Perform

Weak Stale-Safety:

Strong Stale-Safety:11

Formula Formula

Join Add Authz

MODELING TRUSTED REFERENCE MONITOR

(TRM)

12

Stale-Unsafe TRM

authorized refreshing

idle

Request [timeout]/refreshReq

[!Authz]/Reject/refresh

[timeout]/refreshReq

[Authz]/refresh

Request [Authz & !timeout]

[Authz & !timeout]/Perform

Authz Add-TS > Join-TS & Leave-TS = NULL & o NotIn ORL 13

Transition Notation:e[c] / ae : Eventc : Conditiona : Action

Stale-Safe TRM

authorized refreshing

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] / Ae : Eventc : Conditiona : Action

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

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

Join Add AuthzCC

Join Add RT AuthzTRM

Join AddRT AuthzTRM

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