Re: TPM support status ?

[Duboucher Thomas <thomas@duboucher.eu>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Vladimir 'phcoder' Serbinenko a écrit :
> Could you please avoid using abbreviations. It's already hard to read
> TPM specs because of their twisted terminology. If EKP is the key
> stored in the TPM then manufacturer can keep a copy of public or
> private key and nobody will notice.

Sorry for the abbreviations. :|
According to the specs, the private endorsement key must not come out of
the TPM. Also, the pair has to be signed by the "manufacturer". If the
manufacturer is not trutworthy, he can squirt the keys and then have a
local copy of the pair. However, it's no use keeping this key since its
only use is to generate AIK (one-time key pairs that are used to
comunicate using HMAC).

>>>> 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.
>> Yep, but why would you allow reseting the EKP? You can reset everything
>> else because you may need to, but it's no use reseting the EKP.
>>
> By using this key you can prove manufacturer that you use the key he
> burned in device it controls which opens the bad doors.

Well, like in any security system, you suppose the system itself is
secure ... which is not always the case, intentionnaly or not.

>>>> It _can't_ be used for other operations iirc.
>>> Checking you use windows?
>> Not the TPM, only a ***** BIOS and a ***** manufacturer (which can base
>> their scheme on TPM). We saw this in the past, but we didn't needed a
>> TPM for that, only human mind. :|
> But TPM is designed to prevent BIOS modifications.

It's not against my words. I was telling that a malicious manufacturer
can use a TPM to build a system where the BIOS is less likely to be
modified. And if on top of this he uses this to protect the operating
system ... These are use cases of TPM that _we_ don't want to see.

> If you have tokens why do you care if attacker has your passphrase.
> And just the keyboard input can contain a lot of valuable data itself.
> Why do you suppose that attacker can stole the laptop but not the token?

I'm not making any supposition, I'm making all of them. And I'm trying
to reduce the different schemes an attacker could use. There is _always_
a way to steal the secret. At least let's make it less likely to happen.

>> Don't you think it isn't even worth working on?
> If not the freedom concerns it could be fun coding. But IF.
Let's hope that those who works on it are concerned, but you'll always
find someone who isn't.


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkqMXPcACgkQBV7eXqefhqhyFACeNEV9eGIX8Dv+Me0h166yRdg4
uDYAoKLBpliNkKionXrBIOqzu+N7e/rG
=eOtB
-----END PGP SIGNATURE-----