tpm2key.asn1 parent identification

tpm2key.asn1 parent identification

[Jarkko Sakkinen]

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.

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

By persisting this information TPM2_GetCapability + TPM2_ReadPublic can
be used to acquire an appropriate handle.

I'd highly recommend to add this quirk to anything that processes this
ASN.1 format.

BR, Jarkko

Re: tpm2key.asn1 parent identification

[Jarkko Sakkinen]

On Sun, Sep 14, 2025 at 07:08:37PM +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.
> 
> 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
> 
> By persisting this information TPM2_GetCapability + TPM2_ReadPublic can
> be used to acquire an appropriate handle.
> 
> I'd highly recommend to add this quirk to anything that processes this
> ASN.1 format.


Here's a proof of concept:

https://github.com/puavo-org/tpm2sh/commit/18ec3c2169b23523d8866c58fa7b8a89a79bd3d4

BR, Jarkko

Re: tpm2key.asn1 parent identification

[James Bottomley]

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.

> 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.

> 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

Re: tpm2key.asn1 parent identification

[Jarkko Sakkinen]

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
> 
> But first verify you don't simply need to use the non-persistent
> format.
> 
> Regards,
> 
> James
> 
> 
> 

BR, Jarkko

Re: tpm2key.asn1 parent identification

[Jarkko Sakkinen]

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.

> > 
> > But first verify you don't simply need to use the non-persistent
> > format.
> > 
> > Regards,
> > 
> > James
> > 
> > 
> > 
> 
> BR, Jarkko

BR, Jarkko

Re: tpm2key.asn1 parent identification

[Jarkko Sakkinen]

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.

BR, Jarkko

Re: tpm2key.asn1 parent identification

[Jarkko Sakkinen]

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

Re: tpm2key.asn1 parent identification

[James Bottomley]

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 is unacceptable to make strong binding to a random open source
> project. I zero care what OpenSSL TPM2 engine does with the file
> format.

I don't really get what you mean here, but the tone, which is also in
several of your replies is unmistakably hostile.  My usual playbook for
defusing this is to respond only to technical content.  However,
several people have cited to me this hostility as the reason they're
unwilling to engage further with the linux-integrity@ or keyrings@
lists and have moved on to pursue other interests. Since losing
talented contributors because of things like this is a tragedy and
because it's partly my fault for letting this continue, I'm now asking
you to please make the effort to tone down the hostile rhetoric. 
That's not to say you can't do technical criticism, you absolutely can,
just do it without hectoring and implying sinister motivations.

I think most of us have noticed that there seem to be various
circumstances in your life that are producing significant stress but at
the same time, that's not a reason to take it out on the mailing lists.
There are resources available to help with maintainer stress and
burnout and I'd certainly be happy to connect you or help out here in
another way if you'd like.

Regards,

James

Re: tpm2key.asn1 parent identification

[Jarkko Sakkinen]

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.
> 
> I don't really get what you mean here, but the tone, which is also in
> several of your replies is unmistakably hostile.  My usual playbook for
> defusing this is to respond only to technical content.  However,
> several people have cited to me this hostility as the reason they're
> unwilling to engage further with the linux-integrity@ or keyrings@
> lists and have moved on to pursue other interests. Since losing
> talented contributors because of things like this is a tragedy and
> because it's partly my fault for letting this continue, I'm now asking
> you to please make the effort to tone down the hostile rhetoric. 
> That's not to say you can't do technical criticism, you absolutely can,
> just do it without hectoring and implying sinister motivations.

This goes a bit off-topic but I don't recognize this as I'm usually
helpful in my own code reviews at least, and acknowledging my own
misconceptions.

> 
> I think most of us have noticed that there seem to be various
> circumstances in your life that are producing significant stress but at
> the same time, that's not a reason to take it out on the mailing lists.
> There are resources available to help with maintainer stress and
> burnout and I'd certainly be happy to connect you or help out here in
> another way if you'd like.

Sure I get that but as said there's been mostly positive tone in
the patch reviews.

> 
> Regards,
> 
> James
> 

BRm Jarkko

Re: tpm2key.asn1 parent identification

[Jarkko Sakkinen]

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?

