[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: A _good_ and valid use for TPM
From: |
Michael Gorven |
Subject: |
Re: A _good_ and valid use for TPM |
Date: |
Sat, 21 Feb 2009 22:43:16 +0200 |
User-agent: |
KMail/1.9.10 |
On Saturday 21 February 2009 22:31:36 Robert Millan wrote:
> On Sat, Feb 21, 2009 at 05:29:34PM +0200, Michael Gorven wrote:
> > On Saturday 21 February 2009 15:51:42 Robert Millan wrote:
> > > On Fri, Feb 20, 2009 at 09:45:28AM +0200, Michael Gorven wrote:
> > > > TPM can be used for good or for bad, but this is the case for
> > > > everything involving cryptography. We don't refuse to use encryption
> > > > algorithms because they could be used for DRM, so why should we
> > > > refuse to use TPM?
> > >
> > > I don't agree with this analogy. Unlike cryptography, TPMs have been
> > > designed from the ground up to serve an evil purpose. They *could*
> > > have designed them with good intent, for example either of these could
> > > apply:
> > >
> > > - Buyer gets a printed copy of the TPM's private key when they buy a
> > > board.
> > >
> > > - An override button that's physically accessible from the chip can
> > > be used to disable "hostile mode" and make the TPM sign everything.
> > > From that point physical access can be managed with traditional methods
> > > (e.g. locks).
> > >
> > > But they didn't.
> >
> > 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.)
Michael
--
http://michael.gorven.za.net
PGP Key ID 6612FE85
S/MIME Key ID AAF09E0E
signature.asc
Description: This is a digitally signed message part.
- Re: A _good_ and valid use for TPM, (continued)
- Re: A _good_ and valid use for TPM, Michael Gorven, 2009/02/20
- Re: A _good_ and valid use for TPM, phcoder, 2009/02/20
- Re: A _good_ and valid use for TPM, Michael Gorven, 2009/02/20
- Re: A _good_ and valid use for TPM, Jan Alsenz, 2009/02/20
- Re: A _good_ and valid use for TPM, Vesa Jääskeläinen, 2009/02/20
- Re: A _good_ and valid use for TPM, Jan Alsenz, 2009/02/20
- Re: A _good_ and valid use for TPM, Robert Millan, 2009/02/21
- Re: A _good_ and valid use for TPM, Robert Millan, 2009/02/21
- Re: A _good_ and valid use for TPM, Michael Gorven, 2009/02/21
- Re: A _good_ and valid use for TPM, Robert Millan, 2009/02/21
- Re: A _good_ and valid use for TPM,
Michael Gorven <=
- Re: A _good_ and valid use for TPM, Robert Millan, 2009/02/21
- Re: A _good_ and valid use for TPM, Jan Alsenz, 2009/02/21
- Re: A _good_ and valid use for TPM, phcoder, 2009/02/21
- Re: A _good_ and valid use for TPM, Robert Millan, 2009/02/21
- Re: A _good_ and valid use for TPM, Jan Alsenz, 2009/02/21
- Re: A _good_ and valid use for TPM, Robert Millan, 2009/02/21
- Re: A _good_ and valid use for TPM, Jan Alsenz, 2009/02/21
- Re: A _good_ and valid use for TPM, Robert Millan, 2009/02/21
- Re: A _good_ and valid use for TPM, Isaac Dupree, 2009/02/21
- Re: A _good_ and valid use for TPM, Robert Millan, 2009/02/27