PEI Models towards Scalable, Usable and High-assurance Information Sharing
description
Transcript of PEI Models towards Scalable, Usable and High-assurance Information Sharing
1
PEI Models towards Scalable, Usable and High-assurance Information Sharing
Ram KrishnanLaboratory for Information
Security TechnologyGeorge Mason University
Kumar RanganathanIntel Systems
Research CenterBangalore, India
Ravi SandhuInstitute for Cyber-Security
ResearchUniv of Texas at San Antonio
2
Presentation Outline
• Problem Description & Motivation• Background
– Trusted Computing– Information Sharing
• PEI Models for SIS• Future Work• Q&A
3
Problem Description & Motivation• Secure Information Sharing (SIS)
– Share but protect• Distribute information and still retain control
– Long-standing and unsolved problem• Current approaches to SIS:
– Discretionary Access Control (DAC), Lampson 1971• Fundamentally limited• 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• Does not scale to fine-grained sharing
– Explosion of security labels– Originator Control (ORCON), Graubart 1989
• Let copying happen but propagate ACLs to copies (or extracts)
4
…continued
• SIS problem further amplified by the client-server model– No control once information leaves server– Current approaches are software-based
• Inherently weak
• Fundamental question:– How can I trust that policies will be enforced on clients in a trust-
worthy manner?• Trusted Computing (TC) Technology features root of
trust at hardware level– Potential to provide strong controls on client– Potential to solve SIS problem
• We need a family of models to guide TC-based solutions
5
Background
6
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
7
TPM: 3 novel features
• Trusted storage for keys– Encrypt user keys with a chain of keys– Root key 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)
8
TPM: An example functionality
• Seal– Trusted capability– Encrypts and binds data to a PCR value– Data can be unsealed iff PCR value at unseal
time matches with PCR value in sealed blob• Seal can be used to restrict data access
– E.g. A program can access sensitive information only if the platform is in trustworthy state
9
What is Information Sharing?
• Share but protect– Distribute information and still retain control
• Requires strong controls on client– Server controls “information release” only
• Purpose is larger than retail DRM... →
10
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.
11
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 areas thatare of practical interest
and where progress can be made
Roshan Thomas and Ravi Sandhu, “Towards a Multi-Dimensional Characterization of Dissemination Control.” POLICY04.
12
PEI Models for SDS
13
SDS Objectives• Super-distribution (encrypt once,
access wherever authorized)– Requires a notion of a “group”
• A subject is authorized to access a document if he is a group member
• Problem scope: group-based SDS
• Offline access• Document-level access control• Read-only document access
Security and system goals(requirements/objectives)
Target platform, e.g., TrustedComputing Technology
Enforcement models
Policy models
Implementation models
14
SDS Policy Model
• Characterize policies applicable to a group-based SDS problem domain
Security and system goals(requirements/objectives)
Target platform, e.g., TrustedComputing Technology
Enforcement models
Policy models
Implementation models
15
Various states of a group member
Initial state:Never been a
member
State I
Currently a member
State II
Past member
State III
enroll dis-enroll
enroll
1. Straight-forward. User has no access to any group documents.
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 credentials
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 restrictions
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 cycles
16
Various states of a group document
Initial state:Never been a
group doc
State I
Currently a group doc
State II
Past group doc
State III
add remove
add
1. Straight-forward. No access to group members.
1. Access allowed only to current group members
2. Access allowed to current and past group members
1. No one can access2. Any one can access3. Past members can
access
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
17
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
18
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
19
Enforcement Models
• Develop enforcement models for SDS
Security and system goals(requirements/objectives)
Target platform, e.g., TrustedComputing Technology
Enforcement models
Policy models
Implementation models
20
SDS Enforcement Model
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
21
Implementation Models
• Develop implementation models for SDS
Security and system goals(requirements/objectives)
Target platform, e.g., TrustedComputing Technology
Enforcement models
Policy models
Implementation models
22
Implementation Model• Build a Trusted Reference Monitor (TRM)
– The reference monitor on the group members that enforces group policies in a trust-worthy manner
• Identify the Trusted Computing Base (TCB)– A minimal collection of entities that is absolutely essential to be
in integral state in order to preserve security of the entire system• Objective
– Build a TCB in order to enforce document read on group members using a TRM
• Two Key requirements– Only TRM can access the group key and read/write subject and
object attributes– TRM is provided with isolated environment to safely use the
group/document keys
23
Implementation Model (continued)
TPM
VMM
Update Internal PCR
Linux Kernel + TPM Driver + MAC Policies
Internal PCRs
AppPCRs
TRM TVTSS
Indirect communication
Boot time measurement
Isolated executionVM0
VM1
• Use TC mechanisms to bind group key + attributes to TRM
24
Future Work• Formal analysis of SIS
policy models– SDS: object level– SCS: attribute level
• Document/object Read and Write
• SIS across multiple groups– Information flow issues
• Document/object-level querying– Obtain sections of
document/object
Coffee Shop Book Store
Credit Credit
Alice
SCS in M-commerce Scenario
25
Q&A
Thanks!
InformationSharing
Policy, Enforcement, Implementation (PEI) layers
Trusted Computing (TC)Usage CONtrol model (UCON)
26
Backup
27
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
28
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
29
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)
30
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
31
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
32
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
33
Contributions & Conclusions• SIS is a broad and complex problem
– PEI framework, UCON model and TC are highly useful for approaching the SIS problem space
• First steps towards developing a family of models for SIS problem domain– Classify SIS into two distinct levels:
• Object-level SIS• Attribute-level SIS
– Analyze object-level and attribute-level SIS• Demonstrate how TC can be used to address this long-
standing problem• Possibly extend the UCON model• Leave with more open questions!