[PATCH v6 2/2] KEYS: trusted: Store parent's name to the encoded keys

Jarkko Sakkinen jarkko at kernel.org
Sun Dec 7 20:07:50 UTC 2025


On Sun, Dec 07, 2025 at 07:57:13PM +0200, Jarkko Sakkinen wrote:
> On Sun, Dec 07, 2025 at 07:32:10PM +0200, Jarkko Sakkinen wrote:
> > Extend TPMKey ASN.1 speciication [1] with an optional 'parentName'
> > attribute containing TPM name of the parent key (in other words, TPMT_HA
> > blob).
> > 
> > The life-cycle for trusted keys will now proceed as follows:
> > 
> > 1. Encode parent's name to the 'paretName' during tpm2_key_encode().
> > 2. During tpm2_unseal_trusted, read parent's name from 'parentName'. When
> >    the attribute is not available, fallback on doing tpm2_read_public().
> > 
> > In other words, in the common (i.e., not loading a legacy key blob),
> > tpm2_read_public() will now only happen at the time when a key is first
> > created.
> > 
> > In addition, move tpm2_read_public() to 'tpm2-cmd.c' and make its body
> > unconditional so that the binary format of the saved keys is not dependent
> > on kernel configuration.
> > 
> > [1] https://www.hansenpartnership.com/draft-bottomley-tpm2-keys.txt
> > 
> > Cc: tpm2 at lists.linux.dev
> > Signed-off-by: Jarkko Sakkinen <jarkko at kernel.org>
> 
> As an alternative workaround I think the following could be possibly
> done (I need to trial it first though):
> 
> 1. Maintain a cache where a name gets added at the time of
>    tpm2_seal_trusted(). It is from TPMT_HA to TPMT_HA mapping,
>    mapping TPMT_HA of the key to the TPMT of the parent.
> 2. At thet time tpm2_unseal_trusted() retrieve name of thet
>    parent from the cache.
> 
> Capturing TPM2_CreatePrimary would be essentially duct taping the
> spec but I guess this could be more generally applicable. It neither 
> addresses persistent keys nor secondary parent keys, which we *have
> to support*, as the kernel interface does.

I think it is better to focus on merging the first patch and continue
this in the working groups mailing list first before implementing
complex quirks to address flaws of the file format.

BR, Jarkko



More information about the Linux-security-module-archive mailing list