On Mon, Sep 22, 2025 at 05:31:24PM -0400, James Bottomley wrote: > On Mon, 2025-09-22 at 11:56 +0300, Jarkko Sakkinen wrote: > > On Thu, Sep 18, 2025 at 08:35:38PM +0300, Jarkko Sakkinen wrote: > > > On Thu, Sep 18, 2025 at 06:48:06PM +0300, Jarkko Sakkinen wrote: > > > > On Tue, Sep 16, 2025 at 10:33:43PM -0400, James Bottomley wrote: > > > > > On Mon, 2025-09-15 at 21:08 +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. > > > > > > > > > > Can you please explain in technical terms what you see as a > > > > > zero day bug in the current implementation? > > > > > > > > It's essentially ambiguity problem in my opinion that locks in > > > > the creator TPM if you know the expected parent. 0day might be > > > > overstatement yes, but it is essentially the immutable reference > > > > in this scheme. If you want to scope it, it's essentially a great > > > > way to add some defence in depth to the scheme. > > > > > > > > > > > > > > > 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. > > > > > > The way I see it, a "random project" would apply to any project > > > that a format is locked in, and it is quite obvious that fixing > > > handle as the anchor is exactly fit for exactly for this project, > > > and within those exact limits it is probably a sustainable choice. > > > > > > Being able to fix key into cryptographic identity is somewhat sane > > > addition because not only does it lock-in the creator but it also > > > allows to use offline stored keys with the same scheme i.e., > > > non-endorsement hierarchy derived keys created with TPM2_Create or > > > TPM2_Import. > > > > > > In the context of OpenSSL TPM2 engine, perhaps the current scheme > > > is fine but in the context of supporting a "ecosystem" as a kernel > > > feature it's not in its current form robust enough. > > > > > > And how else I can describe it other than I don't care about the > > > project, if the file format enforces me align with it? > > > > The ASN.1 definition limits types of keys while there's no any good > > reasons to disregard transient keys. > > As I explained in the bit you quote above, the spec covers volatile > parents. > > > It also enforces handle numbers, which is not very robust approach. > > I think if you read the spec, you'll find it only requires handle > numbers for persistent keys ... specific handle numbers being a feature > of those keys required by TPM spec. > > > I've neither seen any cryptographic object in my life, which uses > > ambiguous data as part of the identity no matter how hypothetical > > the possible threat scenarios are. It's a bad security practice > > plain and simple. > > This contains no actionable technical content. However, it is possible > the spec doesn't cover your use case, it's just you haven't actually > outlined what your use case is, so no-one who knows the spec can > actually confirm or deny this.
I revisited the issue and this is how I see the situation. I think the most feasible approch especially for volatile keys would be to store all structures included in TPM2_Create response, instead of only storing the first two response parameters. Rest of the blobs can be e.g. optional. It's the most bottleneck free way to address any issues. Creation data contains indefinitive information about parent and this also enable the use of tickets. > > Regards, > > James >
