[tpm2] Re: tpm2-tools, tpm2-pkcs11, and OpenSSL 3.0

[tpm2] Re: tpm2-tools, tpm2-pkcs11, and OpenSSL 3.0

[Petr Gotthard]

[-- Attachment #1: Type: text/plain, Size: 4524 bytes --]

I spent some time with OpenSSL 3.0 so I could help.
 
In generall, all EC_KEY and RSA_KEY functions are deprecated for public use as this is a low-level API. There is no easy fix though-- the low-level functions need to be replaced by the high-level EVP API and there is no simple 1:1 mapping. The affected functions need to be rewritten almost completely, but in case of tpm2-tools and tpm2-pkcs11 the impact is not so high.
 
The good thing is that the EVP API is not(!) new. It has been there since OpenSSL 1.1.0, so one could write an implementation that works with both OpenSSL 1.1.x and OpenSSL 3.0. In fact, the OpenSSL 3.0 aims to have a very limited impact on "well-behaved" applications that refrain from using the (now deprecated) low-level APIs. An app that uses the EVP API from 1.1.x shall work with the 3.0 too.
 
 
The crucial question is: is it acceptable to require the OpenSSL 1.1.1 as the minimum version for tpm2-tools and tpm2-pkcs11?
 
The OpenSSL release strategy indicates the OpenSSL 1.1.1 is now the _only_ supported version! The 1.0.2 is no longer supported and also the 1.1.0 is no longer supported.
https://www.openssl.org/policies/releasestrat.html
 
Maintaining the support for the EOL OpenSSL (prior 1.1.1) would make the support for OpenSSL 3.0 more complicated, harder to review and maintain.
Even the tpm2-tools RELEASE.md says that "supporting an EOL crypto library is not a good idea".
https://github.com/tpm2-software/tpm2-tools/blob/master/doc/RELEASE.md#openssl
 
 
So, my recommendation would be to set OpenSSL 1.1.1 as the minimum version and then simply rewrite the affected functions using the EVP API from 1.1.1, which works also in 3.0. What do you think?
 
 
Regards,
Petr
 
______________________________________________________________
> Od: "Roberts, William C" <william.c.roberts(a)intel.com>
> Komu: "Jerry Snitselaar" <jsnitsel(a)redhat.com>, "tpm2(a)lists.01.org" <tpm2(a)lists.01.org>
> Datum: 25.05.2021 01:41
> Předmět: [tpm2] Re: tpm2-tools, tpm2-pkcs11, and OpenSSL 3.0
>
I can look at compiling with OpenSSL 3.0, I haven't even tried yet. But I would imagineit's all fixable. I don't see anything in the do_sig_verify that requires a non-const key. I would imagineit's just as simple as updating the call sites to match the signatures.I filed bugs:  - https://github.com/tpm2-software/tpm2-pkcs11/issues/686 <https://github.com/tpm2-software/tpm2-pkcs11/issues/686>  - https://github.com/tpm2-software/tpm2-tools/issues/2737 <https://github.com/tpm2-software/tpm2-tools/issues/2737>We'll try to get to these soon, as I would imagine distros are eager to start the process of transitioning over.BillFrom: Jerry Snitselaar <jsnitsel(a)redhat.com>
 Sent: Monday, May 24, 2021 4:34 PM
 To: tpm2(a)lists.01.org <tpm2(a)lists.01.org>
 Subject: [tpm2] tpm2-tools, tpm2-pkcs11, and OpenSSL 3.0 
 Both tpm2-tools and tpm2-pkcs11 make use of some functions that are
 being deprecated in openssl 3.0. Are there plans to move away from using
 those deprecated functions? Currently tpm2-tools will build with
 -Wno-error=deprecated-declarations, but tpm2-pkcs11 trips over
 EVP_PKEY_get0_EC_KEY now returning a const EC_KEY *, and ECDSA_do_verify
 taking a non const parameter. Someone suggested doing something like:
 
        EVP_PKEY_CTX    *pctx = NULL;
        if ((pctx = EVP_PKEY_CTX_new(pkey, NULL)) == NULL) {
                goto fail;
        }
 
        if (EVP_PKEY_verify_init(pctx) != 1 ||
            EVP_PKEY_verify(pctx, sigbuf, siglen,
            dgstbuf, dgstlen) != 1) {
                goto fail;
        }
  fail:
        EVP_PKEY_CTX_free(pctx);
 
 
 but I imagine the ASN.1 framing stuff mentioned in do_sig_verify_ec()
 would still be an issue, yes? I don't know openssl, so I don't know
 if you could get away with casting the pointer to EC_KEY *.
 
 There is work going on to support openssl 3.0 in RHEL9, so this came up.
 
 Regards,
 Jerry
 _______________________________________________
 tpm2 mailing list -- tpm2(a)lists.01.org
 To unsubscribe send an email to tpm2-leave(a)lists.01.org
 %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
 
 ----------
 
 _______________________________________________
 tpm2 mailing list -- tpm2(a)lists.01.org
 To unsubscribe send an email to tpm2-leave(a)lists.01.org
 %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s

[-- Attachment #2: attachment.htm --]
[-- Type: text/html, Size: 7473 bytes --]

[tpm2] Re: tpm2-tools, tpm2-pkcs11, and OpenSSL 3.0

[David Woodhouse]

[-- Attachment #1: Type: text/plain, Size: 373 bytes --]

On Mon, 2021-05-24 at 23:41 +0000, Roberts, William C wrote:
>  I don't see anything in the do_sig_verify that
> requires a non-const key.

If handed an EVP_PKEY with *only* the private key information
populated, OpenSSL could theoretically install the corresponding public
key when asked to do the verification.

cf. https://github.com/openssl/openssl/pull/10954

[-- Attachment #2: smime.p7s --]
[-- Type: application/x-pkcs7-signature, Size: 5174 bytes --]

[tpm2] Re: tpm2-tools, tpm2-pkcs11, and OpenSSL 3.0

[Roberts, William C]

[-- Attachment #1: Type: text/plain, Size: 4721 bytes --]

> I spent some time with OpenSSL 3.0 so I could help.

>

> In generall, all EC_KEY and RSA_KEY functions are deprecated for public use as this is a low-level API. There is no easy fix though-- the low-level functions need to be replaced by the high-level EVP API and there is > no simple 1:1 mapping. The affected functions need to be rewritten almost completely, but in case of tpm2-tools and tpm2-pkcs11 the impact is not so high.

>

> The good thing is that the EVP API is not(!) new. It has been there since OpenSSL 1.1.0, so one could write an implementation that works with both OpenSSL 1.1.x and OpenSSL 3.0. In fact, the OpenSSL 3.0 aims to > have a very limited impact on "well-behaved" applications that refrain from using the (now deprecated) low-level APIs. An app that uses the EVP API from 1.1.x shall work with the 3.0 too.

>


Interesting I did not know that



 > The crucial question is: is it acceptable to require the OpenSSL 1.1.1 as the minimum version for tpm2-tools and tpm2-pkcs11?


Now that ubuntu-16.04 is EOL, yes. I think theirs tickets in the various projects bug trackers to address that. That was the major hold up, while OpenSSL declared 1.0.2

dead, the rest of the world is still on it.


> The OpenSSL release strategy indicates the OpenSSL 1.1.1 is now the _only_ supported version! The 1.0.2 is no longer supported and also the 1.1.0 is no longer supported.

> https://www.openssl.org/policies/releasestrat.html



> Maintaining the support for the EOL OpenSSL (prior 1.1.1) would make the support for OpenSSL 3.0 more complicated, harder to review and maintain.

> Even the tpm2-tools RELEASE.md says that "supporting an EOL crypto library is not a good idea".

> https://github.com/tpm2-software/tpm2-tools/blob/master/doc/RELEASE.md#openssl



 > So, my recommendation would be to set OpenSSL 1.1.1 as the minimum version and then simply rewrite the affected functions using the EVP API from 1.1.1, which works also in 3.0. What do you think?



I agree. I think considering all the various factors, this is an appropriate time to ditch OSSL < 1.1.1





______________________________________________________________
> Od: "Roberts, William C" <william.c.roberts(a)intel.com>
> Komu: "Jerry Snitselaar" <jsnitsel(a)redhat.com>, "tpm2(a)lists.01.org" <tpm2(a)lists.01.org>
> Datum: 25.05.2021 01:41
> Předmět: [tpm2] Re: tpm2-tools, tpm2-pkcs11, and OpenSSL 3.0
>

I can look at compiling with OpenSSL 3.0, I haven't even tried yet. But I would imagine
it's all fixable. I don't see anything in the do_sig_verify that requires a non-const key. I would imagine
it's just as simple as updating the call sites to match the signatures.
I filed bugs:
  - https://github.com/tpm2-software/tpm2-pkcs11/issues/686
  - https://github.com/tpm2-software/tpm2-tools/issues/2737
We'll try to get to these soon, as I would imagine distros are eager to start the process of transitioning over.
Bill
________________________________
From: Jerry Snitselaar <jsnitsel(a)redhat.com>
Sent: Monday, May 24, 2021 4:34 PM
To: tpm2(a)lists.01.org <tpm2(a)lists.01.org>
Subject: [tpm2] tpm2-tools, tpm2-pkcs11, and OpenSSL 3.0


Both tpm2-tools and tpm2-pkcs11 make use of some functions that are
being deprecated in openssl 3.0. Are there plans to move away from using
those deprecated functions? Currently tpm2-tools will build with
-Wno-error=deprecated-declarations, but tpm2-pkcs11 trips over
EVP_PKEY_get0_EC_KEY now returning a const EC_KEY *, and ECDSA_do_verify
taking a non const parameter. Someone suggested doing something like:

       EVP_PKEY_CTX    *pctx = NULL;
       if ((pctx = EVP_PKEY_CTX_new(pkey, NULL)) == NULL) {
               goto fail;
       }

       if (EVP_PKEY_verify_init(pctx) != 1 ||
           EVP_PKEY_verify(pctx, sigbuf, siglen,
           dgstbuf, dgstlen) != 1) {
               goto fail;
       }
 fail:
       EVP_PKEY_CTX_free(pctx);


but I imagine the ASN.1 framing stuff mentioned in do_sig_verify_ec()
would still be an issue, yes? I don't know openssl, so I don't know
if you could get away with casting the pointer to EC_KEY *.

There is work going on to support openssl 3.0 in RHEL9, so this came up.

Regards,
Jerry
_______________________________________________
tpm2 mailing list -- tpm2(a)lists.01.org
To unsubscribe send an email to tpm2-leave(a)lists.01.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s


----------

_______________________________________________
tpm2 mailing list -- tpm2(a)lists.01.org
To unsubscribe send an email to tpm2-leave(a)lists.01.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s

[-- Attachment #2: attachment.htm --]
[-- Type: text/html, Size: 8187 bytes --]

[tpm2] Re: tpm2-tools, tpm2-pkcs11, and OpenSSL 3.0

[Roberts, William C]

[-- Attachment #1: Type: text/plain, Size: 2042 bytes --]


I can look at compiling with OpenSSL 3.0, I haven't even tried yet. But I would imagine
it's all fixable. I don't see anything in the do_sig_verify that requires a non-const key. I would imagine
it's just as simple as updating the call sites to match the signatures.

I filed bugs:
  - https://github.com/tpm2-software/tpm2-pkcs11/issues/686
  - https://github.com/tpm2-software/tpm2-tools/issues/2737

We'll try to get to these soon, as I would imagine distros are eager to start the process of transitioning over.

Bill


________________________________
From: Jerry Snitselaar <jsnitsel(a)redhat.com>
Sent: Monday, May 24, 2021 4:34 PM
To: tpm2(a)lists.01.org <tpm2(a)lists.01.org>
Subject: [tpm2] tpm2-tools, tpm2-pkcs11, and OpenSSL 3.0


Both tpm2-tools and tpm2-pkcs11 make use of some functions that are
being deprecated in openssl 3.0. Are there plans to move away from using
those deprecated functions? Currently tpm2-tools will build with
-Wno-error=deprecated-declarations, but tpm2-pkcs11 trips over
EVP_PKEY_get0_EC_KEY now returning a const EC_KEY *, and ECDSA_do_verify
taking a non const parameter. Someone suggested doing something like:

       EVP_PKEY_CTX    *pctx = NULL;
       if ((pctx = EVP_PKEY_CTX_new(pkey, NULL)) == NULL) {
               goto fail;
       }

       if (EVP_PKEY_verify_init(pctx) != 1 ||
           EVP_PKEY_verify(pctx, sigbuf, siglen,
           dgstbuf, dgstlen) != 1) {
               goto fail;
       }
 fail:
       EVP_PKEY_CTX_free(pctx);


but I imagine the ASN.1 framing stuff mentioned in do_sig_verify_ec()
would still be an issue, yes? I don't know openssl, so I don't know
if you could get away with casting the pointer to EC_KEY *.

There is work going on to support openssl 3.0 in RHEL9, so this came up.

Regards,
Jerry
_______________________________________________
tpm2 mailing list -- tpm2(a)lists.01.org
To unsubscribe send an email to tpm2-leave(a)lists.01.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s

[-- Attachment #2: attachment.htm --]
[-- Type: text/html, Size: 4893 bytes --]