Re: [PATCH v4 00/13] add integrity and security to TPM2 transactions

From: James Bottomley <James.Bottomley@HansenPartnership.com>
To: William Roberts <bill.c.roberts@gmail.com>
Cc: linux-integrity@vger.kernel.org,
	Jarkko Sakkinen <jarkko@kernel.org>,
	keyrings@vger.kernel.org, Ard Biesheuvel <ardb@kernel.org>
Subject: Re: [PATCH v4 00/13] add integrity and security to TPM2 transactions
Date: Tue, 04 Apr 2023 16:19:40 -0400	[thread overview]
Message-ID: <c025ff772580552ced343d88c608b41cd3e11889.camel@HansenPartnership.com> (raw)
In-Reply-To: <CAFftDdqeaRWvfvZfGwdXYaFcGBNirDV75JsuRR88FSdCrYmKpg@mail.gmail.com>

On Tue, 2023-04-04 at 14:42 -0500, William Roberts wrote:
> On Tue, Apr 4, 2023 at 2:18 PM James Bottomley
> <James.Bottomley@hansenpartnership.com> wrote:
> > 
> > On Tue, 2023-04-04 at 13:43 -0500, William Roberts wrote:
> > [...]
> > > > The final part of the puzzle is that the machine owner must
> > > > have a fixed idea of the EK of their TPM and should have
> > > > certified this with the TPM manufacturer.  On every boot, the
> > > > certified EK public key should be used to do a make
> > > > credential/activate credential attestation key insertion and
> > > > then the null key certified with the attestation key.  We can
> > > > follow a trust on first use model where an OS installation will
> > > > extract and verify a public EK and save it to a read only file.
> > > 
> > > Ahh I was wondering how you were going to bootstrap trust using
> > > the NULL hierarchy.
> > 
> > Well, actually, I changed my mind on the details of this one: the
> > make credential/activate credential round trip is a huge faff given
> > that there's no privacy issue.  I think what we should do is simply
> > store the name of a known signing EK on first install (using the
> > standard P-256 derivation of the EK template but with
> > TPMA_OBJECT_SIGN additionally set).  Then you can use the signing
> > EK to certify the NULL key directly and merely check the signing EK
> > name against the stored value to prove everything is correct.
> > 
> 
> Yeah that model is much simpler. My guess is that on install it would
> persist this "Signing EK" to a specific address that is different
> from the typical EK Address?

Actually, since this is used to prove trust in the TPM, we can't have
the TPM store it; it's going to have to be somewhere in the root
filesystem, like /etc.  Ideally it would be in the immutable part of
/etc so it is write once on install.

> Any particular reason for using the Endorsement Hierarchy outside of
> the lifespan of the seed only changing on revocation of the
> Manufacturers Cert? Ie why not Owner Hierarchy?

That's it really: it's the longest lived key of all those the TPM has.
If I'm deriving it once on install and keeping it immutable until
reinstall, I don't want tpm_clear upsetting the apple cart.

James