On Tue, Apr 4, 2023 at 3:19 PM James Bottomley <James.Bottomley@xxxxxxxxxxxxxxxxxxxxx> wrote: > > 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@xxxxxxxxxxxxxxxxxxxxx> 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; Hmm, I think we miscommunicated here. At some point you need to call TPM2_CreatePrimary with the "Signing EK" template which would require Endorsement Hierarchy (EH) Auth. So I would imagine this key would be persistend to avoid needing it all the time? Then the use of TPM2_Certify using the "EK Signing" key would also need EH Auth since AuthPolicy is coupled to EH Auth via PolicySecret. I'm just thinking every time these commands are invoked, especially if this is used during boot, where EH Auth would be coming from or am I missing something? > 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. > I'm assuming this would be the template or name of the "Signing EK"? In systemd we just shove the name (Actually a serialized ESYS_TR) of the SRK into the LUKS data and ESAPI handles the check in session establishment. > > 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 >
