[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Confinement (even with TPMs) and DRM are not mutually exclusive

From: Eric Northup
Subject: Re: Confinement (even with TPMs) and DRM are not mutually exclusive
Date: Wed, 7 Jun 2006 11:55:35 -0400

On Jun 7, 2006, at 1:17 AM, Jonathan S. Shapiro wrote:

On Tue, 2006-06-06 at 14:48 -0400, Eric Northup wrote:
On Tue, 2006-06-06 at 14:37, Marcus Brinkmann wrote:
  A practical consequence is
that the user stops using the options, because they break the programs
that the user is expecting to work.  [...]

Exactly. That's why the system should not* provide a way to authenticate
the low-level services which might be (ab)used to implement freedom-
restricting DRM policies.

How do you propose to enforce this? In general, programs must be able to authenticate the implementations of their service providers in order to
check that their robustness contract preconditions can in fact be

The problem here is that there is no operational difference between a
DRM subsystem checking that it is talking to an EvilDevice driver vs. a
constructor checking that it is using an authentic space bank. The
mechanism of authentication is the same in both cases.

There is an important difference between the constructor/space bank
scenario and the media player/audio driver scenario: the constructor
and the space bank ship together.  So, the constructor can examine
capabilities to check if they designate the space bank which the
constructor already has a capability to.

By contrast, a DRM enabled media player does not ship together with
all the audio output drivers.  So it does not have a mechanism to
certify that a capability given to it is a genuine DRM-friendly

On a system with a TPM, it could use the TPM to authenticate the audio
driver anyway.  My proposal was to *severly restrict* (or forbid
entirely) the set of objects in the system which would be permitted to
use the TPM to authenticate direct output drivers.  Instead, the best
they could do is to use the TPM to authenticate the higher-level
session objects (whose contract would be carefully designed to allow
normal use but not DRM-type use).


reply via email to

[Prev in Thread] Current Thread [Next in Thread]