Re: TPM support status ?

[Vladimir 'phcoder' Serbinenko]

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.
>> >> 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
>> 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.
>
>> >> > 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.
> 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.
>
>> 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").
>> 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.
>> 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.

>> > 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"?
>
> Michael
>
> --
> http://michael.gorven.za.net
> PGP Key ID 1E016BE8
> S/MIME Key ID AAF09E0E
>
> _______________________________________________
> Grub-devel mailing list
> address@hidden
> http://lists.gnu.org/mailman/listinfo/grub-devel
>
>



-- 
Regards
Vladimir 'phcoder' Serbinenko

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