> > 
> > I don't really get what you mean here, but the tone, which is also in
> > several of your replies is unmistakably hostile.  My usual playbook for
> > defusing this is to respond only to technical content.  However,
> > several people have cited to me this hostility as the reason they're
> > unwilling to engage further with the linux-integrity@ or keyrings@
> > lists and have moved on to pursue other interests. Since losing
> > talented contributors because of things like this is a tragedy and
> > because it's partly my fault for letting this continue, I'm now asking
> > you to please make the effort to tone down the hostile rhetoric. 
> > That's not to say you can't do technical criticism, you absolutely can,
> > just do it without hectoring and implying sinister motivations.
> 
> This goes a bit off-topic but I don't recognize this as I'm usually
> helpful in my own code reviews at least, and acknowledging my own
> misconceptions.
> 
> > 
> > I think most of us have noticed that there seem to be various
> > circumstances in your life that are producing significant stress but at
> > the same time, that's not a reason to take it out on the mailing lists.
> > There are resources available to help with maintainer stress and
> > burnout and I'd certainly be happy to connect you or help out here in
> > another way if you'd like.
> 
> Sure I get that but as said there's been mostly positive tone in
> the patch reviews.
> 
> > 
> > Regards,
> > 
> > James
> > 

BR, Jarkko

Re: tpm2key.asn1 parent identification

[Jarkko Sakkinen]

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. 

It also enforces handle numbers, which is not very robust approach.

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.

BR, Jarkko

Re: tpm2key.asn1 parent identification

[James Bottomley]

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.

Regards,

James

Re: tpm2key.asn1 parent identification

[James Bottomley]

On Sun, 2025-09-14 at 19:23 +0300, Jarkko Sakkinen wrote:
> On Sun, Sep 14, 2025 at 07:08:37PM +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.
> > 
> > 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
> > 
> > By persisting this information TPM2_GetCapability + TPM2_ReadPublic
> > can be used to acquire an appropriate handle.
> > 
> > I'd highly recommend to add this quirk to anything that processes
> > this ASN.1 format.
> 
> 
> Here's a proof of concept:
> 
> https://github.com/puavo-org/tpm2sh/commit/18ec3c2169b23523d8866c58fa7b8a89a79bd3d4

Saving the output of read_public and comparing against the saved value
provides no proof of binding.  This is actually what the systemd TPM
keys handlers do and, as I demonstrated in FOSDEM, an interposer attack
that's early enough to come at key sealing still manages to exfiltrate
the secret without being revealed.

https://archive.fosdem.org/2025/schedule/event/fosdem-2025-4827-recent-tpm-security-enhancements-to-the-linux-kernel/

One possible benefit of saving the public part of the TPM key parent is
to give subsequent sessions a known key to encrypt a salt to which an
interposer can't hack.  However, this only works, as demonstrated
above, if you certify the parent *before* you save it.  However, if
you're doing certification, it's just as easy to derive a primary and
certify that before salting the session ... again, as demonstrated,
this is done by saving the name of the EK signing key somewhere in an
encrypted filesystem the attacker wouldn't find it easy to alter.

Regards,

James

Re: tpm2key.asn1 parent identification

[Jarkko Sakkinen]

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
> 

Re: tpm2key.asn1 parent identification

[James Bottomley]

On Tue, 2025-09-23 at 17:25 +0300, Jarkko Sakkinen wrote:
> 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:
[...]
> > > > 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.

I still don't understand what issues you're referring to.  However ...

> Creation data contains indefinitive information about parent and this
> also enable the use of tickets.

This is already being discussed on the list if you want to join:

https://groups.io/g/openssl-tpm2-engine/topic/patch_doc_update_draft_rfc/115384542

Regards,

James

Re: tpm2key.asn1 parent identification

[Jarkko Sakkinen]

On Tue, Sep 23, 2025 at 10:37:06AM -0400, James Bottomley wrote:
> On Tue, 2025-09-23 at 17:25 +0300, Jarkko Sakkinen wrote:
> > 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:
> [...]
> > > > > 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.
> 
> I still don't understand what issues you're referring to.  However ...

OK so I can work on the topic more. In my case, I realized that the is
existential question that why having ASN.1 format is useful in the first
place. This is not to say there is not existential reason (i.e. not
claiming that but) if save just the whole response to the disk I can
load a key as:

1. Read the response blob.
2. Read parent identity from CREATION_DATA
3. With the information iterate through handles in the TPM and find the
   correct parent
4. Pass the parent handle to TPM2_Load

So if this works out I might not need to change tpm2key if I just use
the response blob itself as the file format. I need to experiment with
this and find the possible issues wit the approach, and if there are
fields in ASN.1 that don't exist in some form in the raw TPM data.

> 
> > Creation data contains indefinitive information about parent and this
> > also enable the use of tickets.
> 
> This is already being discussed on the list if you want to join:
> 
> https://groups.io/g/openssl-tpm2-engine/topic/patch_doc_update_draft_rfc/115384542
> 
> Regards,
> 
> James
> 

BR, Jarkko