From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with archive (Exim 4.43) id 1Mdl9r-0001d0-IQ for mharc-grub-devel@gnu.org; Wed, 19 Aug 2009 09:24:55 -0400 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Mdl9p-0001ct-Jw for grub-devel@gnu.org; Wed, 19 Aug 2009 09:24:53 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Mdl9o-0001cZ-Ij for grub-devel@gnu.org; Wed, 19 Aug 2009 09:24:52 -0400 Received: from [199.232.76.173] (port=50850 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Mdl9o-0001cW-Dy for grub-devel@gnu.org; Wed, 19 Aug 2009 09:24:52 -0400 Received: from mammon.mene.za.net ([78.46.253.195]:54288 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 1Mdl9n-0003qI-JP for grub-devel@gnu.org; Wed, 19 Aug 2009 09:24:52 -0400 Received: from mail.mene.za.net (localhost [127.0.0.1]) by mail.mene.za.net (Postfix) with ESMTP id A89E97E41C for ; Wed, 19 Aug 2009 15:24:49 +0200 (SAST) 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=lxoR/bwaEpPqC C/eie8LwK6chOw=; b=j7Q8r63dLVyiWdJ1fTIaqTIULS0Exd8p0kRRE3p2pqWsy km22zjCChjupAezSEFNoZBxqznBQBC0OfRZwzogsy5fcYTVfArStdSZ3xt3cjYxb Gibs9ZKh4tQ5zrCUZojf6nabX5zmFb/zhYZHcUUmrFVrnv2gM3hNPRX/j+MsW4= 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=JdfV+Sq dVcqWGxCjgh9FGgzVc6xnam8x3cwqcjVmEcEn0wxHUxKcn/fDbF+OtH0lef5ctph fc5YzlE1YAUc/OGT1oaGKJmZtCZ3FdkXRoXvxzylkmVSjIR3524exe7XpDKevzfn uhCgkhUgX3j6hevWnxWK87OMBShoytvg91lM= Received: from molech (dsl-241-125-225.telkomadsl.co.za [41.241.125.225]) by mail.mene.za.net (Postfix) with ESMTPSA id 9528F7E270 for ; Wed, 19 Aug 2009 15:24:48 +0200 (SAST) From: Michael Gorven To: The development of GRUB 2 Date: Wed, 19 Aug 2009 15:24:34 +0200 User-Agent: KMail/1.9.10 References: <4A8BDB5B.5000407@labri.fr> <200908191425.29202.michael@gorven.za.net> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart2177150.IQDeJlQu0Q"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200908191524.42432.michael@gorven.za.net> X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.6 (newer, 2) Subject: Re: TPM support status ? 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: Wed, 19 Aug 2009 13:24:53 -0000 --nextPart2177150.IQDeJlQu0Q Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Wednesday 19 August 2009 14:42:37 Vladimir 'phcoder' Serbinenko wrote: > Even if they can't stop from working at all they can make it > effectively useless by e.g. not allowing you to see online videos, buy > online or even just send an e-mail (saying it's "spam control") if you > aren't TPM-checked That falls under the supporting-possibly-harmful-technology argument. It's = not=20 very different from saying "you must use Silverlight to view videos" and=20 whatnot. If you don't want to follow their requirements, then don't. > >> 2) The similar features can be implemented without resorting to TPM by > >> using coreboot and make every stage verify the signature of every next > >> stage. > > > > Trust has to start somewhere, and the more difficult it is to compromise > > that the better. > > flash rom with cut write wire is impossible to compromise without > physical access. Valid solution, but does it protect the contents of the flash ROM? (i.e. ca= n=20 you read the contents?) A minor point is that it does mean you can't upgrad= e=20 your BIOS anymore. It also gets tricky if you're wanting to securely store = a=20 hardrive decryption key though. > >> > 3) Read the PCR (TPM_PCRRead command) and compare it to a recorded > >> > value of a previous (safe) boot. We assume that the previous link of > >> > the chain of trust (BIOS?) has already checked that GRUB hasn't been > >> > tampered before starting it. > >> > >> You propose to check that our checksum in PCR is ok but you already > >> assume GRUB wasn't tampered. If you assume grub wasn't tampered no > >> need to checksum. If you don't it's useless to checksum. > > > > That isn't assumed -- the BIOS checks that GRUB isn't tampered with > > before moving control to it. > > Coreboot can make this too. And firmware doesn't need TPM to do such > checks. Yes, except coreboot isn't widely supported. > >> > A full support of TPM means that GRUB should also be able to ask to a > >> > remote authority if the content of the PCR is still ok... > >> > >> Why do I as user need someone else to check my computer? > > > > Because you don't always own or completely control the computer. > > Then someone is already holding you hostage. We won't help them to > restrict your freedom further. Or you're the person who owns and wants to secure the computer. Maybe you w= ant=20 to co-locate your server and make sure the technicians at the DC can't=20 compromise it, or you're guarding against data loss if your laptop gets=20 stolen without having to enter decryption passwords on boot, or a whole lot= =20 of other situation where *you* are putting *your* computer in an untrusted= =20 environment. > How? Respond to questions I asked (the 4 crypto questions). During > your whole discussion you assumed that attacker already has root > access and argued how to prevent him from changing the kernel. But > what's the use if he already has root access (or in other words > already has the security on the knees and can do whatever he wants). > 1) "Which attacks is it supposed to deflect?" My main use case is unattended booting with an encrypted harddrive, and=20 protecting against physical access or theft. > 2) "Does it deflect those attacks?" It seriously raises the bar to such attacks, since the attacker would need = to=20 pry the decryption key out of the hardware. > 3) "How much does the security costs?" (in money, ressources and > inconvinience) The cost of a TPM chip and some setup time. > 4) "Which other holes does it open?"=20 Obviously the TPM could have flaws which cause it to divulge the decryption= =20 key. I don't see it lessening the security of the system though. > > The only valid argument I see against TPM is the > > supporting-possibly-harmful-technology one. But then we shouldn't use > > crypto at all because it can be used for DRM... > > It's not just "possibly harmful", it's "designed with harm in the mind". Disagree. Michael =2D-=20 http://michael.gorven.za.net PGP Key ID 1E016BE8 S/MIME Key ID AAF09E0E --nextPart2177150.IQDeJlQu0Q 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) iQIVAwUASov9GoOxIz1l+OmhAQqtqQ/+Oc8B6gsNw7Ze/T5QVsfH7Ha0Kfml5KBa FxIvmPi2C05g8b6xdr5fMNYn6NoAOYWY+77Zvg4QkaGZ2MQh54l1R88uvPljjRlH aX6kTxEBBvBZ7e5xr3AMCx5BYwt6fTWKJdLobIMaaqkhHawgDr9cP5aviMLvjHXB kjrY2uQiKkd4hi2Gw3Bd3vzQzCQrnV1EDzpBwM2CZINq0HK/a0dL9nKNra0Of3gI wuu4dR18qAylczTYpwePZZxE6da4UEAvXSyuMSEbWa1zs1heoqyMcpfl5iTk45Nw u3PsYfFpsIP+Miey2LKgPhVp4j0q0OsYOOveRBhSsrdz2kangrhE4fsVBSoK0f8O GB5v4SvrkNRsMhCjnbxqijPYRforWw/dcbTsIlcWf4k+S9zbTKgh3f2eioWP7ak8 jNTcr1xTMK8aGOzL1vOdHItsWIQtc6W5OzO0w2E33BjpJ08GBiL735WUix1L1kQA dQZ9NcsNDi+kytt2qEDYtzdlH8KIYvQkZ2cLAKhUIaASwArZBQzcLikUmzx0fmzp /ACgrg+eMeR3RXyUPMwBfIwAy5HRs43TeWdKbsiXX9EV5GW2tCwbug5Kpm3hig34 EfSg8rJj2+2ZWrBIUiC1xnLmAXyNf/aRCt2B5iqqHst8FqKM7GKcAIbnzrg7w3Yq Pf2EBhWpWcs= =qR42 -----END PGP SIGNATURE----- --nextPart2177150.IQDeJlQu0Q--