We disable elliptic curves using explicit parameters in RHEL, but they continue to work when created using EVP_PKEY_fromdata_init().

See the attached reproducer, which is not a well-known curve, but this example works on RHEL 9.2. (The reproducer fails correctly in FIPS mode.)

+++ This bug was initially created as a clone of Bug #2223953 +++

Testing upcoming PHP Version 8.3.0
and support to generate EC keys with custom EC parameters

Test passes on Fedora 38 with OpenSSL 3.0.9 and RHEL-9 with OpenSSL 3.0.7
It fails on Fedora 37, also with OpenSSL 3.0.9 (but different set of patches)

See discussion on
https://github.com/php/php-src/commit/0dadd6616a491418871fb0b41590a73b128aa212

Relevant part of the test
https://github.com/php/php-src/blob/master/ext/openssl/tests/ecc_custom_params.phpt#L26

Any help welcome on this

— Additional comment from Remi Collet on 2023-07-19 14:05:33 CEST —

Notice: test also fails on RHEL-8 with OpenSSL 1.1.1k

— Additional comment from Clemens Lang on 2023-07-19 14:33:35 CEST —

Both Fedora and RHEL do not support arbitrary EC parameters, see https://bugzilla.redhat.com/show_bug.cgi?id=1977867 and https://bugzilla.redhat.com/show_bug.cgi?id=2066412 which caused https://gitlab.com/redhat/centos-stream/rpms/openssl/-/blob/c9s/0012-Disable-explicit-ec.patch to be written, which is also applied in Fedora at https://src.fedoraproject.org/rpms/openssl/blob/f38/f/0012-Disable-explicit-ec.patch.

An older version of the same patch is also in F37: https://src.fedoraproject.org/rpms/openssl/blob/f37/f/0012-Disable-explicit-ec.patch

I believe a similar patch is applied on RHEL 8, but I can't find the exact location right now.

I would expect the test to fail on RHEL 9 and Fedora 38, too, unless the curve tested happens to match a well-known curve that RHEL 9 and F38 accept.

— Additional comment from Remi Collet on 2023-07-19 14:52:53 CEST —

> I would expect the test to fail on RHEL 9 and Fedora 38, too, unless the curve tested happens to match a well-known curve that RHEL 9 and F38 accept.

Test seems to use (from openssl_pkey_get_details after openssl_pkey_new) a "secp224r1" curve (despite comment says "OSCCA WAPIP192v1")

— Additional comment from Clemens Lang on 2023-07-19 15:04:19 CEST —

In that case what's happening is that OpenSSL 3 on RHEL 9 and Fedora 38 recognizes the curve and transparently uses its internal definition, which makes the test pass.
If this was using an explicitly defined curve that OpenSSL did not recognize, it should fail.

— Additional comment from Clemens Lang on 2023-07-19 15:13:49 CEST —

secp224r1 (aka NIST P-224) is defined in https://csrc.nist.gov/csrc/media/publications/fips/186/3/archive/2009-06-25/documents/fips_186-3.pdf section D.1.2.2 on page 88. This doesn't look like NIST P-224 to me.

— Additional comment from Remi Collet on 2023-07-19 15:32:14 CEST —

