The Secure Information Sharing Problem and Solution Approaches

The Secure Information Sharing Problem and Solution Approaches Ravi Sandhu Executive Director and Endowed Chair Institute for Cyber Security University of Texas at San Antonio www. profsandhu. com © Ravi Sandhu www. profsandhu. com

Three Themes Work in Progress Secure Information Sharing (IS) “Share but Protect” “Mother of all Security Problems” Policy-Enforcement. Implementation Layers (PEI) & Usage Control Models (UCON) 2 Trusted Computing (TC) © Ravi Sandhu www. profsandhu. com

What is Trusted Computing (TC)? Basic premise • Software alone cannot provide an adequate foundation for trust Old style Trusted Computing (1970 – 1990’s) • Multics system • Capability-based computers How best to leverage this technology? – Intel 432 vis a vis Intel 8086 • Trust with security kernel based on military-style security labels – Orange Book: eliminate trust from applications What’s new (2000’s) • Hardware and cryptography-based root of trust – Trust within a platform – Trust across platforms Massive paradigm shift • Rely on trust in applications – No Trojan Horses or – Mitigate Trojan Horses and bugs by legal and reputational recourse 3 Prevent information leakage by binding information to Trusted Viewers on the client © Ravi Sandhu www. profsandhu. com

What is Information Sharing? The mother of all security problems • Share but protect Requires controls on the client • Server-side controls do not scale to high assurance Bigger than (but includes) • Retail DRM (Digital Rights Management) • Enterprise DRM 4 © Ravi Sandhu www. profsandhu. com

What is Information Sharing? Strength of Enforcement Content type and value Weak Strong Sensitive and proprietary Password-protected documents Software-based client controls for documents Hardware based trusted viewers, displays and inputs Revenue driven IEEE, ACM digital libraries protected by server access controls DRM-enabled media players such as for digital music and e. Books Dongle-based copy protection, hardware based trusted viewers, displays and inputs Sensitive and revenue Analyst and business reports protected by server access controls Software-based client controls for documents Hardware based trusted viewers, displays and inputs Roshan Thomas and Ravi Sandhu, “Towards a Multi-Dimensional Characterization of Dissemination Control. ” POLICY 04. 5 Medium © Ravi Sandhu www. profsandhu. com

Functionality Simple Strength of enforcement Complex Legally enforceable versus system enforced rights. Dissemination chains and flexibility. Object types supported. With current state. Flexible, of knowledge multi-step, and multi-point. the information. Support sharing space Simple, read-only and singlefor complex, multi-version objects. isobjects. too complex to characterize Support for object sensitivity/confidentiality. in a comprehensive manner Limited to one-step disseminations. Weak/Medium Strong Reliance on legal enforcement; Limited system enforced controls. Strong system- enforceable rights, revocable rights. Mostly legal enforcement; System enforceable controls. Reliance on legally enforceable rights. System supported and enforceable rights and sanitization on multiple versions. Persistence and modifiability of rights and licenses. Immutable, persistent and viral on all disseminated copies. Not viral and modifiable by recipient. Reliance on legally enforceable rights. System enforceable. Online versus offline access and persistent client-side copies No offline access and no clientside copies. Allows offline access to client-side copies. Few unprotected copies are tolerated. No unprotected copies are tolerated. Usage controls Control of basic dissemination. Flexible, rule-based usage controls on instances. Some usage abuse allowed. No potential for usage abuse. Preservation of attribution. Recipient has legal obligation to give attribution to disseminator. System-enabled preservation and traceback of the attribution chain back to original disseminator. Revocation Simple explicit revocations. Support for derived and value-added objects. Not supported. Integrity protection for disseminated objects. Out of band or non-crypto based validation. Audit Payment 6 Attribution can only be legally Look for sweet spots that. Attribution is system enforced. are of practical interest Complex policy-based revocation. No timeliness guarantees. to take immediate and where progress (and. Guaranteed effect. killer products) can be made Supported. Reliance on legally System enforceable rights for enforceable rights. derived and valued-added objects. Cryptographic schemes for integrity validation. Off-line validation. High-assurance cryptographic validation. Audit support for basic dissemination operations. Additional support for the audit of instance usage. Offline audit analysis. Real-time audit analysis and alerts. Simple payment schemes (if any). Multiple pricing models and payment schemes including resale. Tolerance of some revenue loss. No revenue loss; Objective is to maximize revenue. Roshan Thomas and Ravi Sandhu, “Towards a Multi-Dimensional Characterization of Dissemination Control. ” POLICY 04.

