TPM2_Sign vs TPM2_RSA_Decrypt

TPM2_Sign vs TPM2_RSA_Decrypt

[Jarkko Sakkinen]

Hi,

I'm pushing with James Prestwood RSA and ECDSA based asymmetric keys to
asymmetric keys subsystem of the kernel and for e.g. RSA we can just use
TPM2_RSA_Decrypt:

https://lore.kernel.org/all/20200518172704.29608-18-prestwoj@gmail.com/

I've implemented some code that make this fit more cleanly to the kernel
and James will refactor his old code on top of that. I.e. add the
padding and asn1 data and make x.509 compatible scheme. Just do
textbook style RSA part with TPM2.

Just for plain interest, because I'm not too familiar with TPM2_Sign:
when would you choose to use it instead? I just want to make sure that
we're doing right things right :-)

BR, Jarkko

RE: TPM2_Sign vs TPM2_RSA_Decrypt

[Andreas.Fuchs]

For the OpenSSL engines and also the GNU-TLS engine, we go ahead and use TPM2_RSA_Decrypt for RSA Signing
but TPM2_Sign for ECDSA signing.

The reason here was, that OpenSSL wants to perform SHA512 digests and padding, whilst the TPM only supported SHA384.
And an OpenSSL engine could not tell the OpenSSL-TLS-module, which Hash-Algs are supported.
If that restriction does not exist, I would also tend to use TPM2_Sign for RSA signing.

Cheers,
Andreas

-----Original Message-----
From: Jarkko Sakkinen <jarkko@kernel.org> 
Sent: Donnerstag, 16. Mai 2024 12:25
To: tpm2@lists.linux.dev
Subject: TPM2_Sign vs TPM2_RSA_Decrypt

Caution: This e-mail originated outside Infineon Technologies. Do not click on links or open attachments unless you validate it is safe<https://intranet-content.infineon.com/explore/aboutinfineon/rules/informationsecurity/ug/SocialEngineering/Pages/SocialEngineeringElements_en.aspx>.



Hi,

I'm pushing with James Prestwood RSA and ECDSA based asymmetric keys to asymmetric keys subsystem of the kernel and for e.g. RSA we can just use
TPM2_RSA_Decrypt:

https://lore.kernel.org/all/20200518172704.29608-18-prestwoj@gmail.com/

I've implemented some code that make this fit more cleanly to the kernel and James will refactor his old code on top of that. I.e. add the padding and asn1 data and make x.509 compatible scheme. Just do textbook style RSA part with TPM2.

Just for plain interest, because I'm not too familiar with TPM2_Sign:
when would you choose to use it instead? I just want to make sure that we're doing right things right :-)

BR, Jarkko

Re: TPM2_Sign vs TPM2_RSA_Decrypt

[Jarkko Sakkinen]

On Thu May 16, 2024 at 3:01 PM EEST,  wrote:
> For the OpenSSL engines and also the GNU-TLS engine, we go ahead and
> use TPM2_RSA_Decrypt for RSA Signing but TPM2_Sign for ECDSA signing.

Yeah we get simplest and most understandable and most compatible
RSA because it is textbook style with no strings attached :-)
You can fit it to any scheme.

I can admit after reading TPM2_Sign documentation, my head hurts
and I still don't think I fully get the gist of it so better not
to use something that you don't get, right? :-)

If someone could really put TPM2_Sign into nutshell that'd be
awesome.

> The reason here was, that OpenSSL wants to perform SHA512 digests and
> padding, whilst the TPM only supported SHA384. And an OpenSSL engine
> could not tell the OpenSSL-TLS-module, which Hash-Algs are supported.
> If that restriction does not exist, I would also tend to use TPM2_Sign
> for RSA signing.

Maybe a dumb question but what I could possibly accomplish with
TPM2_Sign that I could not accomplish with TPM2_RSA_Decrypt and
appropraite ASN.1 heading and padding?

This connects to the not understanding TPM2_Sign (obviously).

Just trying to make sure that we make exactly right call for
kernel.

Thanks for responding!

>
> Cheers,
> Andreas

BR, Jarkko

RE: TPM2_Sign vs TPM2_RSA_Decrypt

[Andreas.Fuchs]

