-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Michal Suchanek a écrit : > 2009/8/20 Michael Gorven <mich...@gorven.za.net>: >> On Thursday 20 August 2009 10:20:02 Michal Suchanek wrote: >>> 2009/8/20 Michael Gorven <mich...@gorven.za.net>: >>>> On Thursday 20 August 2009 09:59:42 Michal Suchanek wrote: >>>>> 2009/8/20 Michael Gorven <mich...@gorven.za.net>: >>>>>> On Thursday 20 August 2009 09:49:06 Michal Suchanek wrote: >>>>>>> 2009/8/20 Michael Gorven <mich...@gorven.za.net>: >>>>>>>> On Wednesday 19 August 2009 21:21:28 Michal Suchanek wrote: >>>>>>>>> Tell me one technical benefit of TPM over coreboot. >>>>>>>> Coreboot doesn't provide protected storage of secrets (e.g. >>>>>>>> harddrive decryption keys).
It could emulate what a TPM does, however since it starts its job later in the boot process, it is far, far less secure (I personnaly would consider it useless in this case). >>>>>>> TPM does not either at the time the BIOS is loaded. Remember, it's >>>>>>> the CPU what's running the BIOS, not the TPM chip. Just to make some precisions about TPM and its uses (or at least, as far as I understood how they works). The TPM chip is soldered on the LPC bus, that is, the same bus where the SuperIO (keyboard controller) and the BIOS ROM are located, under the SouthBridge. During a BootUp phase (G2 -> G0), the Core Root of Trusted Measurement, also located on the LPC bus, wake up and initialize the TPM. It measures itself (firmware, configuration, ...), then it measures the BIOS ROM. When these operations are completed, the BIOS is then executed by the processor and the system boots up. Other elements being measured later are the CPU/NB/SB/SuperIO microcode/configuration and the BIOS configuration. I don't have a lot more details on these stages since I haven't acess to the whole specifications, nor I am a PC guru. You can check this if you have a TPM enabled computer by dumping the content of /sys/kernel/security/tpmX/ on your securityfs. These steps contribute in creating what is called a "trusted platform" composed of "trusted elements" within "trust boundary" (yep, that's a lot of trust). This means that when the first IPL is loaded, you can check wether the system has been tampered or not, the TPM state being the "image" of the system (or as close as it can be). Because trust is transitive, you end up with a complete system that you can "trust", because the TPM can be considered as being a "trusted third party". The easiest known attack on TPM is intercepting data on the LPC bus. Because it can't be trusted (the bus), you could put some controller (like FPGAs) between the TPM and the bus (with some dirty work). Then using an altered boot loader (i.e. Stoned), making the system boot normaly, except that you would intercept the measure of the malicious boot loader and replace it by the measure of the old boot loader. You can keep the original series of measure to make the TPM believe the system hasn't been tampered and you'll end up discovering the shared secret the TPM was holding without the user being able to notice the system integrity was compromised. Well, that require a lot of dirty work and wires, but it works. ;) However, later chips, like Intel's iTPM tries to integrate the BIOS ROM and the TPM within the SouthBridge, removing the LPC bus, the untrusted part. Also, TPM are watching closely the LPC bus (such as trying to detect clock variations). >>>>>>> Only after BIOS enables TPM or coreboot enables any crypto device you >>>>>>> choose you get any secrets or keys. >>>>>> So? It's still protected storage. You can read a BIOS chip, but you >>>>>> can't just read the contents of a TPM chip. >>>>> You can use decent crypto storage rather than half-broken TPM. There >>>>> is no advantage to using it. >>>> Like what? >>> There is hardware for secure key storage which you can put into some >>> card slot or USB and unlike TPM you can also remove it and store >>> separately from the computer which greatly decreases the chance that >>> your data would be compromised if your computer is stolen. >> But that doesn't protect the machine (and crypto card) from being physically >> compromised, so it's not the same as TPM. People are mixing everything together :) Apart from its SmartCard capabilities, the basic use of a TPM is proving your system wasn't altered since when you set up the TPM. To make things simple: * a passphrase proves that you _know_ part of the shared secret * a token proves that you _own_ part of the shared secret * a TPM proves that your medium can be trusted Using this, you can use security scheme that do require the medium to be trusted, or at least doesn't require very complex operations to work on untrusted systems. Also, TPM can do the same operations that a SmartCard can; the only difference being that one object is a small SmartCard, and the other is a computer (or any device, laptop, cellphone, PPA, ...). > How does TPM protest your machine from physical access? I thought it's > a small chip somewhere on the board, not a steel case around the > machine. You are right, it's a small chip somewhere on the board. And to give you an answer, it doesn't protect your machine from physical access. The only thing it does is proving that you can "trust" your system (because when you initialized your TPM, your system may already be untrustworthy). And then it can hold _shared_ secrets that you may use (for disk encryption for instance). The result is that if your system was altered in any way, the shared secret remains hidden. > Thanks > > Michal > > > _______________________________________________ > Grub-devel mailing list > Grub-devel@gnu.org > http://lists.gnu.org/mailman/listinfo/grub-devel > -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkqNekcACgkQBV7eXqefhqg6qwCfYkxNXpgVzmin9xM/gFVfpkZn HFAAn1s81V6XKhCbwOqa21V6jXgJHIf7 =Cnnd -----END PGP SIGNATURE----- _______________________________________________ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel