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: <aK1vdEcuN_xjhjyY@kernel.org>
Date: Tue, 26 Aug 2025 11:25:24 +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 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?

[1] https://lore.kernel.org/tpm2/aKzaTYCI2GO_UPRB@kernel.org/T/#u

BR, Jarkko