On Sat, 2024-03-30 at 18:48 +0000, Gabríel Arthúr Pétursson wrote: > On Tue, 2024-02-13 at 12:13 -0500, James Bottomley wrote: > > + /* unique: key specific; for ECC it is two points */ > > + tpm_buf_append_u16(&template, 0); > > + tpm_buf_append_u16(&template, 0); > > Shouldn't the points be 32 bytes each in size, filled with zeros? > > The TCP TPM 2.0 Provisioning Guidance defines the SRK Template as a > diff on top of Template L-2 (for ECC keys) as defined in the EK > Credential Profile 2.0 document. > > Template L-2 calls for the X and Y points to be of 32 bytes each, > filled with zeros. The Provisioning Guidance does not call for zero- > sized points. > > For example, let's create an ECC Endorsement Key using the standard > template then print its name: > > tpm2_createek -G ecc -c /dev/null -u ./ek.pub > tpm2_loadexternal -c n -u ./ek.pub > > Equivalently using tpm2_createprimary: > > perl -e 'print "\0"x64' | tpm2_createprimary -C e -o ./ek.pub -G > ecc -a > 'fixedtpm|fixedparent|sensitivedataorigin|adminwithpolicy|restricted| > decrypt' -L > 837197674484b3f81a90cc8d46a5d724fd52d76e06520b64f2a1da1b331469aa -u - > tpm2_loadexternal -c n -u ./ek.pub > > You'll find that the key's public modulus matches that of the EK > Certificate imprinted by the manufacturer, indicating we got the > template correct. > > To generate a standard SRK key, the TCG TPM2 Provisioning Guidance > states we should: > > 1. set userWithAuth, > 2. clear adminWithPolicy > 3. set noDA, and > 4. clear the authorization policy. > > There's no mention of alterations to the unique field. > > Let's also create the key in the null hierarchy: > > perl -e 'print "\0"x64' | tpm2_createprimary -C n -o ./null.pub -G > ecc -a > 'fixedtpm|fixedparent|sensitivedataorigin|userwithauth|noda|restricte > d|decrypt' -u - > tpm2_loadexternal -c n -u ./null.pub > > The name does not match the kernel's name for the null key. So this seems to be a fairly global problem. If you look at openssl_tpm2_engine, openconnect and gnutls, they all formulate the ECC primary template this way (zero size points). They all look to have inherited it from the IBM TSS: https://github.com/kgoldman/ibmtss/blob/master/utils/objecttemplates.c#L272-L275 Ironically, even the Intel TSS based openssl engine and the provider seem to define it this way as well, and they definitely didn't get it from the IBM TSS: https://github.com/tpm2-software/tpm2-tss-engine/blob/master/src/tpm2-tss-engine-common.h#L149-L152 The problem is if we change it now, it would break all the current keys with primary handles (which is pretty much all of them thanks to almost no-one following the provisioning guidance about persistent handles). So I'm not really sure how to solve this. At the moment the kernel doesn't use permanent handles for keys, but it should and it should follow what all of the industry is doing for interoperability (i.e. zero size points), which means the NULL primary should also follow it. James
