Transcript Rights management

Rights management
Vicky Weissman
[email protected]
Policies


A policy is a set of a conditions under which
an action is permitted or forbidden.
Simple examples:



CS 502 students cannot edit the course website.
A student can only modify a course web page with
the instructor’s permission.
More complicated examples:


To borrow a book from the library, you must have
a library card and you must either bring the book
back in 2 weeks or pay a fine.
A license is a type of policy; it says what a client
needs to do to access a resource legitimately.
A policy is a set of a conditions under
which an action is permitted or
forbidden.
Goals
We want to:


Write policies unambiguously.
Reason about the policies in a provably
correct way.



Is a particular action such as Alice editing the
CS 502 web site allowed? Forbidden?
Are the policies consistent? In other words,do
they allow and forbid the same action?
Enforce the policies in a provably correct
way.
Writing unambiguous policies

Policies written in natural languages,
like English, are often ambiguous.

Ex: A student can only modify a course
web page with the instructor’s permission.
Writing unambiguous policies

Policies written in natural languages,
like English, are often ambiguous.


Ex: A student can only modify a course
web page with the instructor’s permission.
If the student has the instructor’s
permission, can the student edit the page?
Writing unambiguous policies

Policies written in natural languages,
like English, are often ambiguous.



Ex: A student can only modify a course
web page with the instructor’s permission.
If the student has the instructor’s
permission, can the student edit the page?
Does the policy apply to courses with
multiple instructors? If so, whose
permission do you need?
Isn’t this an old problem?


Well, yes. But policies for digital objects can
be more complex.
Consider a library patron borrowing a book


If it’s a digital object, pictures can be blurred or
hidden, according to a policy agreement. Certain
portions of the text can be blocked out.
If it’s a physical book, the library either needs a
copy for each type of policy or can only regulate
who sees the book as a single unit.
Automatic enforcement

Digital works typically are protected by
automatic means (e.g. software), so
there’s no person we can trust.


We can tell a librarian what the policies are
and, if we haven’t considered a scenario,
then the librarian can ‘do something
reasonable’.
If a computer program gets input that it
wasn’t expecting, what’s the likelihood that
it will do something reasonable?
Bottom line



We want to state, reason, and enforce
policies.
The policies we’re interested in are
more complex than we’ve had before.
The standard solution of relying on a
trusted person to ‘act reasonably’ is no
longer an option.
Current solutions in industry

Make policies VERY simple.



For example, digital libraries often only
have digital objects that are in the public
domain.
Alternatively, many libraries only
differentiate between subscribers and nonsubscribers.
Use a commercial right’s language
(eg. XrML, ODRL, …).
XrML

Looks like HTML.


Has tons of predefined tags like:
<LOCATION country = “us” state = NY>
Allows people to make new tags for their
specific needs.
Benefits of using XrML

Popular.




Policy makers don’t have to learn too much
‘new lingo’ when going from app to app.
Allows common enforcement mechanisms
across apps.
Fairly easy to use.
Extremely flexible.
Disadvantages of XrML

No formal semantics.



Semantics tell us what the symbols in a language
mean.
The only meaning I’ve found given to the predefined
tags are in English – which we’ve already argued is
ambiguous.
If we don’t have unambiguous semantics, then we
cannot hope to reason about policies or enforce
them in a provably correct way.
People who use XrML are writing policies that ‘seem right’ without
anyone knowing precisely what is intended or exactly what is
allowed.
Other options - use logic

Policies can be expressed in first-order
logic.
Example:
students cannot edit the website
i (student(i) => ¬Permitted(i, edit website))

Semantics tell us what the
symbols in a language mean.
Pros and Cons of using logic

Benefits




Well-understood.
Extremely flexible.
Has formal semantics.
Disadvantages


Not user-friendly -> needs intuitive GUI.
Most interesting questions are provably
undecidable -> need to find a fragment of
first-order logic that is expressive and
tractable.
Another option:
Regular expressions

Policies are captured by automatons.
give CUID
Start
State
pay fee
give acct #
use photocopier
Above automaton says the photocopier can be used by anyone
whose paid the fee or has given both a CUID and an acct
number.
Semantics tell us what the
symbols in a language mean.
Pros and cons of reg. expr.

Pros




Well-understood.
Easy to give formal semantics.
Easy to reason about.
Cons


Not as expressive as first-order logic.
Not as user-friendly as natural languages
or commercial rights languages like XrML.
Reasoning about policies


for policies written in any language
without formal semantics – this includes
natural languages like English, XrML,
ODRL – reasoning requires a judge
for policies written as regular
expressions – reasoning strategy
depends on the chosen formal
semantics.
Reasoning about policies in
first-order logic


Can Alice edit 502 web site?
Given:



policies p1, …, pn (written in fol) and
facts about the world E
(e.g. Senior(Alice)  (i (Senior(i) => Student(i)))  …)
Alice can edit if:
E  p1  …  pn => Permitted(Alice, edit 502 site)
is valid (i.e. if E and all the policies hold, then Alice may
edit the site, regardless of any other policies and facts).
Enforcement


There are lots of mechanisms to
enforce policies. For an overview, take
Prof. Schneider’s CS 513: System
Security course or read the course’s
notes.
One interesting mechanism that is
particularly well-suited to digital objects
is in-line reference monitors (IRM).
IRM idea



Suppose you wanted to write a code fragment A that
could only be executed by students. You could write:
if (student) {A}
But if you did this, then the policy and ‘real code’ are
mushed together so its hard to see what either is doing
and it’s hard to modify either component (e.g. change
‘students’ to ‘students and faculty’).
The IRM idea is to write and maintain the policy and
code separately. Immediately before execution, the IRM
monitor interleaves them.
Conclusion





Policies are becoming increasingly complex and
the solution in the physical world doesn’t
translate to cyberspace.
There are a lot of ways to write policies, but
none is a clear winner.
Need formal semantics if you’re going to reason
and/or enforce policies in a provably correct
way.
Formal semantics may not be enough to do this.
There are a ton of open questions, got research?