Classic Approaches to Information Sharing Discretionary Access Control (DAC), Lampson 1971 • Fundamentally broken • Controls access to the original but not to copies (or extracts) Mandatory Access Control (MAC), Bell-La. Padula 1971 • Solves the problem for coarse-grained sharing – Thorny issues of covert channels, inference, aggregation remain but can be confronted • Does not scale to fine-grained sharing – Super-exponential explosion of security labels is impractical – Fallback to DAC for fine-grained control (as per the Orange Book) is pointless Originator Control (ORCON), Graubart 1989 • Propagated access control lists: let copying happen but propagate ACLs to copies (or extracts) Not very successful 7 © Ravi Sandhu www. profsandhu. com

Modern Approach to Information Sharing Prevent leakage by binding information to Trusted Viewers on the client • Use a mix of cryptographic and access control techniques Cryptography and Trusted Computing primitives enable encapsulation of content in a Trusted Viewer • Trusted Viewer cannot see plaintext unless it has the correct keys Access control enables fine-grained control and flexible policy enforcement by the Trusted Viewer • Trusted Viewer will not display plaintext (even though it can) unless policy requirements are met • Enables policy flexibility and policy-mechanism separation Without use of hardware-rooted Trusted Computing assurance of client-side controls is very weak 8 © Ravi Sandhu www. profsandhu. com

PEI Models Framework 9 © Ravi Sandhu www. profsandhu. com

Scoping Information Sharing Problem: Objective Layer Scoping the Problem • • Read-only (versus read-write) Document-level controls (versus query-level control) Superdistribution (encrypt once, access wherever authorized) Support for off-line access without advance set-up (with usage limits) Scoping the Solution • Two-phase enforcement Limits instant and preemptive revocation – Enroll TPM (Trusted Platform Module) and La. Grande equipped client computer into a Group – Within the Group impose additional policy-based controls Required to support super-distribution 10 Supports fine-grained controls and policy flexibility © Ravi Sandhu www. profsandhu. com

PEI Models Framework 11 © Ravi Sandhu www. profsandhu. com

Various states of a member in a group enroll Initial state: Never been a member Currently a member Past member State III State I enroll 12 disenroll © Ravi Sandhu www. profsandhu. com

Access policies for State I 1. Straight-forward. User has no access to any group documents. enroll Initial state: Never been a member Currently a member Past member State III State I enroll 13 disenroll © Ravi Sandhu www. profsandhu. com

Access policies for State II 1. 2. 3. 4. Access to current documents only (or) Access to current documents and past documents Access can be further restricted with rate and/or usage limits Access can be further restricted on basis of individual user credentials Initial state: Never been a member enroll Currently a member Past member State III State I enroll 14 disenroll © Ravi Sandhu www. profsandhu. com

Access policies for State III 1. 2. 3. 4. 5. Past member loses access to all documents (or) can access any document created during his membership (or) can access documents he accessed during membership (or) can access all documents created before he left the group (this includes the ones created before his join time) all subject to possible additional rate, usage and user credential restrictions Initial state: Never been a member Currently a member enroll Past member State III State I enroll 15 disenroll © Ravi Sandhu www. profsandhu. com

Access policies for State II. re-enroll 1. 2. 3. 4. No rejoin of past members is allowed, rejoin with new ID (or) Past members rejoin the group just like any other user who has never been a member The same access policies defined during his prior membership should again be enforced (or) access policies could vary between membership cycles enroll Initial state: Never been a member Currently a member Past member State III State I enroll 16 disenroll © Ravi Sandhu www. profsandhu. com

Use-case 1 Access policies: II. 1, II. re-enroll. 1 • Intel’s Vii. V: A typical scenario in libraries, book-stores, cafes, etc. a. b. c. • 17 A master system could be Vii. V enabled which subscribes to various kinds of channels from its content providers Many devices can in-turn subscribe to this master device and receive content and thus form a group When a device leaves the group, it loses access to all the downloaded content. “Leaving the group” could be determined by various mechanisms depending on context and available technology (location, network connectivity, etc. ). Many universities and corporations allow access to their content as long as one is within their network. Once the user leaves the network, the user loses access to the content. © Ravi Sandhu www. profsandhu. com

Use-case 2 Access policies: II. 1, III. 2, II. re-enroll. 1: • Project out-sourcing: – A financial organization could recruit a software-consulting firm to provide software solutions. This forms a temporary group. – The incoming members (from the software firm) cannot access any past documents. These could be design documents that were created in collaboration with a different external organization. – When they finish the project and leave the group, they can continue to have access to the documents exchanged during their membership for future reference and to add to their profile. This is dependant on financial institution’s policy. 18 © Ravi Sandhu www. profsandhu. com

