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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <aTXsWIGR1qA0B_5I@kernel.org>
Date: Sun, 7 Dec 2025 23:06:32 +0200
From: Jarkko Sakkinen <jarkko@...nel.org>
To: linux-integrity@...r.kernel.org
Cc: tpm2@...ts.linux.dev, Peter Huewe <peterhuewe@....de>,
	Jason Gunthorpe <jgg@...pe.ca>,
	James Bottomley <James.Bottomley@...senpartnership.com>,
	Mimi Zohar <zohar@...ux.ibm.com>,
	David Howells <dhowells@...hat.com>,
	Paul Moore <paul@...l-moore.com>, James Morris <jmorris@...ei.org>,
	"Serge E. Hallyn" <serge@...lyn.com>,
	open list <linux-kernel@...r.kernel.org>,
	"open list:KEYS-TRUSTED" <keyrings@...r.kernel.org>,
	"open list:SECURITY SUBSYSTEM" <linux-security-module@...r.kernel.org>
Subject: Re: [PATCH v6 2/2] KEYS: trusted: Store parent's name to the encoded
 keys

On Sun, Dec 07, 2025 at 10:07:55PM +0200, Jarkko Sakkinen wrote:
> 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@...ts.linux.dev
> > > Signed-off-by: Jarkko Sakkinen <jarkko@...nel.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.

Storing the name of the parent to the key file has also some other
advantages such as enabling parent auto discovery, which is especially
useful with transient keys. Parent handle is not useful data as by
definition it has an ambiguous meaning.

It is neither "insecure" as child key is tied to one single parent but
at the same parent's handle is completely useless and irrelevant data.

There's nothing "niche" IMHO on storing parent's name at least, and
it is very limiting not to have it.

BR, Jarkko