Re: TPM support status ?

[Michael Gorven]

On Wednesday 19 August 2009 13:51:34 Vladimir 'phcoder' Serbinenko wrote:
> 1) Making use of TPM you become dependent on good will of TPM
> manufacturer. You can never know if or when the TPM manufacturer or
> someone connected with them will ask you to use remote attestation to
> prove them that you use only the software they signed and that they
> effectively control your computer.

How are you dependent? If they ask you to use remote attestation then just say 
no -- what would you gain? You're probably not using any of their software 
anyway. They can't stop your system from working.

> 2) The similar features can be implemented without resorting to TPM by
> using coreboot and make every stage verify the signature of every next
> stage.

Trust has to start somewhere, and the more difficult it is to compromise that 
the better.
 
> 3) TPM manufacturers claim to achieve the goals like being
> tamperproof. This is simply not possible. Everything is tamperable.
> It's just the question of effort.

Correct, but making hardware the root of trust is more secure than a flashable 
BIOS or the harddrive contents.

> Even without such equipment it's just a
> question of time before a fatal flow in TPM is discovered and
> published. After that point TPM wouldn't be very different from WEP.

Yes, but we used WEP because it was the best available security at the time. 
And then we moved on to WPA. You can't argue that one shouldn't use something 
because it will surely have flaws because otherwise we wouldn't use anything 
at all.

> > 2) Extend the PCR register (TPM_SHA1CompleteExtend command) with the
> > SHA-1 digest.
>
> Why would we need a chip to check if SHA-1 matches if we can use
> signatures?

Because the BIOS or bootloader can be replaced to remove the check.

> > 3) Read the PCR (TPM_PCRRead command) and compare it to a recorded value
> > of a previous (safe) boot. We assume that the previous link of the chain
> > of trust (BIOS?) has already checked that GRUB hasn't been tampered
> > before starting it.
>
> You propose to check that our checksum in PCR is ok but you already
> assume GRUB wasn't tampered. If you assume grub wasn't tampered no
> need to checksum. If you don't it's useless to checksum.

That isn't assumed -- the BIOS checks that GRUB isn't tampered with before 
moving control to it.

> > A full support of TPM means that GRUB should also be able to ask to a
> > remote authority if the content of the PCR is still ok...
>
> Why do I as user need someone else to check my computer?

Because you don't always own or completely control the computer. 

> If you assume attacker has no physical access to a machine checking
> signatures on updates recieved from network and proper permission
> model is enough to deflect any attack

There will always be flaws in the system ;-)

> > Now, the question whether one shouldn't support a technology because it
> > may lead to evil usage is something that should be solved inside the
> > GRUB team (and I believe that the GRUB team has already solved this
> > question out).
>
> It's not like just "can lead". Remote attestation is a part of TPM
> spec. It's like saying nuclear bombs aren't a problem just because
> "they can explode".

It is, but that doesn't mean it has to be implemented.

I see TPM as a very useful security measure, and support in GRUB can help make 
*nix systems much more secure. As Emmanuel noted, the TPM can always be 
cleared, and even if it's holding harddrive encryption keys you should have a 
backup key anyway. You can only be held hostage to the TPM if you're not 
sensible about the way it's setup.

The only valid argument I see against TPM is the 
supporting-possibly-harmful-technology one. But then we shouldn't use crypto 
at all because it can be used for DRM...

Michael

-- 
http://michael.gorven.za.net
PGP Key ID 1E016BE8
S/MIME Key ID AAF09E0E

signature.asc
Description: This is a digitally signed message part.