[Top][All Lists]

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

Re: Yes TPMs are evil :-(

From: Jonathan S. Shapiro
Subject: Re: Yes TPMs are evil :-(
Date: Mon, 06 Nov 2006 07:07:04 -0500

On Mon, 2006-11-06 at 14:04 +0300, Anton Tagunov wrote:
> Sorry I've been proven wrong.
> I've been missing the point of "remote attestation".
> A third party CAN very what soft I'm running via tpm.

Exactly. However:

In order for attestation to work, the local OS must cooperate with the
remote attestation request. In principle, it is possible to *enable* the
TPM chip and then operate in one of the following ways:

  1. OS never replies to an attestation request
  2. OS only supports attestation with user permission
  3. OS always responds to attestation without consulting

(3), obviously, would be a very bad outcome. (2) is likely in the same
sense that your browser asks you things like "do you want to send
information over an insecure connection?" -- the user will always say
yes. (1) is what I expect the hurd will do.

Given the position that the Hurd team has adopted, Hurd basically has
two options:

  0. Ignore the TPM chip
  1. Do not support TPM attestation functions

My recommendation is that Hurd should consider a third position: adopt
(1) with **very limited** attestation functions. Specifically:

  A. Let the chip check the microkernel image (only) so that TPM secure
     storage can be used.
  B. Do not expose any attestation *above* the microkernel. This
     means that no guarantee about applications can be supported,
     which is enough to disable DRM.
  C. Use TPM secure storage for bootstrapping local crypto keys.

This is enough to support locally encrypted disk and reasonable local
security without supporting DRM. A further option would be to do
attestation of kernel and Hurd TCB utilities, but not other
applications, which would allow mutually attested Hurd federations.

The key point here is that DRM breaks if any step in the chain breaks.
In order to disable DRM, it is sufficient to disable attestation of the


reply via email to

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