Re: TPM2_Sign vs TPM2_RSA_Decrypt

[James Prestwood <prestwoj@gmail.com>]

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