Use-case 3 Access policies: II. 2, III. 1, II. re-enroll. 1: • • • 19 An employee in a company can access all the current documents. When he employee quits, he should lose access to all documents. Do. D projects / contracts have a multi tiered structure. A member of a contracting company may be authorized to access certain set of documents only for the duration of the project – once the project is over, the contractor’s right to use the document is automatically voided. In a supply chain situation, there are lots of partners and suppliers who will send quotes for a given proposal. They need to have access to the proposal and related content. But once the quote/response is submitted, their membership context for that particular or group of proposals ceases and they shouldn’t have access to any of the older content that they had access to. © Ravi Sandhu www. profsandhu. com

Use-case 4 Access policies: II. 2, II. re-enroll. 1: • Collaborative product development: – – 20 In the case of several automobile models, there are product twins – models from the same company that resemble each other, except for the division's brand name and price tag. In such instances, there could be either a loose collaboration (e. g. shared design team, parts ordering/manufacturing but different factories) or a tight collaboration (e. g. joint manufacturing of two different models). In either case, the members from different parties join hands and share documents actively. They will need access to both old documents and current documents. Even after the collaboration period, they will need access to the old documents for further refinement and production. © Ravi Sandhu www. profsandhu. com

Various states of an object (document) in a group add Initial state: Never been a group doc Currently a group doc Past group doc State III add 21 remove © Ravi Sandhu www. profsandhu. com

Access policies for State I 1. Straight-forward. No access to group members. add Initial state: Never been a group doc Currently a group doc Past group doc State III add 22 remove © Ravi Sandhu www. profsandhu. com

Access policies for State II 1. 2. Access allowed only to current group members Access allowed to current and past group members add Initial state: Never been a group doc Currently a group doc Past group doc State III add 23 remove © Ravi Sandhu www. profsandhu. com

Access policies for State III 1. 2. 3. No one can access Any one can access Past members can access add Initial state: Never been a group doc Currently a group doc Past group doc State III add 24 remove © Ravi Sandhu www. profsandhu. com

Access policies for State II. re-add 1. 2. 3. 4. Cannot be re-added. When a document is re-added, it will be treated as a new document that is added into the group. Only current members can access. Past members and current members can access Initial state: Never been a group doc Currently a group doc Past group doc State III add 25 add remove © Ravi Sandhu www. profsandhu. com

Policy Models Idealized policy: • Instant revocation • Pre-emptive revocation Enforcement models will specify degree of approximation (among other details) 26 © Ravi Sandhu www. profsandhu. com

Policy Models Group membership control • Group-admins enroll and dis-enroll members • Group-admins add/remove documents. For concreteness we assume specific group-level policies • Members cannot access documents created prior to joining • Past-members can access documents created during (most recent) membership • Past documents cannot be accessed by anybody • Documents cannot be re-added The PEI models have specific points where such policies are enforced and remain robust to changes in policy details 27 © Ravi Sandhu www. profsandhu. com

Usage Control: The UCON Model • unified model integrating • authorization • obligation • conditions • and incorporating • continuity of decisions • mutability of attributes 28 © Ravi Sandhu www. profsandhu. com

UCON Policy Model Operations that we need to model: • Document read by a member. • Adding/removing a member to/from the group • Adding/removing a document to/from the group Member attributes • Member: boolean • TS-join: join time • TS-leave: leave time Document attributes • D-Member: boolean • D-TS-join: join time • D-TS-leave: leave time 29 © Ravi Sandhu www. profsandhu. com

Policy model: member enroll/dis-enroll member TS-join TS-leave null enroll True time of join null dis-enroll, dis-enroll: authorized to Group-Admins Initial state: Never been a member False time of join time of leave Currently a member Past member State III State I enroll 30 disenroll UCON elements: Pre-Authorization, attribute predicates, attribute mutability © Ravi Sandhu www. profsandhu. com

Policy model: document add/remove D-member D-TS-join D-TS-leave null True time of join null add False time of join time of leave remove add, remove : authorized to Group-Admins add Initial state: Never been a group doc Currently a group doc Past group doc State III add 31 remove UCON elements: Pre-Authorization, attribute predicates, attribute mutability © Ravi Sandhu www. profsandhu. com

Policy model: document read (S, O, read) Pre-authorization check • member(S) ≠ null AND D-member(O) ≠ null AND TS-join(S) ≠ null AND D-TS-join(O) ≠ null AND – TS-leave(S) = null AND TS-join(S) ≤ D-TS-join(O) OR – TS-leave(S) ≠ null AND TS-join(S) ≤ D-TS-join(O) ≤ TS-leave(O) Ongoing-authorization check: terminate if • D-TS-leave(O) ≠ null Details depend on details of group-level policy UCON elements: Pre-Authorization, attribute predicates, attribute mutability Ongoing-authorization 32 © Ravi Sandhu www. profsandhu. com

