Re: TPM support status ?

[Michael Gorven]

On Wed, Aug 19, 2009 at 03:48:18PM +0200, Vladimir 'phcoder' Serbinenko wrote:
> On Wed, Aug 19, 2009 at 3:24 PM, Michael Gorven<address@hidden> wrote:
> > 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.
> If it becomes widespread you will need to crack TPM to use mplayer to
> watch videos.

Yes, this is a possibility.

> > > >> 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?)
> You need root access or possibility to remove the chip. Which can be
> made arbitrarily hard

My use case involves physical access.

> > > Coreboot can make this too. And firmware doesn't need TPM to do such
> > > checks.
> >
> > Yes, except coreboot isn't widely supported.
> It's not a reason to obey BIOS manufacturers.

You're not obeying them.

> > > >> > 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,
> If you don't trust a location, change it. They have physical access
> and can execute a wide range of attacks.

So you're saying that you can't solve my use case, right? TPM provides 
significantly more security against a physical attack.

> > 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.
> If there is no interractive authentication key is stolen together with
> laptop. If you have data worth more than a laptop itself you can't
> assume your attacker to be short on resources. If you don't most
> thieves will just wipe the harddrive.

Yes, but the key can only be used if the system is booted with the 
current trusted parts which would then enforce proper access control.

> > > 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.
> You can't seriously assume an attacker with intentions not having
> enough money to buy a system using same RAM format and few bottles of
> liquid nitrogen and download linux designed for cold boot attack.
> As you can see for an attacker with intentions TPM isn't of any
> problem. Supporting it would mean waste time and risk freedom of all
> GNU users just for the few to feel more secure ("feel" and not "be").

All security is a trade off. Yes, TPM doesn't make it impossible, it 
just makes it a heck of a lot harder and raises the bar significantly.

> > > 3) "How much does the security costs?" (in money, ressources and
> > > inconvinience)
> >
> > The cost of a TPM chip and some setup time.
> And the freedom.

If you don't want to use it then don't. I'd like the freedom to make my 
system more secure.

> > > 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.
> using GPT instead of pc-style would also increase security with this
> idea since you need an OS supporting it.

That doesn't provide any security whatsoever.

> > > > 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.
> Why is remote attestation an important part of specification then? Why
> don't they want to give you the key burned in TPM on a piece of paper?
> Why do options to reset TPM are "optional"?

Okay, fair enough, there are parts of TPM which can and are possibly 
intended to screw over the user. That doesn't make the whole thing 
worthless however.

--
http://michael.gorven.za.net/
PGP Key ID 6612FE85
S/MIME Key ID AAF09E0E

signature.asc
Description: Digital signature