[Top][All Lists]

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

Re: TPM support status ?

From: Duboucher Thomas
Subject: Re: TPM support status ?
Date: Wed, 19 Aug 2009 20:13:31 +0200
User-agent: Thunderbird (Windows/20090605)

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).
Also, most of the time, the reset operation is disabled by the TPME.
It _can't_ be used for other operations iirc.

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

>> I would rather consider it's the fault of
>> countries with laws that tolerates these behaviours ...
> Money makes goverments blind.
true :/
>> 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.
Remember that you see a lot of TPM on laptops.
>> As an ending note, I am much more less confident in Intel's processor
>> microcode that is patented than in a chip I can deactivate and live
>> without it.
> Intel microcode is an issue too but it's not hte one which is
> discussed right now
I was talking about trust. Who and what can you trust? A closed-source
software? A black box? Your local cyber-café?
Do you trust a TPM in being a part of a chain of trust?

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. But I also agree with the fact
that it shouldn't be the goal of the Grub project.
Version: GnuPG v1.4.9 (MingW32)
Comment: Using GnuPG with Mozilla -


reply via email to

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