> If someone could really put TPM2_Sign into nutshell that'd be awesome.

Well, TPM2_Sign will perform a signing operation for you given the key.
You can set the scheme in the scheme parameter. That's about it...

> Maybe a dumb question but what I could possibly accomplish with TPM2_Sign that I could not accomplish with TPM2_RSA_Decrypt and appropraite ASN.1 heading and padding?

Yes. If you set TPMA_OBJECT_SIGN but unset TPMA_OBJECT_DECRYPT. This way you can make sure that only signing-padding can ever be executed but never decrypt-based stuff.
In order to use TPM2_RSA_Decrypt you need to set TPMA_OBJECT_DECRYPT which is kind of weird.

Also, if you want to use a restriced key (formally called Attestation Key) for regular signing operations, you need to have a TPMA_OBJECT_SIGN and must not have TPMA_OBJECT_DECRYPT set.

Those would be the reasons for preferring TPM2_Sign wherever possible IMHO.

Cheers,
Andreas

-----Original Message-----
From: Jarkko Sakkinen <jarkko@kernel.org> 
Sent: Donnerstag, 16. Mai 2024 14:52
To: Fuchs Andreas (SMD C3 EMEA TM) <Andreas.Fuchs@infineon.com>; tpm2@lists.linux.dev
Cc: James Prestwood <prestwoj@gmail.com>
Subject: Re: TPM2_Sign vs TPM2_RSA_Decrypt

Caution: This e-mail originated outside Infineon Technologies. Do not click on links or open attachments unless you validate it is safe<https://intranet-content.infineon.com/explore/aboutinfineon/rules/informationsecurity/ug/SocialEngineering/Pages/SocialEngineeringElements_en.aspx>.



On Thu May 16, 2024 at 3:01 PM EEST,  wrote:
> For the OpenSSL engines and also the GNU-TLS engine, we go ahead and 
> use TPM2_RSA_Decrypt for RSA Signing but TPM2_Sign for ECDSA signing.

Yeah we get simplest and most understandable and most compatible RSA because it is textbook style with no strings attached :-) You can fit it to any scheme.

I can admit after reading TPM2_Sign documentation, my head hurts and I still don't think I fully get the gist of it so better not to use something that you don't get, right? :-)

If someone could really put TPM2_Sign into nutshell that'd be awesome.

> The reason here was, that OpenSSL wants to perform SHA512 digests and 
> padding, whilst the TPM only supported SHA384. And an OpenSSL engine 
> could not tell the OpenSSL-TLS-module, which Hash-Algs are supported.
> If that restriction does not exist, I would also tend to use TPM2_Sign 
> for RSA signing.

Maybe a dumb question but what I could possibly accomplish with TPM2_Sign that I could not accomplish with TPM2_RSA_Decrypt and appropraite ASN.1 heading and padding?

This connects to the not understanding TPM2_Sign (obviously).

Just trying to make sure that we make exactly right call for kernel.

Thanks for responding!

>
> Cheers,
> Andreas

BR, Jarkko

Re: TPM2_Sign vs TPM2_RSA_Decrypt

[Jarkko Sakkinen]

On Thu May 16, 2024 at 4:05 PM EEST,  wrote:
> > If someone could really put TPM2_Sign into nutshell that'd be awesome.
>
> Well, TPM2_Sign will perform a signing operation for you given the key.
> You can set the scheme in the scheme parameter. That's about it...

Right. What about the ticket? Can you imagine a use case for that?

> > Maybe a dumb question but what I could possibly accomplish with TPM2_Sign that I could not accomplish with TPM2_RSA_Decrypt and appropraite ASN.1 heading and padding?
>
> Yes. If you set TPMA_OBJECT_SIGN but unset TPMA_OBJECT_DECRYPT. This
> way you can make sure that only signing-padding can ever be executed
> but never decrypt-based stuff. In order to use TPM2_RSA_Decrypt you
> need to set TPMA_OBJECT_DECRYPT which is kind of weird.

David, did you have a "framework" for deciding between these two
when you originally implemented the patch? I.e. did you consider
TPM2_Sign but ended up to TPM2_RSA_Decrypt?

Not meaning to blame just want to go fully through this :-) It
is working code after all.

