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
Notice: test also fails on RHEL-8 with OpenSSL 1.1.1k
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.
> 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")
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.
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.
(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 ?
Created attachment 1976936 [details] Reproducer showing that the key can be imported, but not used
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.
(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?
(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.
Created attachment 1977285 [details] Fixed reproducer
For the record, the curve is the first curve specified in section A.2 of https://www.gmssl.cn/gmssl/down/GMT_0003.4-2012.pdf. That document apparently also happens to specify the SM2 curve, but this is *not* the SM2 curve. I've seen other references to this curve calling it sm2p192, but judging from the zero google hits on that search term, that is not a commonly used identifier.
Yes, there is a bug in my check of EC group in EVP_PKEY_fromdata the better patch is simple, we can add the same check if (EC_GROUP_check_named_curve(group, 0, bnctx) == NID_undef) { ERR_raise(ERR_LIB_EC, EC_R_UNKNOWN_GROUP); goto err; } to the branch group == named_group and a necessary test. Parsing private/public keys should work
Created attachment 1980231 [details] The patch to disable custom curves Doesn't include the fix for the tests (there are upstream tests covering custom generator)
FEDORA-2023-aaef7099ea has been submitted as an update to Fedora 38. https://bodhi.fedoraproject.org/updates/FEDORA-2023-aaef7099ea
FEDORA-2023-2a5f37e0f3 has been submitted as an update to Fedora 39. https://bodhi.fedoraproject.org/updates/FEDORA-2023-2a5f37e0f3
FEDORA-2023-2a5f37e0f3 has been pushed to the Fedora 39 stable repository. If problem still persists, please make note of it in this bug report.
FEDORA-2023-aaef7099ea has been pushed to the Fedora 38 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2023-aaef7099ea` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2023-aaef7099ea See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-2023-aaef7099ea has been pushed to the Fedora 38 stable repository. If problem still persists, please make note of it in this bug report.