PEI Models Framework 33 © Ravi Sandhu www. profsandhu. com

Enforcement Models Design Principle • Do not inject new policy • Focus on trade-offs for instant and pre-emptive revocation versus off-line access Faithful Enforcement w/o Off-line Access (Faithful Model): • We need continuous online touch (at start of every access and during access) • Continuous on-line touch can only be approximated Usage-limited Off-line Access (Approximate Model): • We need online touch periodically after some duration (at start of every access and during access) – Duration between online touches can be based on time, but time is not practical for TPM-based TC – Duration between online touches can be based on usage count, which is practical for TPM-based TC 34 © Ravi Sandhu www. profsandhu. com

Enforcement Architecture Control Center (CC) 4 2 7 3 5 1 Joining Member Group-Admin 6 Member Two sets of attributes • Authoritative: as known to the CC • Local: as known on a member’s computer • Member enroll and dis-enroll (steps 1 -2, 5) • Document add and remove (step 6, 7) • Read policy enforcement (step 3) • Attribute update (step 4) D-Member Faithful Model: steps 3 and 4 are coupled Approximate Model: steps 3 and 4 are de-coupled 35 © Ravi Sandhu www. profsandhu. com

UCON Enforcement Models Member attributes • Member-a, Member-l: boolean • TS-join-a, TS-join-l: join time • TS-leave-a, TS-leave-l: leave time Document attributes • D-Member-a, D-Member-l: boolean • D-TS-join-a, D-TS-join-l: join time • D-TS-leave-a, D-TS-leave-l: leave time Additional Member attributes for Approximate model: • refresh_count: decremented on every access • refresh_count_reset: refresh_count is reset to this value when it hits 0 36 © Ravi Sandhu www. profsandhu. com

Faithful model highlights • enroll a member: two steps • Step 1: Group-admin issues enrollment token to Joining Member • Step 2: Joining Member presents token to CC and receives group membership credential – Group key (symmetric key) – Local attribute values • dis-enroll a member • Updates authoritative attributes at CC • Takes effect on local attributes at next update • add a document • Updates authoritative attributes at CC • remove a document • Updates authoritative attributes at CC • Propagated to clients as DRLs (Document Revocation List) 37 © Ravi Sandhu www. profsandhu. com

Faithful model highlights: (S, O, read) • Pre-Obligation • • • Pre-Condition • • Local attributes of S and O continuously updated based on authoritative values from CC Local DRL continuously updated from authoritative DRL at CC Ongoing-Condition • • Based on just updated local attributes of S and O and DRL Ongoing-Obligation • • • Requires connectivity to enable updates Pre-Authorization • • Local attributes of S and O are updated based on authoritative values from CC Local DRL updated from authoritative DRL at CC Requires connectivity to enable updates Ongoing-Authorization • Based on continuously updated local attributes of S and O and DRL UCON elements: Requires full power of UCON 38 © Ravi Sandhu www. profsandhu. com

Approximate model highlights • enroll a member: two steps • Step 1: Group-admin issues enrollment token to Joining Member • Step 2: Joining Member presents token to CC and receives group membership credential – Group key (symmetric key) – Local attribute values • dis-enroll a member • Updates authoritative attributes at CC • Takes effect on local attributes at next update • add a document • Updates authoritative attributes at CC • remove a document • Updates authoritative attributes at CC • Propagated to clients as DRLs (Document Revocation List) Different from Faithful model 39 © Ravi Sandhu www. profsandhu. com

Approximate model highlights: (S, O, read) • Pre-Obligation • Local attributes of S and O are periodically updated based on authoritative values from CC • Pre-Condition • Requires connectivity to enable updates when required • Pre-Authorization • Based on just updated local attributes of S and O • Ongoing-Obligation • Local attributes of S and O are continuously periodically updated based on authoritative values from CC • Ongoing-Condition • Requires connectivity to enable updates when required • Ongoing-Authorization • Based on continuously periodically updated local attributes of S and O UCON elements: Requires full power of UCON 40 © Ravi Sandhu www. profsandhu. com

PEI Models Framework • Out of scope for this talk 41 © Ravi Sandhu www. profsandhu. com

Conclusion Information sharing is an important security problem and a potential growth area Trusted computing is a good fit for solving some sweet spots in this space The PEI models framework is useful in closing the policy-implementation gap UCON is a useful framework for stating policy and enforcement models 42 © Ravi Sandhu www. profsandhu. com

Q&A Work in Progress Secure Information Sharing (IS) “Share but Protect” “Mother of all Security Problems” Policy-Enforcement. Implementation Layers (PEI) & Usage Control Models (UCON) 43 Trusted Computing (TC) © Ravi Sandhu www. profsandhu. com