-----BEGIN PGP SIGNED MESSAGE----- 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. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkqMQMsACgkQBV7eXqefhqhFHQCguZ02qptk9RdsdJVMJvckM+ms c2QAoK23ZiWYYKRdiPDbSY3ROYzHSEdD =WISW -----END PGP SIGNATURE----- _______________________________________________ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
