[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: TPM support status ?

From: Vladimir 'phcoder' Serbinenko
Subject: Re: TPM support status ?
Date: Wed, 19 Aug 2009 22:13:51 +0200

>>>> 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.
>> 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.
For me additional $15 (actually even less, perhaps $5) on attack
aren't "significant increase in security"
>>> 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.
Watch this:
> 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.
Again cold boot attack is easy to execute.
>> 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.
If DRM-TPM is implemented they can e.g. say "your freedom: use TPM or
don't use .doc format" then it may practically boil down to "use TPM
or have no possibility to find any job" or "use TPM or your computer
is useless". If you apply this logic a choice "obey or die" is
>> 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.
Neither does TPM
>> 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.
It makes it dangerous, too dangerous.

Vladimir 'phcoder' Serbinenko

Personal git repository:

reply via email to

[Prev in Thread] Current Thread [Next in Thread]