From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with archive (Exim 4.43) id 1Mdq20-0003lf-Bt for mharc-grub-devel@gnu.org; Wed, 19 Aug 2009 14:37:08 -0400 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Mdq1y-0003la-FR for grub-devel@gnu.org; Wed, 19 Aug 2009 14:37:06 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Mdq1t-0003lO-OF for grub-devel@gnu.org; Wed, 19 Aug 2009 14:37:05 -0400 Received: from [199.232.76.173] (port=55893 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Mdq1t-0003lL-Ii for grub-devel@gnu.org; Wed, 19 Aug 2009 14:37:01 -0400 Received: from vader.rez-gif.supelec.fr ([160.228.154.1]:53508) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1Mdq1s-00016h-Vj for grub-devel@gnu.org; Wed, 19 Aug 2009 14:37:01 -0400 Received: from localhost (localhost [127.0.0.1]) by vader.rez-gif.supelec.fr (Postfix) with ESMTP id 9AD572C6A6E for ; Wed, 19 Aug 2009 20:36:59 +0200 (CEST) X-Virus-Scanned: amavisd-new at rez-gif.supelec.fr Received: from vader.rez-gif.supelec.fr ([127.0.0.1]) by localhost (vader.rez-gif.supelec.fr [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LD5rkE+DU9nD for ; Wed, 19 Aug 2009 20:36:55 +0200 (CEST) Received: from [127.0.0.1] (duboucher2.rez-gif.supelec.fr [160.228.159.225]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by vader.rez-gif.supelec.fr (Postfix) with ESMTPS id 43BDC2C6A5C for ; Wed, 19 Aug 2009 20:36:54 +0200 (CEST) Message-ID: <4A8C4645.1040301@duboucher.eu> Date: Wed, 19 Aug 2009 20:36:53 +0200 From: Duboucher Thomas User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: The development of GRUB 2 References: <4A8BDB5B.5000407@labri.fr> <200908191425.29202.michael@gorven.za.net> <200908191524.42432.michael@gorven.za.net> <4A8C1DED.7030501@isaac.cedarswampstudios.org> <4A8C3577.2060104@duboucher.eu> In-Reply-To: X-Enigmail-Version: 0.95.7 OpenPGP: id=A79F86A8 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable 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 18:37:07 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Vladimir 'phcoder' Serbinenko a =E9crit : >> I can imagine a world with computers you can access from free and from >> whom you can boot with your USB pen-drive (or trust the installed OS, = or >> whatever you want). But this world is still far away from here ... :| > TPM doesn't protect your computer from being stolen and HD wiped. Hey, I didn't say that TPM will replace a faithful dog! :D >> No! No! No! and No! Coreboot is not an CRTM, and then you can't speak >> about chain of trust if you are starting it with Coreboot ... It is >> already very difficult to consider the TPM as a CRTM since there are >> design flaws. > Yes! Yes! Yes! Yes! Yes! Yes! Yes! Yes! Yes! Yes! Yes! Yes! Yes! Yes! > Yes! Yes! Yes! Yes! > Coreboot is perfect for my use for *****. > Did I bring any argument in last 2 lines? Since the BIOS can be "easily" replaced, it cannot be trusted, hence you can't build a chain of trust starting from your BIOS. It is a "little" more difficult to replace a TPM, even more if it's holding a shared secret. :) >> Also, you are not owning a computer by using a chain of trust. You are >> only sure that the software you trust on your computer haven't been >> tampered. And you can keep trusting them, even if they have a backdoor >> you weren't aware of! ;) >> > That's what open source is here for. You just said it yourself that > you can easier trust open source than closed source and TPM doesn't > change that. >=20 I completly agree with the first part, but you twisted the ending. :'( I trust an open-source software, because I can see the source code (uh, wait! what if I can't trust the compiler!). I keep trusting it because the TPM tells me it hasn't been altered on my computer by nasty people. >>> - Lock down via proprietary crypto chip (TPM). Different software ca= n >>> happen if "attacker" figured out how to break into your TPM, which is >>> actually quite possibly easier, not harder, than replacing hardware >>> because the TPMs are closed systems that don't disclose their design = and >>> flaws... >> Wow! Software hacked TPM? Software breaking into TPM? I must be missin= g >> something. :| > It's possible that using some kind of obscure power control sequence > you can reset tpm to its boot state and then nicely ask it to do > whatever you want. Well, that would be a design flaw, and not very TCG compliant. Things like this happen, and when it does, it's always a little problematic in cryptographics. >> Every technology has its design and its implementation, and also its >> design flaws and implementation flaws. Remember Debian and OpenSSL. >> Well, if a chip has a design flaw, it is more expensive to change it; >> however, people that will truly require it will also be able to. ;) >> > TPM claims to e.g. protect your hd encryption keys. But what a hacker > would do is to boot computer, wait that it retrieves the keys and then > execute cold boot attack (in most cases it's enough to just cool RAM > down and reboot with a USB key which will dump the memory). I don't > spend my time on implementing a "security" which increases hacking > cost by $15, claims to be unbreakable and can be used for evil > purposes (in which case it's more difficult to crack) Uh, wait! There's something I don't understand there. What's the point in puting the whole secret in the TPM? It's like writing your passphrase on a paper and put it under your keyboard. A clever implementation would be using the ownership capabilities of the TPM so that the secret can be protected by system integrity _and_ password. >>> attestation, flawed, as soon as your RAM becomes unpredictable. Not = in >>> a convenient way, but it should definitely be possible..) Also, none= of >>> the airplane arguments really apply to small, non-life-critical syste= ms. >> Airplane manufacter aren't using ordinary computer ... > So what? > Example stays an interesting one and their computers probably have > some kind of protection. Well, I think there's computer onboard, and I think they may have some security, but personnaly I've never worked in a department that produces planes. This would be only pure speculations. >> This chain of trust is useful for people that have to work with a >> computer and data in an untrusted environnement, and that's how and wh= at >> it was designed for. > Then this design is fundamentaly flawed. You just can't trust hardware > in untrusted environment. This is what the TCPA is trying to solve. Not an easy question, but TPM is a good begining imho (invalid the Stoned attack scheme for example) > Claiming to achieve impossible is an advantage proprietary security > suites have over free ones. >=20 Yup ;) -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkqMRkUACgkQBV7eXqefhqjZXgCgmGik1TszdBP3tJDlWHFkDhuS 4ooAoJA7CmS+TR0Mv7UHuOJi4mBxBhtT =3DQqm3 -----END PGP SIGNATURE-----