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
next prev parent 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