Re: [openssl-dev] [TrouSerS-tech] [tpmdd-devel] [PATCH 1/1] add TPM2 version of create_tpm2_key and libtpm2.so engine
On Tue, 2017-01-03 at 16:40 -0700, Jason Gunthorpe wrote: > On Tue, Jan 03, 2017 at 03:22:56PM -0800, James Bottomley wrote: > > > 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. > > 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. > 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. It's a trade off: the user configuration nightmare: how does an ordinary user know what type of TPM key they need ... they'll need to know what their TPM is capable of and what signatures they're likely to need. VS the benefits of having single use keys. 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. > Not everything is SSL - openssh uses these routines too and it should > be able to use the sign only key type without a limitation? Agreed that openssh only has forward compatibility problems, but it still has them thanks to the newer algorithm problem. Actually, the next problem would be gnome-keyring. It does openssl signatures and fishing the algorithm type out by the time James -- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] [TrouSerS-tech] [tpmdd-devel] [PATCH 1/1] add TPM2 version of create_tpm2_key and libtpm2.so engine
-Original Message- From: openssl-dev [mailto:openssl-dev-boun...@openssl.org] On Behalf Of James Bottomley Sent: Tuesday, January 03, 2017 6:23 PM To: Jason Gunthorpe <jguntho...@obsidianresearch.com> Cc: trousers-t...@lists.sourceforge.net; tpmdd-de...@lists.sourceforge.net; ibmtpm20tss-us...@lists.sourceforge.net; openssl-dev@openssl.org Subject: Re: [openssl-dev] [TrouSerS-tech] [tpmdd-devel] [PATCH 1/1] add TPM2 version of create_tpm2_key and libtpm2.so engine On Tue, 2017-01-03 at 16:11 -0700, Jason Gunthorpe wrote: > 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] The TPM1.2 all uses the correct signing functions, the problem is only with 2.0. > 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. 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. > 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. Given the signature restrictions, TPM 2.0 just can't be made to work with the older SSL/TLS protocols, so I'm opting to keep compatibility and not benefit from the distinction between signing and decryption keys. James > 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 > trousers-t...@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/trousers-tech > -- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev -- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] [TrouSerS-tech] [tpmdd-devel] [PATCH 1/1] add TPM2 version of create_tpm2_key and libtpm2.so engine
On Tue, 2017-01-03 at 16:11 -0700, Jason Gunthorpe wrote: > 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] The TPM1.2 all uses the correct signing functions, the problem is only with 2.0. > 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. 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. > 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. Given the signature restrictions, TPM 2.0 just can't be made to work with the older SSL/TLS protocols, so I'm opting to keep compatibility and not benefit from the distinction between signing and decryption keys. James > 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 > trousers-t...@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/trousers-tech > -- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
