Post on 26-Mar-2015
© Ravi Sandhuwww.profsandhu.com
The Secure Information Sharing Problem and Solution Approaches
Ravi SandhuExecutive Director and Endowed Chair
Institute for Cyber SecurityUniversity of Texas at San Antonio
www.profsandhu.com
2 © Ravi Sandhuwww.profsandhu.com
Three Themes Secure Information
Sharing (IS)“Share but Protect”
“Mother of all Security Problems”
TrustedComputing (TC)
Policy-Enforcement-Implementation Layers (PEI)
&Usage Control Models (UCON)
Work in Progress
3 © Ravi Sandhuwww.profsandhu.com
Basic premise• Software alone cannot provide an adequate foundation for trust
Old style Trusted Computing (1970 – 1990’s)• Multics system• Capability-based computers
– 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
• Rely on trust in applications– No Trojan Horses or– Mitigate Trojan Horses and bugs by legal and reputational recourse
What is Trusted Computing (TC)?
Massive paradigm shift
Prevent information leakage by binding information to Trusted Viewers on the client
How best to leveragethis technology?
4 © Ravi Sandhuwww.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
5 © Ravi Sandhuwww.profsandhu.com
What is Information Sharing?Strength of Enforcement
Content type and value Weak Medium 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 eBooks
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.” POLICY04.
Functionality Strength of enforcement
Simple Complex Weak/Medium Strong
Legally enforceable versus system enforced rights.
Reliance on legal enforcement;Limited system enforced controls.
Strong system- enforceable rights, revocable rights.
Dissemination chains and flexibility.
Limited to one-step disseminations.
Flexible, multi-step, and multi-point. Mostly legal enforcement; System enforceable controls.
Object types supported. Simple, read-only and single-version objects.
Support for complex, multi-version objects.Support for object sensitivity/confidentiality.
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 client-side 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 trace- back of the attribution chain back to original disseminator.
Attribution can only be legally enforced.
Attribution is system enforced.
Revocation Simple explicit revocations. Complex policy-based revocation. No timeliness guarantees. Guaranteed to take immediate effect.
Support for derived and value-added objects.
Not supported. Supported. Reliance on legally enforceable rights.
System enforceable rights for derived and valued-added objects.
Integrity protection for disseminated objects.
Out of band or non-crypto based validation.
Cryptographic schemes for integrity validation.
Off-line validation. High-assurance cryptographic validation.
Audit Audit support for basic dissemination operations.
Additional support for the audit of instance usage.
Offline audit analysis. Real-time audit analysis and alerts.
Payment 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.
With current state of knowledgethe information sharing spaceis too complex to characterizein a comprehensive manner
Look for sweet spots thatare of practical interest
and where progress (andkiller products) can be made
Roshan Thomas and Ravi Sandhu, “Towards a Multi-Dimensional Characterization of Dissemination Control.” POLICY04.
7 © Ravi Sandhuwww.profsandhu.com
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-LaPadula 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
8 © Ravi Sandhuwww.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-rootedTrusted Computing assurance ofclient-side controls is very weak
9 © Ravi Sandhuwww.profsandhu.com
PEI Models Framework
Security and system goals(requirements/objectives)
Target platform, e.g., TrustedComputing technology
Enforcement models
Policy models
Implementation models
Horizontalview
Looks atIndividual
layer
VerticalViewLooksAcrossLayers
10 © Ravi Sandhuwww.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
– Enroll TPM (Trusted Platform Module) and LaGrande equipped client computer into a Group
– Within the Group impose additional policy-based controls
Required to support super-distribution
Supports fine-grained controls and policy flexibility
Limits instant and pre-emptive revocation
11 © Ravi Sandhuwww.profsandhu.com
PEI Models Framework
Security and system goals(requirements/objectives)
Target platform, e.g., TrustedComputing technology
Enforcement models
Policy models
Implementation models
Horizontalview
Looks atIndividual
layer
VerticalViewLooksAcrossLayers
12 © Ravi Sandhuwww.profsandhu.com
Various states of a member in a group
Initial state:Never been a
member
State I
Currently a member
State II
Past member
State III
enroll dis-enroll
enroll
13 © Ravi Sandhuwww.profsandhu.com
Access policies for State I
Initial state:Never been a
member
State I
Currently a member
State II
Past member
State III
enroll dis-enroll
1. Straight-forward. User has no access to any group documents.
enroll
14 © Ravi Sandhuwww.profsandhu.com
Access policies for State II
Initial state:Never been a
member
State I
Currently a member
State II
Past member
State III
enroll dis-enroll
1. Access to current documents only (or)2. Access to current documents and past
documents3. Access can be further restricted with rate
and/or usage limits4. Access can be further restricted on basis
of individual user credentialsenroll
15 © Ravi Sandhuwww.profsandhu.com
Access policies for State III
Initial state:Never been a
member
State I
Currently a member
State II
Past member
State III
enroll dis-enroll
1. Past member loses access to all documents (or)2. can access any document created during his membership (or)3. can access documents he accessed during membership (or)4. can access all documents created before he left the group (this
includes the ones created before his join time)5. all subject to possible additional rate, usage and user
credential restrictionsenroll
16 © Ravi Sandhuwww.profsandhu.com
Access policies for State II.re-enroll
Initial state:Never been a
member
State I
Currently a member
State II
Past member
State III
enroll dis-enroll
1. No rejoin of past members is allowed, rejoin with new ID (or)
2. Past members rejoin the group just like any other user who has never been a member
3. The same access policies defined during his prior membership should again be enforced (or)
4. access policies could vary between membership cyclesenroll
17 © Ravi Sandhuwww.profsandhu.com
Use-case 1
Access policies: II.1, III.1, II.re-enroll.1• Intel’s ViiV: A typical scenario in libraries, book-stores, cafes, etc.
a. A master system could be ViiV enabled which subscribes to various kinds of channels from its content providers
b. Many devices can in-turn subscribe to this master device and receive content and thus form a group
c. 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.
18 © Ravi Sandhuwww.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.
19 © Ravi Sandhuwww.profsandhu.com
Use-case 3
Access policies: II.2, III.1, II.re-enroll.1:• An employee in a company can access all the current documents. When he
employee quits, he should lose access to all documents.• DoD 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.
20 © Ravi Sandhuwww.profsandhu.com
Use-case 4
Access policies: II.2, III.2, II.re-enroll.1:• Collaborative product development:
– 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.
21 © Ravi Sandhuwww.profsandhu.com
Various states of an object (document) in a group
Initial state:Never been a
group doc
State I
Currently a group doc
State II
Past group doc
State III
add remove
add
22 © Ravi Sandhuwww.profsandhu.com
Access policies for State I
Initial state:Never been a
group doc
State I
Currently a group doc
State II
Past group doc
State III
add remove
1. Straight-forward. No access to group members.
add
23 © Ravi Sandhuwww.profsandhu.com
Access policies for State II
Initial state:Never been a
group doc
State I
Currently a group doc
State II
Past group doc
State III
add remove
1. Access allowed only to current group members
2. Access allowed to current and past group members
add
24 © Ravi Sandhuwww.profsandhu.com
Access policies for State III
Initial state:Never been a
group doc
State I
Currently a group doc
State II
Past group doc
State III
add remove
1. No one can access2. Any one can access3. Past members can
access
add
25 © Ravi Sandhuwww.profsandhu.com
Access policies for State II.re-add
Initial state:Never been a
group doc
State I
Currently a group doc
State II
Past group doc
State III
add remove
1. Cannot be re-added.2. When a document is re-added, it
will be treated as a new document that is added into the group.
3. Only current members can access.4. Past members and current
members can access add
26 © Ravi Sandhuwww.profsandhu.com
Policy Models
Idealized policy:• Instant revocation• Pre-emptive revocation
Enforcement models will specify degree of approximation (among other details)
27 © Ravi Sandhuwww.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-addedThe PEI models have specific points where such policies are enforced and
remain robust to changes in policy details
28 © Ravi Sandhuwww.profsandhu.com
Usage Control: The UCON Model
Rights(R)
Authorizations
(A)
Subjects(S)
Objects(O)
Subject Attributes (SA) Object Attributes (OA)
Obligations(B)
Conditions(C)
UsageDecisions
before-usage ongoing-Usage after-usage
Continuity ofDecisions
pre-decision ongoing-decision
pre-update ongoing-update post-update
Mutability ofAttributes
• unified model integrating• authorization• obligation• conditions
• and incorporating• continuity of decisions• mutability of attributes
29 © Ravi Sandhuwww.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
30 © Ravi Sandhuwww.profsandhu.com
Policy model: member enroll/dis-enroll
Initial state:Never been a
member
State I
Currently a member
State II
Past member
State III
enroll dis-enroll
memberTS-joinTS-leave
nullnullnull
Truetime of joinnullenroll
Falsetime of jointime of leavedis-enroll
enroll
enroll, dis-enroll: authorized to Group-Admins
UCON elements:Pre-Authorization, attribute predicates, attribute mutability
enroll
31 © Ravi Sandhuwww.profsandhu.com
Policy model: document add/remove
Initial state:Never been a
group doc
State I
Currently a group doc
State II
Past group doc
State III
add remove
D-memberD-TS-joinD-TS-leave
nullnullnull
Truetime of joinnulladd
Falsetime of jointime of leaveremove
add, remove : authorized to Group-Admins
add
UCON elements:Pre-Authorization, attribute predicates, attribute mutability
add
32 © Ravi Sandhuwww.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 mutabilityOngoing-authorization
33 © Ravi Sandhuwww.profsandhu.com
PEI Models Framework
Security and system goals(requirements/objectives)
Target platform, e.g., TrustedComputing technology
Enforcement models
Policy models
Implementation models
Horizontalview
Looks atIndividual
layer
VerticalViewLooksAcrossLayers
34 © Ravi Sandhuwww.profsandhu.com
Enforcement Models
Design Principle• Do not inject new policy• Focus on trade-offs for instant and pre-emptive revocation versus off-line
accessFaithful 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
35 © Ravi Sandhuwww.profsandhu.com
Enforcement Architecture
3
1
2 4 5
Group-Admin MemberJoining Member
Control Center (CC)
7
Faithful Model: steps 3 and 4 are coupledApproximate Model: steps 3 and 4 are de-coupled
D-Member
6
• 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)
Two sets of attributes• Authoritative: as known to the CC• Local: as known on a member’s computer
36 © Ravi Sandhuwww.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
37 © Ravi Sandhuwww.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)
38 © Ravi Sandhuwww.profsandhu.com
Faithful model highlights: (S,O,read)
• Pre-Obligation• Local attributes of S and O are updated based on authoritative values from CC• Local DRL updated from authoritative DRL at CC
• Pre-Condition• Requires connectivity to enable updates
• Pre-Authorization• Based on just updated local attributes of S and O and DRL
• Ongoing-Obligation• 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• 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
39 © Ravi Sandhuwww.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
40 © Ravi Sandhuwww.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
41 © Ravi Sandhuwww.profsandhu.com
PEI Models Framework
Security and system goals(requirements/objectives)
Target platform, e.g., TrustedComputing technology
Enforcement models
Policy models
Implementation models
Horizontalview
Looks atIndividual
layer
VerticalViewLooksAcrossLayers
• Out of scope for this talk
42 © Ravi Sandhuwww.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
43 © Ravi Sandhuwww.profsandhu.com
Q&A Secure Information
Sharing (IS)“Share but Protect”
“Mother of all Security Problems”
TrustedComputing (TC)
Policy-Enforcement-Implementation Layers (PEI)
&Usage Control Models (UCON)
Work in Progress