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 15:18:45 -0400	[thread overview]
Message-ID: <414fd2f5e49f9772dd1de4bd281a63e27e60e934.camel@HansenPartnership.com> (raw)
In-Reply-To: <CAFftDdpTWjtNEf=E5V0X1c5ZrG=LQKo1WH6n0Ok2DE7jsh6yqg@mail.gmail.com>

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.

James