From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with archive (Exim 4.43) id 1LaJIb-0004zr-6x for mharc-grub-devel@gnu.org; Thu, 19 Feb 2009 19:31:25 -0500 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1LaJIZ-0004yK-5G for grub-devel@gnu.org; Thu, 19 Feb 2009 19:31:23 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1LaJIX-0004x5-DD for grub-devel@gnu.org; Thu, 19 Feb 2009 19:31:22 -0500 Received: from [199.232.76.173] (port=35365 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1LaJIW-0004wj-Tz for grub-devel@gnu.org; Thu, 19 Feb 2009 19:31:21 -0500 Received: from xsmtp0.ethz.ch ([82.130.70.14]:3970) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1LaJIW-0001zZ-8H for grub-devel@gnu.org; Thu, 19 Feb 2009 19:31:20 -0500 Received: from xfe1.d.ethz.ch ([82.130.124.41]) by XSMTP0.ethz.ch with Microsoft SMTPSVC(6.0.3790.3959); Fri, 20 Feb 2009 01:31:16 +0100 Received: from [192.168.2.77] ([81.221.97.38]) by xfe1.d.ethz.ch over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Fri, 20 Feb 2009 01:31:16 +0100 Message-ID: <499DF97E.1080800@student.ethz.ch> Date: Fri, 20 Feb 2009 01:29:50 +0100 From: Jan Alsenz User-Agent: Thunderbird 2.0.0.19 (X11/20090104) MIME-Version: 1.0 To: Grub-devel References: <499DB343.9020301@gmail.com> In-Reply-To: X-Enigmail-Version: 0.95.7 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig78D9E2976B795BC59EAF933A" X-OriginalArrivalTime: 20 Feb 2009 00:31:16.0420 (UTC) FILETIME=[8ABDB840:01C992F2] X-detected-operating-system: by monty-python.gnu.org: Windows 2000 SP4, XP SP1+ Cc: Alex Besogonov 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: Fri, 20 Feb 2009 00:31:23 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig78D9E2976B795BC59EAF933A Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi! Alright, lets try to make sure everyone is talking about the same things = here. First of all a TPM is not just some kind of secure memory only accessible= from early BIOS, it basically is a small computer. You can only send it comman= ds, and it can "decide" to reject them, e.g. if you try to read out the endorseme= nt private key. (Of course there is always the chance that the TPM has hidden commands to= do that, or the manufacturer already has the keys anyway) Next, we need to keep in mind, what kind of attack and attacker we're try= ing to defend against. As I see it we have an attacker with relatively low-tech abilities (he ca= nnot replace chips, break the TPM physically, or knows it's "dark secrets"), w= ho gets physical access to the machine. So he is basically limited to flashing th= e BIOS, replacing anything, that is written on a disk, controling the network, e= tc. I excluded a higher grade attacker, because, if we have one of these, the= re is nothing we can do. Any solution, TPM or not, can be broken under these as= sumptions. Now for, what the TPM can do and is SUPPOSED to do according to the speci= fication. First there is nothing it can do actively, like interrupt or change anyth= ing in the system. It is pretty passive and only acts on request. The TPM has a number of PCRs (Platform Configuration Registers), where it= can store and concatenate hash values - this is what every stage of a trusted= boot chain has to do. Every stage has to get a hash of the next one, before it executes it. (Th= e assumption here is, that the PCRs cannot be tampered with and the stages = to it correctly) So in the end (after boot) you have a bunch of PCR values, that represent= all the code and data, that was used to boot the system. If you have this and= are sure, that the current configuration is correct, you have a reference val= ue of the expected system state, which you can use for the following: - seal a key: You can create a key with the TPM and "bind" it to specific values of th= e PCRs, so it only en/decrypts with it, if these values match. You can encrypt any kind of data with this, but the only useful thing fo= r boot is to encrypt a cryptographic key needed to further start the system. - remote attestation: The TPM can proof to another party, that the PCRs have certain values (o= f course the communication needs to be established by normal software runni= ng on the machine) The TPM has a few more functions, but I think they are not relevant here.= And now for the ongoing discussion: (things I didn't comment on should have been answered above) Alex Besogonov wrote: > On Thu, Feb 19, 2009 at 9:30 PM, phcoder wrote: >>> Yes, but that's way too hard. >> Sure? There was a demonstration when rsa key was recovered just by plo= tting >> variations on powerline of usb port > TPM performs encoding/decoding, and I consider it secure. >=20 > I don't think it's possible to recover the symmetric key used later > during normal system operation. It could possibly be done, but that is out of scope here. Regardless of what you use to establish your trust, if someone can extrac= t the key for your disk encryption from the running system your screwed. >> And what about cache attack? > You mean frozen memory chip attack? No, cache timing. (search for "aes cache timing") >>> That's possible, but again I consider this not critical. BIOS itself >>> is checksummed and checked by the root of trust. >> Isn't bios (or part of it) the root of "trust" > As far as I understand - no. Actually - it is. Check the "TCG PC Client Specific Implementation Specification for Conven= tional Bios" or "TCG PC Specific Implementation Specification" at https://www.trustedcomputinggroup.org/specs/PCClient/ and look for CRTM (Core Root of Trust for Measurement) >>> Why? >> Because I don't want support this technology. TPM=3Dobfuscation=3Dunse= curity. > No. TPM is just a secure way to store keys, nothing more. It can be > used for good and bad. Well, it is a bit more, but it's definitely not just obfuscation. Actuall= y it's pretty well documented what it's supposed to do (all the specification is= available, there is an open-source emulation implementation of it). What you are referring to, is that you don't trust it to have ONLY this functionality, but you can make the same argument for every part of your = PC! Are you sure, there is nothing in your network card, CPU or hard drive, that = can be used against you? >> And as an opensource and open security fan I can't claim to have solve= d an >> impossible problem. But if you want to use obfuscation schemes it's yo= ur >> right > I want a reasonably secure scheme that DOESN'T use obfuscation. >=20 >> You assume that noone will develop hypervisor able to fool tpm bios. O= ne >> could powercut the tpm chip (similar to how a resistor is remove to av= oid >> burning efuses in xbox) then power would be reestablished to it and bi= os >> would be executed on hypervisor which will retrieve the keys. > Would not work. Or rather it'll require uber-precise timing, a lot of > soldering and access to private data of the mainboard developer. >=20 >> Actually you >> can trust tpm only as much as you trust in obfuscation power of bios. = Only >> obfuscation prevents attacker from disconnecting tpm and reading keys = from >> it. And there are only few types of tpm. Sooner or later someone will = figure >> their interface. Then it can be read by special usb adapter > TPMs are fairly well engineered, it requires several magnitudes more > time to crack it than any pure software security system. >=20 >>> Actually, I can probably even formally prove this assumption. >> I really don't see you point. With my proposition mbr still can be ver= ified >> by tpm but grub2 needs to know nothing about tpm as long as it ensures= it >> doesn't load any unsigned modules. > First, I don't think it's possible to implement SHA-1 hashing in MBR - > there's probably just not enough space left in 512-byte code segment > for that. I am very sure of that. > Second, the only safe action non TPM-aware MBR can perform if it > detects tampering is just shutting down hard. Everything else is > dangerous. Yeah, but an attacker could patch that out too. > Third, it would be nice to be able to measure (attest integrity) of > other files, but that's just nice and not really necessary. >=20 >> This approach is more versatile. It can >> be used also for e.g. checking that debian install is really from debi= an. >> And having experience with manufacturers supplying buggy hw and sw te= nd to >> avoid solutions directly relying on hardware when another implementati= on is >> possible > TPM will be used in the most minimalistic way possible. I'll even add > pure software signature checking support (which can be useful for > another purposes like checking that kernel is not damaged, etc.). >=20 >> Which collaboration other than not loading anything unchecked does you= r >> scheme need from grub? > Mainly, communicating with TPM in MBR to tell it that the next stage > has passed checks. >=20 >> From readme of trustedgrub the only thing it does is checking integrit= y > Yes. >=20 >>> PS: please, can you CC me when you answer my posts? >> Could you come to irc channel or meet me at jabber/gtalk? > Feel free to contact me on Alex.Besogonov _atttttttt___ gmail.com in Ja= bber. Greets, Jan --------------enig78D9E2976B795BC59EAF933A Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkmd+YQACgkQfZylhtn4XvfQvgCbBwv6i6mll5PhcJzKr7YM0UVC 9mYAoN3DbbUCLHNS/q45VcL6jz5h8OPV =CP8/ -----END PGP SIGNATURE----- --------------enig78D9E2976B795BC59EAF933A--