5
Problem Statement One of the central problems in information sharing is the ability to securely share information for a specific purpose or mission by bringing together users and information There is no existing model that addresses this problem 5 A first step towards a formal and systematic study of Group- Centric Secure Information Sharing Models Contribution

9
Core g-SIS Properties 9 Authorization Persistence Authorization cannot change if no group event occurs Authorization Provenance Authorization can begin to hold only after a simultaneous period of user and object membership

11
Satisfaction and Independence 11 The Core Properties are Satisfiable There exists a trace in whichis true The Core Properties are Independent Neither prove nor refute one of the properties from others is not valid

22
Stale-Safe Security Properties If a user is able to perform an action on an object, the authorization to perform the action is guaranteed to have held sometime prior to perform Weak Stale-Safety Allows safe authorization decision without contacting the CC Achieved by requiring that authorization held 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 22

27
Contribution Policy Layer Formal characterization of Group-Centric models Identification of a core set of properties required of all g-SIS specifications Proof of Independence and Satisfaction of core properties A set of useful group operation semantics A family of g-SIS specifications ( -system) supporting a variety of group operation semantics A formal proof that the -system satisfies the core properties Enforcement Layer Identification and specification of stale-safe security properties Verification of stale-safety of g-SIS enforcement model Implementation Layer TPM-based protocols for g-SIS enforcement model Provisioning protocol proof-of-concept 27

40
Roles Vs Groups in SIS Roles Users get same set of privileges on role assignment Does not consider timing of assignment/activation Temporal RBAC considers specific timing aspects E.g. authorizations for when a role can be activated Groups Privileges may differ with time of join, leave, etc. Sharing is promoted within and across groups Inter-group relationship may differ from that of roles 40

43
Linear Temporal Logic (summary) Next p Formula p holds in the next state Henceforth p Starting from current state, p will continuously hold in all the future states p until q q will occur sometime in the future and p will hold at least until the first occurrence of q p unless q p holds either until the next occurrence of q or if q never occurs, it holds throughout 43 Previous p Formula p held in the previous state Once p Formula p held at least once in the past p since q q happened in the past and p held continuously from the position following the last occurrence of q to the present

44
Notations Use Join, Leave, Add and Remove to refer to some respective event type occurring 44 Drop the parameters for convenience

45
Well-Formed Traces Multiple events cannot occur in a state for the same user (or object) E.g. 1 User cannot join and leave in the same state E.g. 2 Two types of join cannot occur in the same state 45 Malformed trace s0s0 s1s1 s2s2 s3s3 E.g. 1 E.g. 2 User events should occur alternatively beginning with a join event E.g. 1 leave cannot occur before join E.g. 2 join should be followed by a leave before another join Malformed trace s0s0 s1s1 s2s2 s3s3 E.g. 1E.g. 2

49
Group Operation Semantics Membership semantics Authorizations enabled by current membership (join & add) And authorizations disabled at the time of leave and remove Membership Renewal Semantics Authorizations enabled from prior membership period And those disabled at subsequent leave time 49

51
Verification Using Model Checker Model allows join, leave, add and remove to occur concurrently, non-deterministically and in any order 51 The above implication is used as the LTLSPEC The model checker generates a counter-example if the specification is false Used the open-source NuSMV model checker

52
Read-Write Object Model 52 No VersioningVersioning 1. Multiple users may update, latest write is committed (destructive write). 1. Multiple users may update, each update creates a new version. 2. No write after leave. 3. Coarse-grained authorization (specified on the whole object). 3. Fine-grained. Authorization can differ for different versions of the same object. 4. Tricky issues with Liberal operations. E.g. On LL, past users may read new writes by group users. 4.1 Fix: Past LL users cannot read after write. 4. No such issues. Past LL users may continue to read versions authorized at leave time. Provenance property rules out access to new versions after leave.

55
Read-Write (versioning) 55 An object is composed of multiple versions An update operation creates a new version A specific version of an object may be updated Basically, versions are immutable New operation: Update(o.v i, o.v j ) Version to update New updated Version

56
Core Properties (Continued) Version dependency properties If current user can read base version of o, all other versions of o can also be read 56 If some version of o can be read, all prior versions of o can also be read If user can write some version of o, then he/she can write all versions of o Note only current members can write