lkml.org 
[lkml]   [2005]   [May]   [23]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH 2 of 4] ima: related Makefile compile order change and Readme

Valdis.Kletnieks@vt.edu wrote on 05/23/2005 12:52:13 AM:

> On Mon, 23 May 2005 00:30:15 EDT, James Morris said:
>
> > Perhaps I don't understand things fully, but what is the purpose of
> > providing measurement values locally via proc?
> >
> > How can they be trusted without the TPM signing an externally generated
> > nonce?
>
> If you can't trust what the kernel is outputting in /proc, you're screwed.

No, this is not the case. You can establish trust into the measurements
read through /proc by validating the TPM signature over the measurement
aggregate on a separate, trusted system. IMA measurements are not intended
to be used on the local system but on a separate system that is trusted not
to be compromised. The system validating the measurements does not trust
the origin; the TPM signature is the part that (i) verifies
the integrity of the measurement list, and (ii) verifies the platform
where the signature was created and links the validated measurement list
to this system.

You can think of IMA as a reliable, Hardware-root-of-trust (TPM)
based logging mechanism for loaded executables. IMA is a usage-example of
the TPM HW root-of-trust used to gain confidence into what was loaded into
another system. Since IMA is released opensource (GPL), people can experiment
with services putting value to the IMA load-time guarantees. We did experiment
with IMA, and we found it interesting enough to make it available.

> And for that matter, how would you verify that it's the TPM that signed the
> externally generated nonce? (Remember - if you can't trust /proc, then you
> have to assume that *any* attempt at talking to the TPM from userspace *is*
> a MITM attack - and you don't have access to any out-of-band info. If the
> now-untrusted kernel did a MITM on your nonce and signed it with a fake key,
> then it can *also* MITM your attempt to read the "correct" key from /etc/tpm.key
> or wherever it is....

Your concern would be relevant if measurements were validated on
the (measured) system that creates them, which is not the intended use.

Verification is based on the public TPM signature key: The remote party
has a certificate of the public key of the system from which it retrieves
measurements. If the public key does not 'validate' the TPM signature
(delivered with a measurement list) then the retrieved measurement list
is not trusted. All signature keys used by the TPM are protected when stored
outside the TPM chip. A system cannot use TPM signature keys outside the TPM
and cannot create valid signatures over manipulated measurement lists.

Man-in-the-middle-attacks on the measurement-list-retrieval are only successful
if the entity controlling the measured system can guess the 160bit random
number (nonce) that will be used in the future by a remote party
or if a remote party re-uses nonces. In this case, old measurement lists can be
replayed; this is very unlikely if the nonces / random numbers are chosen as
directed in the TPM specs.

Thanks
Reiner

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-05-23 22:00    [W:0.073 / U:0.232 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site