From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with archive (Exim 4.43) id 1LayhQ-0002Kq-4P for mharc-grub-devel@gnu.org; Sat, 21 Feb 2009 15:43:48 -0500 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1LayhO-0002K6-99 for grub-devel@gnu.org; Sat, 21 Feb 2009 15:43:46 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1LayhN-0002Jg-JS for grub-devel@gnu.org; Sat, 21 Feb 2009 15:43:45 -0500 Received: from [199.232.76.173] (port=39526 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1LayhN-0002Ja-Bk for grub-devel@gnu.org; Sat, 21 Feb 2009 15:43:45 -0500 Received: from mammon.mene.za.net ([78.46.253.195]:52190 helo=mail.mene.za.net) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1LayhM-000258-Sd for grub-devel@gnu.org; Sat, 21 Feb 2009 15:43:45 -0500 Received: from mail.mene.za.net (localhost [127.0.0.1]) by mail.mene.za.net (Postfix) with ESMTP id 75F3C33A5E3 for ; Sat, 21 Feb 2009 21:43:40 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=gorven.za.net; h=from:to :subject:date:references:in-reply-to:mime-version:content-type :content-transfer-encoding:message-id; s=alpha; bh=r41z/hCOPWZhb 6Du+4wcgI6FWNU=; b=B/vhTp+98EeVR8rBYr/Q+60ZsD1Xmg2nLgSQzEnGdZ/oV ybue9pZ08T85yXg5UlT3CNRdpFQJEkga6SP/fcafCIBDpeW8+T5Rk60fazKTgcCE k5AQRqC/MJWXTdDfWiSQpCKk1t7Wxk9mIbBXtN1d+PKrxvyvB96wXeEzOYy+To= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gorven.za.net; h=from:to:subject :date:references:in-reply-to:mime-version:content-type :content-transfer-encoding:message-id; q=dns; s=alpha; b=R7hehpW G5jhD7JAQoU9ag5NMuooAChxPmlc/hp6iV5dc+oqkgKrKLYZ2VaP8U3Iin0eGkTN vQaXs2kfHfMtjFbjxg4ybmTc2AojThCFLNNr3gUtZ2yb/THjNh75ZhQDmtwvW74B R+BzVsnfTisW85AlYp/sDF9Lj6nuRlR5Y2Qc= Received: from molech (dsl-241-58-76.telkomadsl.co.za [41.241.58.76]) by mail.mene.za.net (Postfix) with ESMTPSA id D2E9333A5D4 for ; Sat, 21 Feb 2009 21:43:39 +0100 (CET) From: Michael Gorven To: The development of GRUB 2 Date: Sat, 21 Feb 2009 22:43:16 +0200 User-Agent: KMail/1.9.10 References: <200902211729.52450.michael@gorven.za.net> <20090221203136.GF18492@thorin> In-Reply-To: <20090221203136.GF18492@thorin> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart2263359.EBQ3HWYAmb"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200902212243.31194.michael@gorven.za.net> X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.6 (newer, 1) Subject: Re: A _good_ and valid use for TPM X-BeenThere: grub-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: The development of GRUB 2 List-Id: The development of GRUB 2 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Feb 2009 20:43:46 -0000 --nextPart2263359.EBQ3HWYAmb Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline 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.=20 > > > From that point physical access can be managed with traditional metho= ds > > > (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 t= o=20 store a disk encryption key sealed with PCR registers, so that it would onl= y=20 be provided once it's been verified that GRUB hasn't been changed.=20 (Personally I wouldn't want to use remote attestation at all.) Michael =2D-=20 http://michael.gorven.za.net PGP Key ID 6612FE85 S/MIME Key ID AAF09E0E --nextPart2263359.EBQ3HWYAmb Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQBJoGdzO9SWvWYS/oURAqHfAJ99CLicNPVAfwcmrv/8fxZU+yV4FQCgl0qc PEwfjf4V+o7ZDJzAH0Fhcps= =ZG2+ -----END PGP SIGNATURE----- --nextPart2263359.EBQ3HWYAmb--