Re: TPM support status ?

[Michal Suchanek]

2009/8/20 Duboucher Thomas <address@hidden>:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Seems that my smtp was down :|
>
> Michal Suchanek a écrit :
>> 2009/8/20 Michael Gorven <address@hidden>:
>>> On Thursday 20 August 2009 10:20:02 Michal Suchanek wrote:
>>>> 2009/8/20 Michael Gorven <address@hidden>:
>>>>> On Thursday 20 August 2009 09:59:42 Michal Suchanek wrote:
>>>>>> 2009/8/20 Michael Gorven <address@hidden>:
>>>>>>> On Thursday 20 August 2009 09:49:06 Michal Suchanek wrote:
>>>>>>>> 2009/8/20 Michael Gorven <address@hidden>:
>>>>>>>>> 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).
>

Ok, thanks for clarifying this.

On platforms that integrate a TPM chip properly it should be started
before the BIOS and thus it can check the integrity of the BIOS which
is something coreboot cannot do.

The manufacturers could include any decent crypto solution in the
platform but they included a crippled chip designed for DRM schemes so
that's what we have.

Thanks

Michal