On Mon, 27 Jun 2011 10:08:44 -0400 Simo Sorce <simo@xxxxxxxxxx> wrote: > On Mon, 2011-06-27 at 15:12 +0200, Miloslav Trmač wrote: > > On Mon, Jun 27, 2011 at 12:11 PM, Andrew Haley <aph@xxxxxxxxxx> > > wrote: > > > On 24/06/11 20:49, Miloslav Trmač wrote: > > >> On Fri, Jun 24, 2011 at 12:49 PM, Andrew Haley <aph@xxxxxxxxxx> > > >> wrote: > > >>> What I don't understand is why this feature requires a binary > > >>> blob. Surely whatever northbridge code is required can be free > > >>> software, Is this just security through obscurity? > > >> > > >> The purpose of the blob is to "measure" the system state; only > > >> the blob (and hardware reset) is allowed to restart the > > >> "measuring" process in the TPM. For this to work securely, the > > >> blob must be signed by someone that the TPM itself trusts - > > >> otherwise an attacker could replace the blob by something that > > >> lies about the system state. > > <snip> > > > What we're saying, then, is that the TPM doesn't trust the owner > > > of the computer, but its manufacturer. It's impossible for a > > > user to decide who they trust. > > > > First, the TPM (nor the CPU) really can't tell the difference > > between the owner of the computer and an author of a virus. It's > > all just software. > > > > Second, every owner of a computer has to completely trust the > > manufacturer of the computer anyway - there are way too many ways > > the manufacturer can break the security of the system, e.g. > > backdoors in the CPU or motherboard, or hidden configurations of > > https://secure.wikimedia.org/wikipedia/en/wiki/Intel_AMT . > > > > Placing trust in the manufacturer of the hardware puts the user in > > no worse position than they were before. And the user, of course, > > still has full control over whether to use the TPM or not, and what > > to use it for. > > Trusting the manufacturer to not put bugs/backdoors is one thing. > Having to depend on the manufacturer to sign your boot sequence is > entirely different, doesn't scale and is generally not welcome. > > If the manufacturer allows you to put in the TPM your own set of keys > then it's different as the user now has the power to do his own > kernels and sign them with his own key and have it verify by the TPM. > > If the user trusts Fedora to do that he'd store a Fedora public key in > the TPM, if he doesn't he'll just not use TPM or re-sign kernels on > update on his own with his personal key. On the subject of trust, may I repeat that this is at present entirely undocumented. The feature page contains nothing whatsoever saying what this is, except for a link to a sourceforge project. The sourceforge project in turn contains nothing saying what the software does. Nothing. I have found something that looks related here http://www.intel.com/technology/security/downloads/315168.htm but is that it? How would anyone know? -- Bernd Stramm bernd.stramm@xxxxxxxxx -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
