[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 14:42:37 +0200 |
On Wed, Aug 19, 2009 at 2:25 PM, Michael Gorven<address@hidden> wrote:
> 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.
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
>
>> 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.
>> 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.
>
Cut write wire?
>> 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.
But TPM isn't the "best available security" now.
>
>> > 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.
>
And you can mess with PCI to fool TPM.
>> > 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.
>> > 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.
>> > 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.
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).
>
> 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".
>
> 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
- TPM support status ?, Emmanuel Fleury, 2009/08/19
- Re: TPM support status ?, Vladimir 'phcoder' Serbinenko, 2009/08/19
- Re: TPM support status ?, Robert Millan, 2009/08/19
- Re: TPM support status ?, Michael Gorven, 2009/08/19
- Re: TPM support status ?, Vladimir 'phcoder' Serbinenko, 2009/08/19
- Re: TPM support status ?, Robert Millan, 2009/08/20
- Re: TPM support status ?, Robert Millan, 2009/08/19
- Re: TPM support status ?, Isaac Dupree, 2009/08/19