public inbox for tpm2@lists.linux.dev
 help / color / mirror / Atom feed
From: "Jarkko Sakkinen" <jarkko@kernel.org>
To: <Andreas.Fuchs@infineon.com>, <tpm2@lists.linux.dev>
Cc: <prestwoj@gmail.com>
Subject: Re: TPM2_Sign vs TPM2_RSA_Decrypt
Date: Thu, 16 May 2024 16:31:46 +0300	[thread overview]
Message-ID: <D1B3UAYNEUQE.3PHLGENN3AYKM@kernel.org> (raw)
In-Reply-To: <e6ac8dc493f04fdca0469f7df7735468@infineon.com>

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

  reply	other threads:[~2024-05-16 13:31 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-05-16 10:25 TPM2_Sign vs TPM2_RSA_Decrypt Jarkko Sakkinen
2024-05-16 12:01 ` Andreas.Fuchs
2024-05-16 12:51   ` Jarkko Sakkinen
2024-05-16 13:05     ` Andreas.Fuchs
2024-05-16 13:31       ` Jarkko Sakkinen [this message]
2024-05-16 13:33         ` Jarkko Sakkinen
2024-05-16 13:44         ` James Prestwood
2024-05-16 13:55           ` Jarkko Sakkinen
2024-05-16 13:59             ` James Prestwood
2024-05-16 14:14               ` Andreas.Fuchs
2024-05-16 15:20                 ` Jarkko Sakkinen
2024-05-17 17:58                   ` Jarkko Sakkinen
2024-05-16 15:18               ` Jarkko Sakkinen

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=D1B3UAYNEUQE.3PHLGENN3AYKM@kernel.org \
    --to=jarkko@kernel.org \
    --cc=Andreas.Fuchs@infineon.com \
    --cc=prestwoj@gmail.com \
    --cc=tpm2@lists.linux.dev \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox