On Tue, Apr 4, 2023 at 4:33 PM James Bottomley <James.Bottomley@xxxxxxxxxxxxxxxxxxxxx> wrote: > > 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. > That's been proven not to be a good assertion. Just look at the bugs on systemd about not working if Owner Auth is set. I think it's important to look at models that support auth being set for the hierarchy and minimizing the need on it. Hierarchy Auth could even be a policy, thankfully I haven't bumped into that yet. If this "EK Signing" key is persisted and the AuthPolicy of the key cleared we would only need EH Auth one time versus assuming it's always empty. This would essentially be an SRK for the EH but includes sign attribute (ERK :-p). But if we're shoving stuff into a read only config, these options could be set in the config file (ie use a persistent handle at location XXX, no auth, etc). But *not* hardcoding EH auth into the config file. I would hate to see requirements requiring that hierarchy auth remains empty. > 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 >
