Re: digital-copyright Digest 23 May 2002 15:00:00 -0000 Issue 1

["John Erickson" <john_erickson@xxxxxxxxxxxxxxx>]

Chuck Hamaker writes:

> ...There are two major approaches to DRM I think...

He then goes on to describe two methodologies, one dealing with media-level
enforcement of implicit policies, and one a network-based approach. Both of the
solutions he describes are well-known.

While no generally-accepted toxonomy for DRM exists, recent work by Jaehong
Park, Ravi Sandhu and other colleagues at George Mason Univ. has produced a
great model. Their argument in [1] is that there are essentially eight distinct
variations, with increasing levels of felixbility and "originator control."
Current state-of-the-art technologies (e.g. Microsoft, Intertrust, IBM,
RealNetworks/Aegisoft) look more like the most flexible of these (see below)

They differentiate based upon three factors: whether or not an architecture
utilizes a "virtual machine" (e.g. a distinct DRM client); whether the "control
set" (license package, enumerating the client's usage capabilities or "rights")
are external or embedded; and whether the content is distributed via an
"external repository" or through so-called "message push" (individually sent to
each client).

Briefly, their breakdown is as follows (the designations are theirs). For
completeness, two non-DRM cases are mentioned first:

1. No Control Architecture (i.e. no VM) w/ message push (NC1): This is normal
file sharing

2. No Control Architecture w/ external repository (NC2): This is normal
downloading, possible with secured access to the server.

3. Fixed Control Architecture w/ message push (FC1): Control set (the rules) are
built into the VM and can't be changed. This is equivalent to receiving content
that is secured to a particular application.

4. Fixed Control Architecture w/ external repo (FC2): Control set built into the
VM, but this time the client must connect to a server to obtain the content. VM
could control operations on the downloaded content, such as saving.

5. Embedded Control Architecture w/ message push (EC1): Control set is built
into the content package (container) and can be configured at packaging time.
With MP, content is sent to individual users. Originator cannot change control
set once content is distributed.

6. Embedded Control Architecture w/ external repo (EC2): Control set again built
into content package, but this time user is downloading from server. Again, VM
could control local operations of downloaded content, such as saving.

7. External Control Architecture w/ message push (XC1): This is the first of the
two options which looks the most like hard-core, distributed DRM solutions. In
this model the content distribution and license generation are orthogonal
(indepedent), and in particular the content package may be freely distributed
amongst users. Only users who have been issued license packages (the control
set) may access the content.

Because license generation is separate from content deployment (in time and
space), originators retain a high degree of controllability and flexibility.
There are two subtle variants of this model --- in the first case, the client
code must "phone home" to obtain the license package upon each access attempt;
in the second, the license may be locally stored, usually with a time-to-live
(for the license package, not necessarily the rights themselves) to help bound
the revocation problem.

8. External Control Architecture w/ external repo (XC2): Same as XC2, but based
upon streaming (there are some sub-variants based upon access to the repository
and whether the content is allowed to be stored on the client machine).

I've been 'way too brief with this, but you should be able to see the
distinctions...generally speaking, the variant XC1 is the most flexible in terms
of distributed architecture, and is what the Microsoft, Intertrust, IBM and
RealNetworks, and other solutions look like. The important thing to observe is
that a flexible architecture should accomodate separate content and license
generation services, so that content may flow independently while license
generation can be arbitrarily client-specific. Note also that transactions are a
whole separate issue --- to properly think about this, you've got to have
transactions out-of-band or orthogonal to content deployment and license
generation (but obviously related). That what, you can map DRM architectures
onto other notions of group membership, such as department membership,
affiliation with a consortium, etc.

NOT discussed by Park et.al. is the requirement for a "trusted execution
environment" for the VM --- DRM clients that operate solely at the user level
(speaking in OS terms) with no kernel-level roots of trust are fundamentally
flawed; Mark Stefik wrote generally about this a number of years ago [2], and
some of the DRM vendors have provided proprietary trusted execution environments
for some time. Note that pointing out this sort of thing is beyond the scope of
Park & Sandhu's toxonomy. The astute reader should recognize also that
principles of code authentication and trusted execution are at the root of the
Intertrust/Microsoft infringement suits.

John

[1] Jaehong Park, Ravi Sandhu and James Schifalacqua, "Security Architectures
for Controllerd Digital Information Dissemination," Proceedings of the 16th
Annual Computer Security Applications Conference (IEEE) 2000.

[2] Mark Stefik, "Trusted Sytems," Scientific American, March 1997. See
http://www.sciam.com/0397issue/0397stefik.html

[3] InterTrust Technologies Corp., "InterTrust Expands Patent Infringement Suit
Against Microsoft to Include Windows File Protection," March 2002. See
http://www.intertrust.com/main/home/press/2002/020313_wfp.html

| John S. Erickson, Ph.D.
| Hewlett-Packard Laboratories
| PO Box 1158, Norwich, Vermont USA 05055
| 802-649-1683 (vox) 802-371-9796 (cell) 802-649-1695 (fax)
| john_erickson@xxxxxxxxxx         AIM/YIM/MSN: olyerickson