(In reply to Clemens Lang from comment #5)
> This doesn't look like NIST P-224 to me.

Indeed, rather wapip192v1
Only found this https://github.com/pedroalbanese/wapi/blob/main/wapip192v1.go#L14

So, as accepted (in F38) is it a bug in the new patch ?

— Additional comment from Clemens Lang on 2023-07-21 16:01:31 CEST —

— Additional comment from Clemens Lang on 2023-07-21 16:02:26 CEST —

No, this isn't a bug in the patch. While you can import those keys from their components using EVP_PKEY_fromdata() (which is what PHP does), you cannot do anything with the resulting key other than exporting it again. If you attempt to run any validation functions (EVP_PKEY_param_check(), or EVP_PKEY_public_check()), signature operations, or shared secret derivation with such a key, it will fail.

Fedora 37 has an older version of the patch, which fails earlier, but the end result is the same: you cannot use explicitly specified curves unless they happen to match a well-known curve.

At this time, we have no plans to backport the newer version of the patch to F37, since it does not make a functional difference:

f37:
[root@fedora37 ~]# cat test.pem
----BEGIN PRIVATE KEY----
MIIBAQIBADCBpAYHKoZIzj0CATCBmAIBATAkBgcqhkjOPQEBAhkAvbb0/j6LHZ4N
qMDUb0wxjO/kr+O2uFUfMDQEGLuOXo+8EV4Tn+aoFP5IqqbwraGqXfkZhQQYGFS+
vcMbIbeu/ICrDs0Q1bGzMI5tvxHBBBkCStX3BI3nCa1RI23mXk1LSCyDbcbkEGZA
AhkAvbb0/j6LHZ4NqMDUD8liGV36529WVkZ3AgEBBFUwUwIBAQQYjQrGWq6g1rli
VMZYF9ShQ6nnoDh28aN9oTQDMgAEmOB6rVDDH5GJ6+a4tccOXe5Z16i8NEzGYQnT
2W5S0IZ7nQXXLQe+WHaj2XPg6WeS
----END PRIVATE KEY----
[root@fedora37 ~]# openssl dgst -sha256 -sign test.pem test.pem
Error setting context
008EB0BB637F0000:error:1C8000B0:Provider routines:ossl_ec_check_key:invalid curve:providers/common/securitycheck.c:108:Explicit curves are not allowed in this build

f38:
[root@fedora38 ~]# openssl dgst -sha256 -sign test.pem test.pem
Could not read private key from test.pem
00AEC34A577F0000:error:1608010C:STORE routines:ossl_store_handle_load_result:unsupported:crypto/store/store_result.c:151:

I have also attached the reproducer in C that I used to verify this.

— Additional comment from Eno on 2023-07-23 02:32:48 CEST —

(In reply to Clemens Lang from comment #8)
> No, this isn't a bug in the patch. While you can import those keys from
> their components using EVP_PKEY_fromdata() (which is what PHP does), you
> cannot do anything with the resulting key other than exporting it again. If
> you attempt to run any validation functions (EVP_PKEY_param_check(), or
> EVP_PKEY_public_check()), signature operations, or shared secret derivation
> with such a key, it will fail.
>
> Fedora 37 has an older version of the patch, which fails earlier, but the
> end result is the same: you cannot use explicitly specified curves unless
> they happen to match a well-known curve.
>
> I have also attached the reproducer in C that I used to verify this.

When compiling and debugging this attached code with the official OpenSSL library version 3.1.0 release, I found two errors. The if conditions at line 222 and line 229 are incorrect.

After correcting these two errors, there are no issues with compiling and running.

Additionally, I can't understand why explicit parameter specification for curves other than named curves is not supported. Is there any security risk associated with this?

— Additional comment from Clemens Lang on 2023-07-24 12:52:55 CEST —

(In reply to Eno from comment #9)
> When compiling and debugging this attached code with the official OpenSSL
> library version 3.1.0 release, I found two errors. The if conditions at line
> 222 and line 229 are incorrect.
>
> After correcting these two errors, there are no issues with compiling and
> running.

You are correct. Thanks for catching these. I have reproduced that the signature works on both Fedora 38 and RHEL 9.2, which is not the intended behavior.
I am re-opening this, and we will consider it as a bug. I will also clone this to CentOS Stream 9 so it can be fixed in RHEL.

> Additionally, I can't understand why explicit parameter specification for
> curves other than named curves is not supported. Is there any security risk
> associated with this?

Yes. Explicitly specified curves may introduce mathematical vulnerabilities, and supporting explicit curves increases the attack surface.
See for example https://www.openssl.org/news/secadv/20220315.txt:

> It is possible to trigger the infinite loop by crafting a certificate that has invalid explicit curve parameters.