On Tue, Sep 16, 2025 at 05:10:06AM +0300, Jarkko Sakkinen wrote: > On Mon, Sep 15, 2025 at 09:08:31PM +0300, Jarkko Sakkinen wrote: > > On Mon, Sep 15, 2025 at 05:50:07PM +0300, Jarkko Sakkinen wrote: > > > On Sun, Sep 14, 2025 at 11:24:24PM -0400, James Bottomley wrote: > > > > On Sun, 2025-09-14 at 19:08 +0300, Jarkko Sakkinen wrote: > > > > > Hi, > > > > > > > > > > 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. > > > > > > > > > > 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. > > > > > > Even if you fix it to persistent handle, the problem does not go > > > magically go away. Read public attributes are ubiquitos and > > > cryptographically correct way to do the binding. > > > > > > > > > > > > To address this issue I just added couple of optional fields to > > > > > TPMKey: > > > > > > > > > > parentName [6] EXPLICIT OCTET STRING OPTIONAL, > > > > > parentPubkey [7] EXPLICIT OCTET STRING OPTIONAL > > > > > > > > So that's a bit redundant, since if you know the key, you know its > > > > name. > > > > > > What I know is irrelevant here :-) > > > > > > > > > > > > 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. > > > > > > Transient handle is like file handle and persistent handle is like inode > > > number. Neither unambigiuously (and this is dead obvious) does not > > > identify any possible key. > > > > > > Further by binding key correctly, the requirement of being persistent > > > key goes away, which is a limiting factor. > > > > > > > > > > > > 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 > > > > Further there is two options: > > > > 1. Either remove TPM2 key ASN.1 support from kernel entirely. > > 2. Fix the 0day bug. > > > > It is unacceptable to make strong binding to a random open source > > project. I zero care what OpenSSL TPM2 engine does with the file > > format. > > OK, so obviously the binding exists that if the key matches the whatever > is in that persistent handle it will be loaded. However, that has still > ambiguity concern given that any pair of parent and child key matching > will do. It's much better if you can require a specific parent based > on its cryptographic stamp. > > So what I'll do for my project is that I just add those as optional > while adding parent handle for backward compatibility but users > of tpm2sh still get the benefit of enhanced security.
E.g., for kernel you could have them as kernel command-line parameter, and by having known stamps for legit parents also adds a bit interposer protection i.e., it disables capability from interposer to generate child keys effectively (with low cost as this requires only extra readpublic). I'll see how it works in my tools, gain experience and submit a kernel patch so that the feature gets semi-standardized. BR, Jarkko