Huge benefit I see with TPM2_Sign would be probably that we get
ECDSA from the same functionality.

Disadvantage is that we can use TPM2_Decrypt, i.e. single command
for decrypt operation. Encryption side is done in the case asymmetric
keys with software as it is done with the public key.

Have not actually looked at yet TPM2_EncrypDecrypt and
TPM2_EncryptDecrypt2 (do not know even their difference).

> Also, if you want to use a restriced key (formally called Attestation
> Key) for regular signing operations, you need to have a
> TPMA_OBJECT_SIGN and must not have TPMA_OBJECT_DECRYPT set.
>
> Those would be the reasons for preferring TPM2_Sign wherever possible IMHO.

Actually I think in our case it should be non-restricted as the
point is x.509 certs not proving TPM inherent properties.

Also section 3.5 seems to support this view, if I understand it
correctly:

https://trustedcomputinggroup.org/wp-content/uploads/TPM-2p0-Keys-for-Device-Identity-and-Attestation_v1_r12_pub10082021.pdf

So technically I see TPM2_RSA_Decrypt and TPM2_Sign still
equivalent in the context of use case...

>
> Cheers,
> Andreas

BR, Jarkko

Re: TPM2_Sign vs TPM2_RSA_Decrypt

[Jarkko Sakkinen]

On Thu May 16, 2024 at 4:31 PM EEST, Jarkko Sakkinen wrote:
> On Thu May 16, 2024 at 4:05 PM EEST,  wrote:
> > > If someone could really put TPM2_Sign into nutshell that'd be awesome.
> >
> > Well, TPM2_Sign will perform a signing operation for you given the key.
> > You can set the scheme in the scheme parameter. That's about it...
>
> Right. What about the ticket? Can you imagine a use case for that?
>
> > > Maybe a dumb question but what I could possibly accomplish with TPM2_Sign that I could not accomplish with TPM2_RSA_Decrypt and appropraite ASN.1 heading and padding?
> >
> > Yes. If you set TPMA_OBJECT_SIGN but unset TPMA_OBJECT_DECRYPT. This
> > way you can make sure that only signing-padding can ever be executed
> > but never decrypt-based stuff. In order to use TPM2_RSA_Decrypt you
> > need to set TPMA_OBJECT_DECRYPT which is kind of weird.
>
> David, did you have a "framework" for deciding between these two
  ~~~~~  
  James

Ugh, sorry ;-)

BR, Jarkko

Re: TPM2_Sign vs TPM2_RSA_Decrypt

[James Prestwood]

On 5/16/24 6:31 AM, Jarkko Sakkinen wrote:
> On Thu May 16, 2024 at 4:05 PM EEST,  wrote:
>>> If someone could really put TPM2_Sign into nutshell that'd be awesome.
>> Well, TPM2_Sign will perform a signing operation for you given the key.
>> You can set the scheme in the scheme parameter. That's about it...
> Right. What about the ticket? Can you imagine a use case for that?
>
>>> Maybe a dumb question but what I could possibly accomplish with TPM2_Sign that I could not accomplish with TPM2_RSA_Decrypt and appropraite ASN.1 heading and padding?
>> Yes. If you set TPMA_OBJECT_SIGN but unset TPMA_OBJECT_DECRYPT. This
>> way you can make sure that only signing-padding can ever be executed
>> but never decrypt-based stuff. In order to use TPM2_RSA_Decrypt you
>> need to set TPMA_OBJECT_DECRYPT which is kind of weird.
> David, did you have a "framework" for deciding between these two
> when you originally implemented the patch? I.e. did you consider
> TPM2_Sign but ended up to TPM2_RSA_Decrypt?
>
> Not meaning to blame just want to go fully through this :-) It
> is working code after all.
To be honest I started with encrypt/decrypt and included the signing 
operation because it was basically "free" by using tpm2_rsa_decrypt(). I 
was not aware of this distinction/difference between that and doing 
signing on the TPM itself. I don't think I ever looked into the signing 
command on the TPM itself.
>
> Huge benefit I see with TPM2_Sign would be probably that we get
> ECDSA from the same functionality.
>
> Disadvantage is that we can use TPM2_Decrypt, i.e. single command
> for decrypt operation. Encryption side is done in the case asymmetric
> keys with software as it is done with the public key.
>
> Have not actually looked at yet TPM2_EncrypDecrypt and
> TPM2_EncryptDecrypt2 (do not know even their difference).
>
>> Also, if you want to use a restriced key (formally called Attestation
>> Key) for regular signing operations, you need to have a
>> TPMA_OBJECT_SIGN and must not have TPMA_OBJECT_DECRYPT set.
>>
>> Those would be the reasons for preferring TPM2_Sign wherever possible IMHO.
> Actually I think in our case it should be non-restricted as the
> point is x.509 certs not proving TPM inherent properties.
>
> Also section 3.5 seems to support this view, if I understand it
> correctly:
>
> https://trustedcomputinggroup.org/wp-content/uploads/TPM-2p0-Keys-for-Device-Identity-and-Attestation_v1_r12_pub10082021.pdf
>
> So technically I see TPM2_RSA_Decrypt and TPM2_Sign still
> equivalent in the context of use case...
>
>> Cheers,
>> Andreas
> BR, Jarkko

