linux-kernel - Re: [PATCH v7 4/5] keys: asymmetric: Add tpm2_key

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <aMuSvJNt2KdVBIOA@kernel.org>
Date: Thu, 18 Sep 2025 08:03:56 +0300
From: Jarkko Sakkinen <jarkko@...nel.org>
To: Herbert Xu <herbert@...dor.apana.org.au>
Cc: linux-integrity@...r.kernel.org, keyrings@...r.kernel.org,
	Andreas.Fuchs@...ineon.com, James Prestwood <prestwoj@...il.com>,
	David Woodhouse <dwmw2@...radead.org>,
	Eric Biggers <ebiggers@...nel.org>,
	James Bottomley <James.Bottomley@...senpartnership.com>,
	linux-crypto@...r.kernel.org, Stefan Berger <stefanb@...ux.ibm.com>,
	Lennart Poettering <lennart@...ttering.net>,
	"David S. Miller" <davem@...emloft.net>,
	open list <linux-kernel@...r.kernel.org>,
	David Howells <dhowells@...hat.com>,
	Ard Biesheuvel <ardb@...nel.org>,
	Mario Limonciello <mario.limonciello@....com>
Subject: Re: [PATCH v7 4/5] keys: asymmetric: Add tpm2_key_rsa

On Tue, Aug 26, 2025 at 11:25:24AM +0300, Jarkko Sakkinen wrote:
> On Thu, Jun 20, 2024 at 03:23:20AM +0300, Jarkko Sakkinen wrote:
> > On Fri Jun 7, 2024 at 1:58 PM EEST, Herbert Xu wrote:
> > > On Wed, May 29, 2024 at 12:08:09AM +0300, Jarkko Sakkinen wrote:
> > > >
> > > > +/*
> > > > + * Sign operation is an encryption using the TPM's private key. With RSA the
> > > > + * only difference between encryption and decryption is where the padding goes.
> > > > + * Since own padding can be used, TPM2_RSA_Decrypt can be repurposed to do
> > > > + * encryption.
> > > > + */
> > > > +static int tpm2_key_rsa_sign(struct tpm_chip *chip, struct tpm2_key *key,
> > > > +			     struct kernel_pkey_params *params,
> > > > +			     const void *in, void *out)
> > > > +{
> > > > +	const off_t o = key->priv_len + 2 + sizeof(*key->desc);
> > > > +	const struct tpm2_rsa_parms *p =
> > > > +		(const struct tpm2_rsa_parms *)&key->data[o];
> > > > +	const u16 mod_size = be16_to_cpu(p->modulus_size);
> > > > +	const struct rsa_asn1_template *asn1;
> > > > +	u32 in_len = params->in_len;
> > > > +	void *asn1_wrapped = NULL;
> > > > +	u8 *padded;
> > > > +	int ret;
> > > > +
> > > > +	if (strcmp(params->encoding, "pkcs1") != 0) {
> > > > +		ret = -ENOPKG;
> > > > +		goto err;
> > > > +	}
> > > > +
> > > > +	if (params->hash_algo) {
> > > > +		asn1 = rsa_lookup_asn1(params->hash_algo);
> > >
> > > Could you please explain why this can't be done through pkcs1pad
> > > instead of going to raw RSA?
> > 
> > Sorry was away couple of weeks from here. I replace this with TPM2_Sign
> > as is done already in the ECDSA module, so I guess that is a "yes".
> 
> Time travelling back to 2024 ;-)
> 
> I can't recall what I was thining here butI'm glad that I did not put
> the patch set further as now I have much more sane angle to this.
> 
> I realized while working on [1] that I'm better of making this to work
> as API on rsapubkey.asn1 and rsaprivkey.asn1 and matching files for
> ECC and do all steps inside kernel from this:
> 
> tpm2_createprimary --hierarchy o -G rsa2048 -c owner.txt
> tpm2_evictcontrol -c owner.txt 0x81000001
> tpm2_getcap handles-persistent
> openssl genrsa -out private.pem 2048
> tpm2_import -C 0x81000001 -G rsa -i private.pem -u key.pub -r key.priv
> tpm2_encodeobject -C 0x81000001 -u key.pub -r key.priv -o key.priv.pem
> openssl asn1parse -inform pem -in key.priv.pem -noout -out key.priv.der
> 
> I.e. my test tool does everything else except
> 
> openssl genrsa -out private.pem 2048
> 
> Im now pretty familiar with import procedure and how to prepare data
> for TPM2_Import and is like the "spirit" of it i.e., take external
> key and store it inside TPM2. That as side effect removes all the
> use of tpm2key.asn1 from the patch set and simplifies flows
> greatly.
> 
> And my Rust works help to get the preparation procedure exactly
> right and none of those crazy tools and commands will be needed.
> 
> The matching C code following TCG Architecture spec  I'll first write in
> user space and then port that kernel crypto APIs
> 
> That spans a question tho: should it be its own key type (as it is
> right now or would it be better idea to have parameter/option for
> hardware pre-existing RSA key types, or what would be the best
> direction API wise to approach this?

This response was filled wrong conclusions. The current
separate key types is the correct path. It's best to use TpmKey ASN.1
import as the keys might also source from TPM2_Create command, not
necessarily necessarily from external source, or at least it would be
stupid to limit it to only external keys.

So yeah two options to get this finally somehere are either pkcs1pad
route or more likely to change this to use TPM2_Sign, which should
be able to address padding internally at the chip.

Also I think RSA key should only expose here signinig operation for
the time being and encryption should be something reconsidered later
(if ever).

Just had a such a long pause since I've revisited this that did not
recall the reasoning why it was implemeted like it was.


BR, Jarkko