On Tue, 2023-04-04 at 16:10 -0500, William Roberts wrote: > 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. That's right. Then you hash what you get back and check it against the name file. > So I would imagine this key would be persistend to avoid needing it > all the time? You could, but the benefit is marginal given how fast the Elliptic Curve calculation can be done. Remember the key is only needed for a quote or a certification, so that's once per boot to certify the NULL seed and possibly a handful of other uses. > 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? No, but then TPM2_CreatePrimary needs the hierarchy authorizations. The standard assumption I tend to make is that they're empty for both the endorsement and owner. Although if there's a use case that actually wants them set for some reason, then I think there might be a case for removing the policy from the EK template, but if not, it's easier just to follow what the TCG says with the addition of the signing permission. > > 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"? Just the name, I think, assuming everyone agrees on the template. If there's going to be a question about which template then we'd need both. James