Re: TPM2_Sign vs TPM2_RSA_Decrypt

[Jarkko Sakkinen]

On Thu May 16, 2024 at 4:44 PM EEST, James Prestwood wrote:
> To be honest I started with encrypt/decrypt and included the signing 
> operation because it was basically "free" by using tpm2_rsa_decrypt(). I 
> was not aware of this distinction/difference between that and doing 
> signing on the TPM itself. I don't think I ever looked into the signing 
> command on the TPM itself.

My personal take: I'd start RSA with the working code and just
clean up the parts for the first round. It is tested code and
does the job, right? :-)

Then we will weight the odds and cons in the review. That said,
if you want to use TPM_Sign and TPM2_EncryptDecrypt(2) that is
fine too, but not demand.

As for ECDSA, it can be part of the patch set, or we can start
just with the RSA part.

Andreas, is it OK if the patch set is CC'd to you so you can
give your feedback/remarks on it?

BR, Jarkko

Re: TPM2_Sign vs TPM2_RSA_Decrypt

[James Prestwood]

On 5/16/24 6:55 AM, Jarkko Sakkinen wrote:
> On Thu May 16, 2024 at 4:44 PM EEST, James Prestwood wrote:
>> To be honest I started with encrypt/decrypt and included the signing
>> operation because it was basically "free" by using tpm2_rsa_decrypt(). I
>> was not aware of this distinction/difference between that and doing
>> signing on the TPM itself. I don't think I ever looked into the signing
>> command on the TPM itself.
> My personal take: I'd start RSA with the working code and just
> clean up the parts for the first round. It is tested code and
> does the job, right? :-)
It was tested then yes, obviously need to verify that after 4 years :)
>
> Then we will weight the odds and cons in the review. That said,
> if you want to use TPM_Sign and TPM2_EncryptDecrypt(2) that is
> fine too, but not demand.
>
> As for ECDSA, it can be part of the patch set, or we can start
> just with the RSA part.
> Andreas, is it OK if the patch set is CC'd to you so you can
> give your feedback/remarks on it?
>
> BR, Jarkko

RE: TPM2_Sign vs TPM2_RSA_Decrypt

[Andreas.Fuchs]

TPM2_EncryptDecrypt2 is for Symmetric encryption (i.e. AES) only.

I'd still recommend to go for TPM2_Sign().
Note also that switching may be hard later down the road, since the key usage flags are define during creation.
So backwards compatibility is nasty here.

Feel free to CC me.
I'll do what I can.

-----Original Message-----
From: James Prestwood <prestwoj@gmail.com> 
Sent: Donnerstag, 16. Mai 2024 15:59
To: Jarkko Sakkinen <jarkko@kernel.org>; Fuchs Andreas (SMD C3 EMEA TM) <Andreas.Fuchs@infineon.com>; tpm2@lists.linux.dev
Subject: Re: TPM2_Sign vs TPM2_RSA_Decrypt

Caution: This e-mail originated outside Infineon Technologies. Do not click on links or open attachments unless you validate it is safe<https://intranet-content.infineon.com/explore/aboutinfineon/rules/informationsecurity/ug/SocialEngineering/Pages/SocialEngineeringElements_en.aspx>.



