Enforcement Architecture and Implementation Model for Group-Centric Information Sharing

1. Enforcement Architecture and Implementation Model for Group-Centric Information Sharing Ram Krishnan (George Mason University) Ravi Sandhu (Univ. of Texas at San Antonio)

2. PEI Models: 3 Layers/5 Layers

3. Secure Information Sharing (SIS) • A fundamental problem in cyber security • Share but protect • Current approaches not satisfactory • Traditional models (MAC/DAC/RBAC) do not work • Recent approaches • Proprietary systems for Enterprise Rights Management • Many solutions: IBM, CA, Oracle, Sun, Authentica, etc. • Interoperability is a major issue • Many languages have been standardized • XrML, ODRL, XACML, etc. • Primarily, dissemination or object centric

4. Dissemination Centric Sharing • Attach attributes and policies to objects • Objects are associated with sticky policies • Policy language standards such as XrML and ODRL provide sticky policies Attribute + Policy Cloud Attribute + Policy Cloud Attribute + Policy Cloud Attribute + Policy Cloud Object Object Object Object Alice Bob Charlie Jake John Attribute Cloud Attribute Cloud Attribute Cloud Attribute Cloud Attribute Cloud Dissemination Chain with Sticky Policies on Objects

5. Group-Centric Sharing (g-SIS) • Advocates bringing users & objects together in a group • In practice, co-exists with dissemination centric sharing Join Add Never Group User Current Group User Past Group User Never Group Object Current Group Object Past Group Object Join Add Remove Leave • Two useful metaphors • Secure Meeting/Document Room • Users’ access may depend on their participation period • E.g. Program committee meeting, Collaborative Product Development, Merger and Acquisition, etc. • Subscription Model • Access to content may depend on when the subscription began • E.g. Magazine Subscription, Secure Multicast, etc.

6. g-SIS Policy Model Users Leave Join GROUP Authz (S,O,R)? Add Remove Objects

7. Enforcement Model Objectives • Allow offline access • Assumes a Trusted Reference Monitor (TRM) • Resides on group user’s access machine • Enforces group policy • Synchronizes attributes periodically with server • Objects available via Super-Distribution • Encrypt objects using group key and distribute • Other users with access to group key may access

8. g-SIS Architecture 6.2 Update: a. Remove_TS (o) = Current Time b. ORL = ORL U {id, Add_TS (o), Remove_TS (o)} 5.2 Set Leave-TS (u) = Current Time Object Cloud 2.2 Distribute o 1.3 User Join CC {AUTH=TRUE}, Integrity Evidence 2.1 Add Object o Obtain Object o 1.4 Provision Credentials 5.1 Remove User (id) 6.1 Remove Object (o) {id, Join_TS, Leave_TS, ORL, gKey, N} 3. Read Objects 4.1 Request Refresh 4.2 Update Attributes 1.1 Request Join {AUTH = FALSE} Group Users … Non-Group User GA TRM TRM TRM TRM 1.2 Authz Join {AUTH = TRUE} User Attributes: {id, Join-TS, Leave-TS, ORL, gKey} Object Attributes: {id, Add-TS} • ORL: Object Revocation List • gKey: Group Key Authz (s,o,r) -> Add-TS(o) > Join-TS(s) & Leave-TS(s) = NULL & o NotIn ORL

9. Super Vs Micro-distribution in g-SIS • Super-Distribution (SD) • Single key for all group users • Encrypt once, access where authorized • Total offline access except periodic refresh times • Micro-Distribution (MD) • CC shares a key with each user in the group • Initial access requires CC participation • CC custom encrypts using key shared with user • Subsequent accesses can be offline as allowed by TRM Super-Distribution in g-SIS Micro-Distribution in g-SIS User Object Cloud CC Author User CC Author Add (C) Encrypt o with key k1 shared with CC (C = Enc(o,k1))) C = Enc (o, K) Add (C) Dec (c, k1), Set Add_TS for o and Store Locally Distribute (C) Set Add_TS for o Get (o) Get (o) Provide (C’) Encrypt o with key k2 shared with User (C’ = Enc (o, k2)) Provide (C) Store C’ Locally Read o and Store C Locally Dec (C’, k2)

10. Super Vs Micro-Distribution (contd)

11. Protocols

12. Background (Trusted Computing) • Trusted Computing • An industry standard/alliance • Proposed by Trusted Computing Group • Basic premise • Software alone cannot provide an adequate foundation for trust • TCG proposes root of trust at the hardware level using a Trusted Platform Module or TPM

13. Background (TPM) • Trusted storage for keys • Encrypt user keys with a chain of keys • Storage Root key (SRK) is stored in TPM & never exposed • Trusted Capabilities • Operations exposed by the TPM • Guaranteed to be trust-worthy • Platform Configuration Registers (PCR) • Hardware registers used to store integrity of software (e.g. boot-chain)

14. Background (TPM Capabilities) • Seal • Data/Key coupled with a PCR value encrypted with SRK • Unseal • Data/Key will be decrypted by the TPM only if current PCR value matches that of PCR value in sealed blob • CertifyKey • Create a key pair • Private key is sealed to a PCR value • Public key signed by TPM only if Private part is non-migratable • Private part available in the future only if future PCR value matches the PCR value at seal time • Third parties can encrypt data with public key • Data can be decrypted only under known PCR state • Data cab be decrypted only using the same TPM that created the key (non-migratable)

15. Join (Authorization)

16. Join (Provisioning)

17. Object Add

18. Object Read

19. Attribute Refresh

20. Leave and Remove User Leave Object Remove

21. Conclusion • Group-Centric Vs Dissemination-Centric Sharing • Super Vs Micro-Distribution approach in g-SIS • g-SIS Architecture supports both SD and MD • Offline access realizable due to Trusted Computing • Future Work • Investigate Implementation Model • Read-Write Access • Multiple Groups