Download Mason Template 1: Title Slide

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-EnforcementImplementation 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
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.
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 stateFlexible,
of knowledge
multi-step, and multi-point.
the informationSupport
sharing
space
Simple, read-only and singlefor complex, multi-version
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
Attribution
can only
be
Look for
sweet
spots
thatAttribution is system enforced.
legally enforced.
are of practical interest
Complex policy-based revocation.
No timeliness guarantees.
to take immediate
and where
progress (andGuaranteed
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.” POLICY04.
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
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
Security and system goals
(requirements/objectives)
Policy models
Horizontal
view
Enforcement models
Looks at
Individual
layer
Implementation models
Vertical
View
Looks
Across
Layers
9
Target platform, e.g., Trusted
Computing technology
© 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 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
10
© Ravi Sandhu
www.profsandhu.com
PEI Models Framework
Security and system goals
(requirements/objectives)
Policy models
Horizontal
view
Enforcement models
Looks at
Individual
layer
Implementation models
Vertical
View
Looks
Across
Layers
11
Target platform, e.g., Trusted
Computing technology
© 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 II
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 II
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 II
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
enroll
Initial state:
Never been a
member
Currently a
member
Past member
State III
State II
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 II
State I
enroll
16
disenroll
© Ravi Sandhu
www.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.
b.
c.
•
17
A master system could be ViiV 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.
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.
© Ravi Sandhu
www.profsandhu.com
Use-case 4
Access policies: II.2, III.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 I
State II
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 I
State II
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 I
State II
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 I
State II
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 I
State II
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
Rights
(R)
Subjects
(S)
Objects
(O)
Usage
Decisions
Subject Attributes (SA)
Authoriz
ations
(A)
Continuity of
Decisions
28
pre-decision
ongoing-decision
before-usage
ongoing-Usage
pre-update
ongoing-update
Mutability of
Attributes
Object Attributes (OA)
Obliga
tions
(B)
Condi
tions
(C)
after-usage
post-update
© 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
enroll
member
TS-join
TS-leave
null
null
null
enroll
True
time of join
null
dis-enroll
enroll
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 II
State I
enroll
30
disenroll
UCON elements:
Pre-Authorization, attribute predicates, attribute mutability
© Ravi Sandhu
www.profsandhu.com
Policy model: document add/remove
add
D-member
D-TS-join
D-TS-leave
null
null
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 I
State II
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
Security and system goals
(requirements/objectives)
Policy models
Horizontal
view
Enforcement models
Looks at
Individual
layer
Implementation models
Vertical
View
Looks
Across
Layers
33
Target platform, e.g., Trusted
Computing technology
© 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
Security and system goals
(requirements/objectives)
Policy models
Horizontal
view
Enforcement models
Looks at
Individual
layer
• Out of scope for this talk
Implementation models
Vertical
View
Looks
Across
Layers
41
Target platform, e.g., Trusted
Computing technology
© 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-EnforcementImplementation Layers (PEI)
&
Usage Control Models (UCON)
43
Trusted
Computing (TC)
© Ravi Sandhu
www.profsandhu.com