Re: A _good_ and valid use for TPM

[Robert Millan <rmh@aybabtu.com>]

On Sat, Feb 21, 2009 at 10:43:16PM +0200, Michael Gorven wrote:
> > > Just to clarify, are you objecting to the use of TPM on principle and
> > > because you don't want to encourage use of it, or because you think this
> > > specific use (trusted boot path) is dangerous?
> >
> > I can't reply to this question, because it's not just a specific use, it's
> > part of the design, of its purpose.  One of the design goals is remote
> > attestation, which is a threat to our freedom and is unethical.
> >
> > If there was a device that behaves like a TPM except remote attestation is
> > not possible (e.g. by one of the means described above), I wouldn't object
> > to it, and I think the GNU project wouldn't either, but then referring to
> > that as "TPM" is misleading.
> 
> I wasn't actually referring to the remote attestation. Just using the TPM to 
> store a disk encryption key sealed with PCR registers, so that it would only 
> be provided once it's been verified that GRUB hasn't been changed. 
> (Personally I wouldn't want to use remote attestation at all.)

First of all, I think it's a poor approach, because there's no way to garantee
the TPM is doing what it's supposed to (can you read its source code?  how do
you know for sure there are no backdoors?).

But the important here is not whether there's something wrong with the use case
you described or not.  The important is that this use case is lumped together
with something seriously nasty, and that its promoters are acting
irresponsibly by not allowing us to make the distinction.

-- 
Robert Millan

  The DRM opt-in fallacy: "Your data belongs to us. We will decide when (and
  how) you may access your data; but nobody's threatening your freedom: we
  still allow you to remove your data and not access it at all."