On Mon, 2011-06-27 at 15:12 +0200, Miloslav Trmač wrote:
> On Mon, Jun 27, 2011 at 12:11 PM, Andrew Haley <aph(a)redhat.com>
> wrote:
> > On 24/06/11 20:49, Miloslav Trmač wrote:
> >> On Fri, Jun 24, 2011 at 12:49 PM, Andrew Haley <aph(a)redhat.com>
> >> 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
but is that it? How would anyone know?
--
Bernd Stramm
bernd.stramm(a)gmail.com