TPM2 engine support for openssl

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

Quoted 8 lines · James Bottomley

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.

e_tpm2.c line 510

Quoted 6 lines

e_tpm2.c new file +6 -0

+	/* 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
_______________________________________________
tpmdd-devel mailing list [email protected]
https://lists.sourceforge.net/lists/listinfo/tpmdd-devel

Quoted 9 lines · James Bottomley

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.

e_tpm2.c line 510

Quoted 9 lines

(quoted diff) +2 -0

+	/* this is slightly paradoxical that we're doing a Decrypt
+	 * operation: the only material difference between decrypt

and

(quoted diff) +1 -0

+	 * encrypt is where the padding is applied or checked, so

if

(quoted diff) +1 -0

+	 * you apply your own padding up to the RSA block size and

use

e_tpm2.c new file +2 -0

+	 * 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
_______________________________________________
TrouSerS-tech mailing list [email protected]
https://lists.sourceforge.net/lists/listinfo/trousers-tech

Quoted 7 lines

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.

The problem is the MD5-SHA1 signature of SSL and TLS < v1.2. This
cannot be performed by the TPM because it's not listed as a supported signature, so the choice is either to deprecate these protocols (not really viable since they're in wide use in old websites) or use decrypt to do the signatures. Once we get to the point of having to use decrypt, there's no reason to preserve the signing distinction since we never know when a key will be used to decrypt or sign.

Quoted 9 lines · James Bottomley

Quoted 8 lines

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.

Quoted 8 lines

The problem is the MD5-SHA1 signature of SSL and TLS < v1.2. This
cannot be performed by the TPM because it's not listed as a supported signature, so the choice is either to deprecate these protocols (not really viable since they're in wide use in old websites) or use decrypt to do the signatures. Once we get to the point of having to use decrypt, there's no reason to preserve the signing distinction since we never know when a key will be used to decrypt or sign.

I'm not disputing your analysis, just remarking that it seem very undesirable to ban *all* sign-only keys just to support a single legacy SSL configuration.

This is why I suggest looking at the sign being requested and using the sign path if it is *possible*, otherwise requiring a key with the broader key usage.

Not everything is SSL - openssh uses these routines too and it should be able to use the sign only key type without a limitation?

Quoted 3 lines · Jason Gunthorpe

I'm not disputing your analysis, just remarking that it seem very undesirable to ban *all* sign-only keys just to support a single legacy SSL configuration.

It's not just a single situation. MD5-SHA1 is where it will fall apart on backwards compatibility but my current TPM doesn't understand anything other than sha1 or sha256, so it wouldn't allow more state of the art algorithms like sha224, sha384 or sha512 either.

I'm just not sure I see enough benefits to trying to preserve the decrypt vs sign distinction, whereas I do see the floods of complaints from users who got it wrong or think it should work as advertised.

Quoted 3 lines

... but my current TPM doesn't understand
anything other than sha1 or sha256, so it wouldn't allow more state of the art algorithms like sha224, sha384 or sha512 either.

Okay, yes, that is horrible :( If it is that bad it might not be worth the effort.

Jason Gunthorpe <jgunthorpe-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org> wrote on 01/03/2017 07:42:17 PM:

Quoted 2 lines

Quoted 2 lines

... but my current TPM doesn't understand
anything other than sha1 or sha256, so it wouldn't allow more state

of

Quoted 4 lines

Quoted 1 line

the art algorithms like sha224, sha384 or sha512 either.

Okay, yes, that is horrible :( If it is that bad it might not be worth the effort.

The place to ask for new algorithms is the TCG's Device Driver WG. It's an odd WG name, but this is the WG where the TPM mandatory algorithms are specified. A real, commercial use case will likely be an effective argument, since these are resource constrained and cost sensitive. SHA-384 and SHA-512 are currently optional, which traditionally means they won't be implemented.

Quoted 13 lines · Kenneth Goldman

Jason Gunthorpe <[email protected]> wrote on
01/03/2017
07:42:17 PM:

Quoted 2 lines

Quoted 2 lines

... but my current TPM doesn't understand anything other than sha1 or sha256, so it wouldn't allow

more state
of

Quoted 3 lines

Quoted 1 line

the art algorithms like sha224, sha384 or sha512 either.

Okay, yes, that is horrible :( If it is that bad it might not

be worth

Quoted 1 line

the effort.

Quoted 7 lines

The place to ask for new algorithms is the TCG's Device Driver WG. It's an odd WG name, but this is the WG where the TPM mandatory algorithms are specified. A real, commercial use case will likely be an effective argument, since these are resource constrained and cost sensitive. SHA-384 and SHA-512 are currently optional, which traditionally means they won't be implemented.

We don't need the algorithm in the TPM. We just need to be able to RSA sign an arbitary OID + externally computed hash like TPM 1.2 could.

What is the recommended way to create a key with a sign-only intent that can be used with arbitary OID + computed hash?

James is proposing using the Decrypt op to do this job.

Quoted 1 line

James is proposing using the Decrypt op to do this job.

I believe the TCG has decided this is the only way to sign arbitrary data.

We don't need the algorithm in the TPM. We just need to be able to RSA sign an arbitary OID + externally computed hash like TPM 1.2 could.

What is the recommended way to create a key with a sign-only intent that can be used with arbitary OID + computed hash?

James is proposing using the Decrypt op to do this job.

Quoted 8 lines · James Bottomley

Quoted 7 lines

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.

Quoted 7 lines

The problem is the MD5-SHA1 signature of SSL and TLS < v1.2. This
cannot be performed by the TPM because it's not listed as a supported signature, so the choice is either to deprecate these protocols (not really viable since they're in wide use in old websites) or use decrypt to do the signatures. Once we get to the point of having to use decrypt, there's no reason to preserve the signing distinction since we never know when a key will be used to decrypt or sign.

I'm not disputing your analysis, just remarking that it seem very undesirable to ban *all* sign-only keys just to support a single legacy SSL configuration.

This is why I suggest looking at the sign being requested and using the sign path if it is *possible*, otherwise requiring a key with the broader key usage.

Not everything is SSL - openssh uses these routines too and it should be able to use the sign only key type without a limitation?

Jason

Quoted 3 lines

[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]

The TPM1.2 all uses the correct signing functions, the problem is only with 2.0.

Quoted 3 lines

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'.

Note that google took an alternative approach and modified their TSS to work with a MD5-SHA1 signature:

https://chromium-review.googlesource.com/#/c/420811/

But this requires a modification to the TPM as well, which we can't do.