Re: TPM support status ?

[Vladimir 'phcoder' Serbinenko]

>
> 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).
You have to secure something physically. What we consider here are
targetted attacks, not script kiddies. To deflect script kiddies
anything is enough. For targetted attack you can't assume attacker
can't mess with any chip
>
>>>>>>>> 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).
>
Thanks for detailing technical details but they don't invalidate my
point. An attacker will just mess with another part. Can't mess with
LPC? Let's mess with PCI. Or RAM. Or CPU. There is a known attack of
filling the memory with jumps to your code and putting CPU into
hazardous environment (like microwave in my kitchen) and waiting till
CPU jumps to your code.
But these measures are enough to make people not consider Free
Software at all. Even now when you can't provide XYZ feature users say
free software is a crap. And making users require to put their CPU in
microwave to read .docs would effectively mean the death of free
software. Additionally TPM possesses technical and non-technical
properties which make it suitable to lock-out. If TPM came blank (no
keys whatsoever) and key was generate by calling a special function
then I would be ok with it. And it will be appropriate for every
legitimate use you mention. But as is we can't and will never support
TPM.
You can argue that GRUB will never implement a lockout (and GPLv3+
explicitly forbids it) but you need to think broadly. If even GNU
silently approves TPM it would be like watching senator Pallpatin
taking powers and applause. If we[1] raise public awareness around TPM
but use it in software it both makes our statements hipocritic and our
software useless in a free world which s our goal.
For these reasons we won't support TPM until it meets one of the
conditions that will make it ok

[1] I feel myself like a part of GNU and allowed myself to speak in
its name but I'm not an official GNU person myself and my opinion
isn't necessarily this of GNU but I hope maintainers agree with what I
say
> * a TPM proves that your medium can be trusted
Trusted by whom? We have the problem that beyond the key there is the
signature but it makes for manufacturer possible tocoerce most of
users to transfer trust to him.
It's like buying a lock without a key. You don't own such
lock.Similarly you don't completely own a general-purpose computer and
it may boil down you owning just the metal and computer being owned by
someone else's even if you bought a computer.
>        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.
DRM producers trust the system even more since for them targetted
attacks by skilled geeks knowing to manipulate soldering iron aren't a
problem


-- 
Regards
Vladimir 'phcoder' Serbinenko

Personal git repository: http://repo.or.cz/w/grub2/phcoder.git