tpm2key.asn1 parent identification
Jarkko Sakkinen
maintainerHi,
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
Jarkko Sakkinen
maintainerQuoted 11 lines · 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:
Quoted 8 lines
parentName [6] EXPLICIT OCTET STRING OPTIONAL,
parentPubkey [7] EXPLICIT OCTET STRING OPTIONALBy persisting this information
TPM2_GetCapability+TPM2_ReadPubliccan 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
James Bottomley
maintainerQuoted 19 lines · Jarkko Sakkinen
Quoted 18 lines · 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_ReadPubliccan be used to acquire an appropriate handle.
Quoted 7 lines
Quoted 2 lines
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.
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
James Bottomley
maintainerQuoted 8 lines · 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.
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.
Quoted 5 lines
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.
Quoted 2 lines
By persisting this information
TPM2_GetCapability+TPM2_ReadPubliccan 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.
Quoted 2 lines
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
Jarkko Sakkinen
maintainerQuoted 10 lines · James Bottomley
Quoted 8 lines · 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.
Quoted 8 lines
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.
Quoted 9 lines
Quoted 6 lines
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 :-)
Quoted 7 lines
Quoted 3 lines
By persisting this information
TPM2_GetCapability+TPM2_ReadPubliccan 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.
Quoted 6 lines
Quoted 3 lines
I'd highly recommend to add this quirk to anything that processes this ASN.1 format.
Well, patches to the standard are accepted:
Quoted 11 lines
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
Jarkko Sakkinen
maintainerQuoted 44 lines · Jarkko Sakkinen
Quoted 10 lines · James Bottomley
Quoted 8 lines · 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.
Quoted 8 lines
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.
Quoted 9 lines
Quoted 6 lines
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 :-)
Quoted 7 lines
Quoted 3 lines
By persisting this information
TPM2_GetCapability+TPM2_ReadPubliccan 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.
Quoted 14 lines
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.
Quoted 7 lines
Quoted 3 lines
I'd highly recommend to add this quirk to anything that processes this ASN.1 format.
Well, patches to the standard are accepted:
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.
Quoted 4 lines
Quoted 4 lines
But first verify you don't simply need to use the non-persistent format.
Quoted 8 lines
Quoted 6 lines
Regards,
James
BR, Jarkko
BR, Jarkko
Jarkko Sakkinen
maintainerQuoted 60 lines · Jarkko Sakkinen
Quoted 44 lines · Jarkko Sakkinen
Quoted 10 lines · James Bottomley
Quoted 8 lines · 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.
Quoted 8 lines
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.
Quoted 9 lines
Quoted 6 lines
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 :-)
Quoted 7 lines
Quoted 3 lines
By persisting this information
TPM2_GetCapability+TPM2_ReadPubliccan 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.
Quoted 14 lines
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.
Quoted 7 lines
Quoted 3 lines
I'd highly recommend to add this quirk to anything that processes this ASN.1 format.
Well, patches to the standard are accepted:
Quoted 8 lines
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
Jarkko Sakkinen
maintainerQuoted 76 lines · Jarkko Sakkinen
Quoted 60 lines · Jarkko Sakkinen
Quoted 44 lines · Jarkko Sakkinen
Quoted 10 lines · James Bottomley
Quoted 8 lines · 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.
Quoted 8 lines
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.
Quoted 9 lines
Quoted 6 lines
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 :-)
Quoted 7 lines
Quoted 3 lines
By persisting this information
TPM2_GetCapability+TPM2_ReadPubliccan 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.
Quoted 14 lines
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.
Quoted 7 lines
Quoted 3 lines
I'd highly recommend to add this quirk to anything that processes this ASN.1 format.
Well, patches to the standard are accepted:
Quoted 8 lines
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.
Quoted 3 lines
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
James Bottomley
maintainerQuoted 57 lines · Jarkko Sakkinen
Quoted 56 lines · Jarkko Sakkinen
Quoted 11 lines · James Bottomley
Quoted 9 lines · 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.
Quoted 8 lines
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.
Quoted 9 lines
Quoted 6 lines
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 :-)
Quoted 7 lines
Quoted 3 lines
By persisting this information
TPM2_GetCapability+TPM2_ReadPubliccan 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.
Quoted 4 lines
Quoted 3 lines
I'd highly recommend to add this quirk to anything that processes this ASN.1 format.
Quoted 8 lines
Quoted 3 lines
Quoted 3 lines
Well, patches to the standard are accepted:
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?
Quoted 3 lines
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
Jarkko Sakkinen
maintainerQuoted 62 lines · James Bottomley
Quoted 61 lines · Jarkko Sakkinen
Quoted 59 lines · Jarkko Sakkinen
Quoted 11 lines · James Bottomley
Quoted 9 lines · 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.
Quoted 8 lines
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.
Quoted 9 lines
Quoted 6 lines
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 :-)
Quoted 7 lines
Quoted 3 lines
By persisting this information
TPM2_GetCapability+TPM2_ReadPubliccan 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.
Quoted 7 lines
Quoted 3 lines
I'd highly recommend to add this quirk to anything that processes this ASN.1 format.
Well, patches to the standard are accepted:
Quoted 7 lines
Quoted 4 lines
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.
Quoted 5 lines
Quoted 4 lines
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.
Quoted 11 lines
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.
Quoted 7 lines
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.
Quoted 5 lines
Regards,
James
BRm Jarkko
Jarkko Sakkinen
maintainerQuoted 68 lines · Jarkko Sakkinen
Quoted 67 lines · James Bottomley
Quoted 65 lines · Jarkko Sakkinen
Quoted 45 lines · Jarkko Sakkinen
Quoted 11 lines · James Bottomley
Quoted 9 lines · 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.
Quoted 8 lines
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.
Quoted 9 lines
Quoted 6 lines
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 :-)
Quoted 7 lines
Quoted 3 lines
By persisting this information
TPM2_GetCapability+TPM2_ReadPubliccan 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.
Quoted 14 lines
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.
Quoted 7 lines
Quoted 3 lines
I'd highly recommend to add this quirk to anything that processes this ASN.1 format.
Well, patches to the standard are accepted:
Further there is two options:
1. Either remove TPM2 key ASN.1 support from kernel entirely.
2. Fix the 0day bug.
Quoted 13 lines
Quoted 2 lines
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.
Quoted 4 lines
Quoted 4 lines
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?
Quoted 25 lines
Quoted 12 lines
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.
Quoted 7 lines
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.
Quoted 8 lines
Sure I get that but as said there's been mostly positive tone in the patch reviews.
Quoted 5 lines
Regards,
James
BR, Jarkko
Jarkko Sakkinen
maintainerQuoted 93 lines · Jarkko Sakkinen
Quoted 68 lines · Jarkko Sakkinen
Quoted 67 lines · James Bottomley
Quoted 65 lines · Jarkko Sakkinen
Quoted 45 lines · Jarkko Sakkinen
Quoted 11 lines · James Bottomley
Quoted 9 lines · 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.
Quoted 8 lines
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.
Quoted 9 lines
Quoted 6 lines
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 :-)
Quoted 7 lines
Quoted 3 lines
By persisting this information
TPM2_GetCapability+TPM2_ReadPubliccan 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.
Quoted 14 lines
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.
Quoted 7 lines
Quoted 3 lines
I'd highly recommend to add this quirk to anything that processes this ASN.1 format.
Well, patches to the standard are accepted:
Further there is two options:
1. Either remove TPM2 key ASN.1 support from kernel entirely.
2. Fix the 0day bug.Quoted 13 lines
Quoted 2 lines
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.
Quoted 4 lines
Quoted 4 lines
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_CreateorTPM2_Import.
Quoted 6 lines
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
James Bottomley
maintainerQuoted 108 lines · Jarkko Sakkinen
Quoted 107 lines · Jarkko Sakkinen
Quoted 77 lines · Jarkko Sakkinen
Quoted 76 lines · James Bottomley
Quoted 74 lines · Jarkko Sakkinen
Quoted 53 lines · Jarkko Sakkinen
Quoted 17 lines · James Bottomley
Quoted 10 lines · 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.
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:
Quoted 4 lines
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.
Quoted 11 lines
Quoted 7 lines
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 :-)
Quoted 9 lines
Quoted 4 lines
By persisting this information
TPM2_GetCapability+TPM2_ReadPubliccan 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.
Quoted 14 lines
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.
Quoted 7 lines
Quoted 3 lines
I'd highly recommend to add this quirk to anything that processes this ASN.1 format.
Well, patches to the standard are accepted:
Further there is two options:
1. Either remove TPM2 key ASN.1 support from kernel entirely.
2. Fix the 0day bug.Quoted 13 lines
Quoted 2 lines
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.
Quoted 4 lines
Quoted 4 lines
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_CreateorTPM2_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.
Quoted 5 lines
Quoted 2 lines
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.
Quoted 1 line
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.
Quoted 4 lines
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
Jarkko Sakkinen
maintainerQuoted 129 lines · James Bottomley
Quoted 108 lines · Jarkko Sakkinen
Quoted 107 lines · Jarkko Sakkinen
Quoted 77 lines · Jarkko Sakkinen
Quoted 76 lines · James Bottomley
Quoted 74 lines · Jarkko Sakkinen
Quoted 53 lines · Jarkko Sakkinen
Quoted 17 lines · James Bottomley
Quoted 10 lines · 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.
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:
Quoted 4 lines
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.
Quoted 11 lines
Quoted 7 lines
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 :-)
Quoted 9 lines
Quoted 4 lines
By persisting this information
TPM2_GetCapability+TPM2_ReadPubliccan 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.
Quoted 14 lines
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.
Quoted 7 lines
Quoted 3 lines
I'd highly recommend to add this quirk to anything that processes this ASN.1 format.
Well, patches to the standard are accepted:
Further there is two options:
1. Either remove TPM2 key ASN.1 support from kernel entirely.
2. Fix the 0day bug.Quoted 13 lines
Quoted 2 lines
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.
Quoted 4 lines
Quoted 4 lines
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_CreateorTPM2_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.
Quoted 5 lines
Quoted 2 lines
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.
Quoted 1 line
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.
Quoted 4 lines
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.
Quoted 4 lines
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.
Quoted 5 lines
Regards,
James
James Bottomley
maintainerQuoted 3 lines · Jarkko Sakkinen
Quoted 2 lines · James Bottomley
Quoted 1 line · Jarkko Sakkinen
On Thu, Sep 18, 2025 at 08:35:38PM +0300, Jarkko Sakkinen wrote:
[...]
Quoted 42 lines
Quoted 37 lines
Quoted 16 lines
Quoted 16 lines
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_CreateorTPM2_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.
Quoted 5 lines
Quoted 2 lines
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.
Quoted 2 lines
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.
Quoted 4 lines
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.
Quoted 4 lines
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.
Quoted 7 lines
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_Createresponse, 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 ...
Quoted 2 lines
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
Jarkko Sakkinen
maintainerQuoted 49 lines · James Bottomley
Quoted 3 lines · Jarkko Sakkinen
Quoted 2 lines · James Bottomley
Quoted 1 line · Jarkko Sakkinen
On Thu, Sep 18, 2025 at 08:35:38PM +0300, Jarkko Sakkinen wrote:
[...]
Quoted 44 lines
Quoted 37 lines
Quoted 16 lines
Quoted 16 lines
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_CreateorTPM2_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.
Quoted 5 lines
Quoted 2 lines
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.
Quoted 2 lines
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.
Quoted 4 lines
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.
Quoted 4 lines
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.
Quoted 7 lines
Quoted 5 lines
I think the most feasible approch especially for volatile keys would be to store all structures included in
TPM2_Createresponse, 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.
Quoted 4 lines
Quoted 3 lines
Creation data contains indefinitive information about parent and this also enable the use of tickets.
Quoted 8 lines
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