Re: tpm2key.asn1 parent identification
James Bottomley <[email protected]> Sun, 14 Sep 2025 23:24:24 -0400
| Newsgroups | dev.linux.lists.tpm2,org.kernel.vger.linux-integrity |
|---|---|
| Message-ID | <6e1f2713288b48a1cc0311d01e281a98d8e7f45d.camel@HansenPartnership.com> |
On Sun, 2025-09-14 at 19:08 +0300, Jarkko Sakkinen wrote: > Hi, >=20 > In practice, while implementing tpm2sh and its self-contained TPM > emulator called "MockTPM", I've noticed that 'tpm2key.asn1.' has a > major bottleneck, but luckily it is easy to squash. >=20 > Parent handle should never be persisted, as it defies the existential > reason of having a file format in the first place. Actually, if you read the spec:it describes how to handle non- persistent parents by defining the exact form of the P256 parent you derive from the permanent handle in section 3.1.8: https://www.hansenpartnership.com/draft-bottomley-tpm2-keys.html This is the way all the implementations (well except the kernel, but that's fixable) do it. > To address this issue I just added couple of optional fields to > TPMKey: >=20 > =C2=A0 parentName=C2=A0=C2=A0 [6] EXPLICIT OCTET STRING OPTIONAL, > =C2=A0 parentPubkey [7] EXPLICIT OCTET STRING OPTIONAL So that's a bit redundant, since if you know the key, you know its name. > By persisting this information TPM2_GetCapability + TPM2_ReadPublic > can be used to acquire an appropriate handle. It can, how? If the parent is a primary, you can't insert it from a public key, you have to derive it and if it's non-primary, you need its parent to do the insertion. > I'd highly recommend to add this quirk to anything that processes > this ASN.1 format. Well, patches to the standard are accepted: https://groups.io/g/openssl-tpm2-engine/topics But first verify you don't simply need to use the non-persistent format. Regards, James