|
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 isthat the user stops using the options, because they break the programsthat the user is expecting to work. [...]Exactly. That's why the system should not* provide a way to authenticatethe 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 tocheck that their robustness contract preconditions can in fact be satisfied. The problem here is that there is no operational difference between aDRM subsystem checking that it is talking to an EvilDevice driver vs. aconstructor 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 driver. 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). -Eric
[Prev in Thread] | Current Thread | [Next in Thread] |