[Top][All Lists]

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

Re: TPM support status ?

From: Michal Suchanek
Subject: Re: TPM support status ?
Date: Wed, 19 Aug 2009 21:21:28 +0200

2009/8/19 Vladimir 'phcoder' Serbinenko <address@hidden>:
> On Wed, Aug 19, 2009 at 8:13 PM, Duboucher Thomas<address@hidden> wrote:
>> Hash: SHA1
>> Vladimir 'phcoder' Serbinenko a écrit :
>>>>> 2) Ethical Aspects
>>>>> ==================
>>>> Every technology has its evil uses, so does TPM. However, there's a very
>>>> large gap between currently implemented solutions and what you suggest.
>>> How can you know this? I met persons who say that it's very difficult
>>> to mount a PKI infrastructure to make remote attestation.  would have
>>> agreed if remote attestation would be a corner case of something and
>>> if there was no coordination between TPMs. But none of this holds
>>> true. Additionally some manufacturers even say explicitly that the key
>>> is "approved" and if you reset your TPM your key will be "unaproved"
>>> which implies that some kind of such infrastructure exists.
>> What key are you talking? The Endorsment Key Pair? Those are bound to
>> the TPM (and so the platform). They may only be used for AIK generation
>> and ownership. The result is that you can trust the medium you use to
>> exchange private data with the tpm after taking control of it (using
>> HMACs). Of course, if you reset the EKP, then the TPM is marked as
>> unsecure (would you trust a website if its certificate has changed? oO).
> But why does a third instance (manufacturer) need to trust my key?
> Only one: he wants a control.
>> Also, most of the time, the reset operation is disabled by the TPME.
> This is a problem (again): you can't make TPM to behave like you want.
>> It _can't_ be used for other operations iirc.
> Checking you use windows?
>>>> Of course, someone may use TPM in a software suite that completly lock
>>>> down your computer. However, I don't think that it's the TPM's fault;
>>>> its just a technology.
>>> Handcuffs are just a technology too but you probably wouldn't disagree
>>> if I say that they are the opposite of freedom.
>> Hmmm, handcuffs :)
>> I don't think we are in a good direction, since you use different
>> schemes to protect material and immaterial property. I don't disagree
>> the fact that they are the opposite of freedom, but I won't personnaly
>> count this as an argument.
> The argument was "TPM aren't opposite of freedom".
>>>> The goal of TPM is to be used in broader security schemes. Its use is
>>>> only to make sure that the integrity of the system was preserved. This
>>>> would prevent an attacker from inserting a stealth PCI device which can
>>>> leaks data using SMM.
>>> Please ellaborate. Who is the attacker? What is he after in someone
>>> else's computer? Obviously he isn't after hardware components. If he's
>>> after the data then the owner of data should encrypt is with a decent
>>> password.
>> The attacker is someone that wants to steal a secret from you (and not
>> the computer, the TPM is useless in this case). Imagine you have an
>> unbreakable password (that requires a lot of imagination). The attacker
>> will simply modify for example your bootloader with something like
>> Stoned. However, if you use a shared secret and the TPM is part of share
>> process (that means the integrity of your computer is part of the key
>> retrieval process), then this attack will simply fail.
> Why wouldn't he connect a hardware keylogger (price about $100,
> reusable) or change keyboard firmware. Neither is detectable by TPM.
>> I was talking about trust. Who and what can you trust? A closed-source
>> software?
> No
>> A black box? Your local cyber-café?
> No
>> Do you trust a TPM in being a part of a chain of trust?
> No
>> I completly agree with the fact that we must be vigilant. TPM is another
>> brick that can be used in any cryptographic applications (like CSS).
>> However, I truly think that simply disregarding it is a mistake: It is
>> an incredible tool in hardened software.
> I don't believe it to be wonderful in anything except giving
> impression of security. Increase of $100 is a gain but if your data is
> worth less than that your laptop will be stolen for hardware and not
> data.
> If this measure didn't come with the risk of losing freedom I would be
> for its inclusion but with warnings in manual that it provides no real
> security (I wouldn't have spend time coding it though, neither would I
> have used it). But considering the price (freedom) I reject it.
> You lose the freedom the moment when you go in prison cell and someone
> is able to close it regardless whether he actualy closes it or not -
> he has you at his mercy.

These TPM discussions are .. interesting.

I have a challenge for people who want TPM support:

Tell me one technical benefit of TPM over coreboot.

The disadvantage is obvious: TPM was designed for DRM schemes. However
hard these might be to implement in practice it's what they had in
mind when designing the TPM chips. When you reset the internal key of
the TPM you can still trust the chip because you can verify that next
time is still the same - nobody has reset it again. But the media and
other IP vendors using DRM schemes would only trust the manufacturer's
key. If it was not designed for DRM the device would come blank and
you would generate a key when you first use the device. This is how
many USB/SmartCard/1wire/.. devices work with the additional benefit
that you can easily remove them from the system when it is not in use
for additional protection.

So coreboot+removable crypto device >> TPM in my book.

Remember that it's the CPU what runs your system, not the TPM so you
still rely on BIOS to do the right thing while initializing the TPM.



reply via email to

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