Re: [tpmdd-devel] [PATCH 1/1] add TPM2 version of create_tpm2_key and libtpm2.so engine

[Jason Gunthorpe <jgunthorpe@obsidianresearch.com>]

On Sat, Dec 31, 2016 at 02:52:43PM -0800, James Bottomley wrote:
> This patch adds RSA signing for TPM2 keys.  There's a limitation to the
> way TPM2 does signing: it must recognise the OID for the signature. 
>  That fails for the MD5-SHA1 signatures of the TLS/SSL certificate
> verification protocol, so I'm using RSA_Decrypt for both signing
> (encryption) and decryption ... meaning that this only works with TPM
> decryption keys.  It is possible to use the prior code, which preserved
> the distinction of signing and decryption keys, but only at the expense
> of not being able to support SSL or TLS lower than 1.2

[Note, I haven't looked closely at TPM2, but TPM1.2 has a concept of
 key usage, and I assume that is carried over in the below comments]

I think it is very important to natively support the sign-only key
usage restriction. TPM1.2 goes so far as to declare keys that can be
used for arbitary decrypt as 'legacy do not use'.

IMHO the best way to do this is to look at the sign operation openssl
is trying to do and see if it can be sent down the sign path to the
TPM. Only if that fails should the decrypt path be used.

For TPM1.2 you could create a sign-only key with the
TPM_SS_RSASSAPKCS1v15_DER mode and feed it arbitary NIDs - the TPM did
not check the data to sign, AFAIK.

Ideally the user should be able to setup a sign-only key and the
correct SSL negotiation parameters and have a working system, eg a
sign-only key used with TLS 1.3 and ephemeral keyx should work.

> +	/* this is slightly paradoxical that we're doing a Decrypt
> +	 * operation: the only material difference between decrypt and
> +	 * encrypt is where the padding is applied or checked, so if
> +	 * you apply your own padding up to the RSA block size and use
> +	 * TPM_ALG_NULL, which means no padding check, a decrypt
> +	 * operation effectively becomes an encrypt */

IIRC this duality is exactly why key usage exists, and why good crypto
practice has been to forbid decrypt/encrypt on the same key.

Jason

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most 
engaging tech sites, SlashDot.org! http://sdm.link/slashdot