On 5/16/24 6:55 AM, Jarkko Sakkinen wrote:
> On Thu May 16, 2024 at 4:44 PM EEST, James Prestwood wrote:
>> To be honest I started with encrypt/decrypt and included the signing 
>> operation because it was basically "free" by using 
>> tpm2_rsa_decrypt(). I was not aware of this distinction/difference 
>> between that and doing signing on the TPM itself. I don't think I 
>> ever looked into the signing command on the TPM itself.
> My personal take: I'd start RSA with the working code and just clean 
> up the parts for the first round. It is tested code and does the job, 
> right? :-)
It was tested then yes, obviously need to verify that after 4 years :)
>
> Then we will weight the odds and cons in the review. That said, if you 
> want to use TPM_Sign and TPM2_EncryptDecrypt(2) that is fine too, but 
> not demand.
>
> As for ECDSA, it can be part of the patch set, or we can start just 
> with the RSA part.
> Andreas, is it OK if the patch set is CC'd to you so you can give your 
> feedback/remarks on it?
>
> BR, Jarkko

Re: TPM2_Sign vs TPM2_RSA_Decrypt

[Jarkko Sakkinen]

On Thu May 16, 2024 at 5:14 PM EEST,  wrote:
> TPM2_EncryptDecrypt2 is for Symmetric encryption (i.e. AES) only.
>
> I'd still recommend to go for TPM2_Sign().
> Note also that switching may be hard later down the road, since the key usage flags are define during creation.
> So backwards compatibility is nasty here.
>
> Feel free to CC me.
> I'll do what I can.

Great I get that but I'd still start with the existing code because it
was how it was done. I'm strong believer of "change only by stimulus"
and it is rare for feature patch set anyway land in the first round.

BR, Jarkko

Re: TPM2_Sign vs TPM2_RSA_Decrypt

[Jarkko Sakkinen]

On Thu May 16, 2024 at 6:20 PM EEST, Jarkko Sakkinen wrote:
> On Thu May 16, 2024 at 5:14 PM EEST,  wrote:
> > TPM2_EncryptDecrypt2 is for Symmetric encryption (i.e. AES) only.
> >
> > I'd still recommend to go for TPM2_Sign().
> > Note also that switching may be hard later down the road, since the key usage flags are define during creation.
> > So backwards compatibility is nasty here.
> >
> > Feel free to CC me.
> > I'll do what I can.
>
> Great I get that but I'd still start with the existing code because it
> was how it was done. I'm strong believer of "change only by stimulus"
> and it is rare for feature patch set anyway land in the first round.

In the case of asymmetric keys, the hash comes from outside and it is
signed by the TPM so to be neutral to the source, TPM2_RSA_Decrypt does
make sense. It is more robust in this case.

BR, Jarkko

Re: TPM2_Sign vs TPM2_RSA_Decrypt

[Jarkko Sakkinen]

On Thu May 16, 2024 at 4:59 PM EEST, James Prestwood wrote:
> On 5/16/24 6:55 AM, Jarkko Sakkinen wrote:
> > On Thu May 16, 2024 at 4:44 PM EEST, James Prestwood wrote:
> >> To be honest I started with encrypt/decrypt and included the signing
> >> operation because it was basically "free" by using tpm2_rsa_decrypt(). I
> >> was not aware of this distinction/difference between that and doing
> >> signing on the TPM itself. I don't think I ever looked into the signing
> >> command on the TPM itself.
> > My personal take: I'd start RSA with the working code and just
> > clean up the parts for the first round. It is tested code and
> > does the job, right? :-)
> It was tested then yes, obviously need to verify that after 4 years :)

Yeah, I gave some nitpicks for you (private) and yeah branch (tpm2_key)
branch has shenigans to call ANS.1 template acquiring function from the
stock RSA code in the kernel :-)

Better to do as little as possible and then we look at what actually
needs to be done.

In addition to Andreas, I'd recommend to first of all CC the patch
set to linux-crypto too in addition to linux-integrity and
keyrings and also Herbert Xu (crypto maintainer).

I know this is some effort to you but isn't it any way worth it
because then the work that you did years ago was not wasted? :-)

BR, Jarkko