Re: TPM support status ?

[Michael Gorven <michael@gorven.za.net>]

[-- Attachment #1: Type: text/plain, Size: 4084 bytes --]

On Wednesday 19 August 2009 14:42:37 Vladimir 'phcoder' Serbinenko wrote:
> Even if they can't stop from working at all they can make it
> effectively useless by e.g. not allowing you to see online videos, buy
> online or even just send an e-mail (saying it's "spam control") if you
> aren't TPM-checked

That falls under the supporting-possibly-harmful-technology argument. It's not 
very different from saying "you must use Silverlight to view videos" and 
whatnot. If you don't want to follow their requirements, then don't.

> >> 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.
>
> flash rom with cut write wire is impossible to compromise without
> physical access.

Valid solution, but does it protect the contents of the flash ROM? (i.e. can 
you read the contents?) A minor point is that it does mean you can't upgrade 
your BIOS anymore. It also gets tricky if you're wanting to securely store a 
hardrive decryption key though.

> >> > 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.
>
> Coreboot can make this too. And firmware doesn't need TPM to do such
> checks.

Yes, except coreboot isn't widely supported.

> >> > 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.
>
> Then someone is already holding you hostage. We won't help them to
> restrict your freedom further.

Or you're the person who owns and wants to secure the computer. Maybe you want 
to co-locate your server and make sure the technicians at the DC can't 
compromise it, or you're guarding against data loss if your laptop gets 
stolen without having to enter decryption passwords on boot, or a whole lot 
of other situation where *you* are putting *your* computer in an untrusted 
environment.

> How? Respond to questions I asked (the 4 crypto questions). During
> your whole discussion you assumed that attacker already has root
> access and argued how to prevent him from changing the kernel. But
> what's the use if he already has root access (or in other words
> already has the security on the knees and can do whatever he wants).

> 1) "Which attacks is it supposed to deflect?"

My main use case is unattended booting with an encrypted harddrive, and 
protecting against physical access or theft.

> 2) "Does it deflect those attacks?"

It seriously raises the bar to such attacks, since the attacker would need to 
pry the decryption key out of the hardware.

> 3) "How much does the security costs?" (in money, ressources and
> inconvinience)

The cost of a TPM chip and some setup time.

> 4) "Which other holes does it open?" 

Obviously the TPM could have flaws which cause it to divulge the decryption 
key. I don't see it lessening the security of the system though.

> > 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...
>
> It's not just "possibly harmful", it's "designed with harm in the mind".

Disagree.

Michael

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

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 827 bytes --]