How to check if a key is FIPS-unapproved?

[junaruga]

Is there a way to check if a key or a key name is FIPS-unapproved (providers/fips/fipsprov.c - FIPS_UNAPPROVED_PROPERTIES) using C APIs in a C code?

The logic may be to get key name by the EVP_PKEY_get0_type_name(), then call the C API to ask if the key name is FIPS-unapproved or not.

It's related to this comment, #20758 (comment).

[t8m]

There is no such thing as an unapproved key. Well, there are some key types that do not have any FIPS approved operations but that is only an indirect thing. Instead you always need to try to use the key with an operation to find out whether that is approved or not. For example let's have a key that supports both signatures and decryption of encrypted data - the signature can be FIPS approved but the decryption non-approved. This is actually a real-world example with RSA keys - signatures with PKCS#1 v1.5 padding are approved, decryption with PKCS#1 v1.5 padding is unapproved.

[junaruga]

Thanks for answering it with the real-world example.

Instead you always need to try to use the key with an operation to find out whether that is approved or not.

For example, when calling the OSSL_DECODER_CTX_new_for_pkey() and/or OSSL_DECODER_from_bio(), and the program couldn't get the value for pkey because of the FIPS-unapproved, how can we know that the reason of failing to get the pkey is because of the FIPS-unapproved, not because of the wrong the input_type? Does these functions return a specific error code or message in the case?

[t8m]

I do not actually think there will be a failure from OSSL_DECODER_CTX_new_for_pkey() and OSSL_DECODER_from_bio() when a key is unapproved. Only when you try to use that key in an operation, it will fail if it is unapproved.

[t8m]

Or maybe for some key types it might fail in OSSL_DECODER_from_bio() and won't provide a value for pkey. However I do not think it is possible to recognize what triggered the failure. I assume the error will indicate unsupported algorithm or something like that. But you would need to test this.

[junaruga]

Yes, the SSL_DECODER_from_bio(dctx, bio) doesn't get the value for pkey when the key is FIPS-unapproved.

This annoys me. Because I want to know that failing to get the pkey is because of the wrong input_type or selection argument for the OSSL_DECODER_CTX_new_for_pkey() or because the key is FIPS-unapproved. The handling logic for the 2 cases can be different in the application side.

[t8m]

The error reporting from decoding failures is less than ideal. However there is no easy way how to fix this concrete case. If some key type does not have a FIPS approved implementation this is very much equal to not having an implementation at all. This is a consequence of the design where the FIPS provider and default provider are completely separate modules.

[junaruga]

I see. Thanks for explaining the situation.

[junaruga]

As a real case to know if a key is FIPS-unapproved or not, we failed to read the following key (EC PRIVATE KEY - AES-128-CBC) in OpenSSL 3.2.0 dev (cf71283) FIPS module. The SSL_DECODER_from_bio(dctx, bio) didn't get the value for pkey.

https://github.com/ruby/openssl/blob/7c34a439bae71f110dd40be35454b68bd2b82e37/test/openssl/test_pkey_ec.rb#L237-L247

-----BEGIN EC PRIVATE KEY-----
Proc-Type: 4,ENCRYPTED
DEK-Info: AES-128-CBC,85743EB6FAC9EA76BF99D9328AFD1A66

nhsP1NHxb53aeZdzUe9umKKyr+OIwQq67eP0ONM6E1vFTIcjkDcFLR6PhPFufF4m
y7E2HF+9uT1KPQhlE+D63i1m1Mvez6PWfNM34iOQp2vEhaoHHKlR3c43lLyzaZDI
0/dGSU5SzFG+iT9iFXCwCvv+bxyegkBOyALFje1NAsM=
-----END EC PRIVATE KEY-----

In this case, how can we know the key is FIPS-unapproved or not by checking both the code and the security policy document?

For the code, I guess that the code below is a clue. However, as it doesn't have the FIPS_DEFAULT_PROPERTIES or FIPS_UNAPPROVED_PROPERTIES, it's not clear if the PROV_NAMES_AES_128_CBC is FIPS-unapproved or not. Perhaps do I need to check the logic in the ossl_aes128cbc_functions? But where is the ossl_aes128cbc_functions implemented?

openssl/providers/fips/fipsprov.c

Line 315 in bd3b026

ALG(PROV_NAMES_AES_128_CBC, ossl_aes128cbc_functions),

For the security policy document (https://www.openssl.org/source/ - security policy links), openssl-3.0.8-security-policy-2023-05-05.pdf - 8.1 Cryptographic Algorithms (page 17) - AES 128 bits is listed as approved algorithms in OpenSSL 3.0.8 (FIPS 180-2). This is the key (EC PRIVATE KEY - AES-128-CBC) in this case, right? If it is, it's weird that the SSL_DECODER_from_bio(dctx, bio) didn't get the value for pkey in OpenSSL 3.2.0-dev. I am not sure if it is approved in the current OpenSSL 3.2.0-dev.

[t8m]

Here the reason is the password based encryption used in the old encrypted PEM format. It uses MD5 for deriving the encryption key from the password and MD5 is obviously not FIPS approved.

If you try to read this - what are the errors on the error stack if any?

[t8m]

So precisely speaking, the key is not unapproved. But we cannot decrypt it because the encryption uses unapproved algorithms.

[junaruga]

Here the reason is the password based encryption used in the old encrypted PEM format. It uses MD5 for deriving the encryption key from the password and MD5 is obviously not FIPS approved.

So precisely speaking, the key is not unapproved. But we cannot decrypt it because the encryption uses unapproved algorithms.

I see. Thanks for the answer. You know the password based encryption is not FIPS approved, and you know that that the encryption uses unapproved algorithms. However, I want to know that the encryption uses unapproved algorithms from reading the code by myself. Could you tell me how to know that by myself? Otherwise, I have to ask someone in OpenSSL project if a key is FIPS-unapproved every time. I want to avoid it.

If you try to read this - what are the errors on the error stack if any?

I tried if the ossl_pkey_read_generic prints the errors on the error stack by ERR_print_errors_fp(stderr). The ossl_pkey_read_generic calls the OSSL_DECODER_CTX_new_for_pkey() and OSSL_DECODER_from_bio() for every input_type ("DER" and "PEM"), and selection (EVP_PKEY_KEYPAIR, EVP_PKEY_KEY_PARAMETERS, EVP_PKEY_PUBLIC_KEY) cases. There is no ossl_clear_error() in the ossl_pkey_read_generic(). I commented it out.

The ossl_pkey_read_generic function is https://github.com/ruby/openssl/blob/7c34a439bae71f110dd40be35454b68bd2b82e37/ext/openssl/ossl_pkey.c#L117-L181

And below is my try. You can see the ERR_clear_error() before calling the ossl_pkey_read_generic(), and the ERR_print_errors_fp() after calling the ossl_pkey_read_generic().

diff --git a/ext/openssl/ossl_pkey.c b/ext/openssl/ossl_pkey.c
index 013412c..67ce85c 100644
--- a/ext/openssl/ossl_pkey.c
+++ b/ext/openssl/ossl_pkey.c
@@ -105,7 +105,7 @@ ossl_pkey_read(BIO *bio, const char *input_type, int selection, VALUE pass)
         pos2 = BIO_tell(bio);
         if (pos2 < 0 || pos2 <= pos)
             break;
-        ossl_clear_error();
+        /* ossl_clear_error(); */
         pos = pos2;
     }
   out:
diff --git a/ext/openssl/ossl_pkey_ec.c b/ext/openssl/ossl_pkey_ec.c
index 4b3a1fd..a7c91fa 100644
--- a/ext/openssl/ossl_pkey_ec.c
+++ b/ext/openssl/ossl_pkey_ec.c
@@ -163,7 +163,13 @@ static VALUE ossl_ec_key_initialize(int argc, VALUE *argv, VALUE self)
     arg = ossl_to_der_if_possible(arg);
     in = ossl_obj2bio(&arg);
 
+    ERR_clear_error();
     pkey = ossl_pkey_read_generic(in, pass);
+    if (!pkey) {
+        fprintf(stderr, "DEBUG errors start.\n");
+        ERR_print_errors_fp(stderr);
+        fprintf(stderr, "DEBUG errors end.\n");
+    }
     BIO_free(in);
     if (!pkey) {
         ossl_clear_error();

However I didn't see any error information by ERR_print_errors_fp() when running the reproducing Ruby script below.

$ OPENSSL_CONF=/home/jaruga/.local/openssl-3.2.0-dev-fips-debug-cf712830b7/ssl/openssl_fips.cnf \
  ruby -I./lib -ropenssl -e 'OpenSSL::PKey::EC.new("-----BEGIN EC PRIVATE KEY-----\nProc-Type: 4,ENCRYPTED\nDEK-Info: AES-128-CBC,85743EB6FAC9EA76BF99D9328AFD1A66\n\nnhsP1NHxb53aeZdzUe9umKKyr+OIwQq67eP0ONM6E1vFTIcjkDcFLR6PhPFufF4m\ny7E2HF+9uT1KPQhlE+D63i1m1Mvez6PWfNM34iOQp2vEhaoHHKlR3c43lLyzaZDI\n0/dGSU5SzFG+iT9iFXCwCvv+bxyegkBOyALFje1NAsM=\n-----END EC PRIVATE KEY-----\n", "abcdef")'
DEBUG errors start.
DEBUG errors end.
-e:1:in `initialize': invalid curve name (OpenSSL::PKey::ECError)
	from -e:1:in `new'
	from -e:1:in `<main>'

[paulidale]

In this case, how can we know the key is FIPS-unapproved or not by checking both the code and the security policy document?

The security policy document is the canonical source of truth for all things FIPS. Note that it changes over time and only the most recent version is gospel.

For the code, I guess that the code below is a clue. However, as it doesn't have the FIPS_DEFAULT_PROPERTIES or FIPS_UNAPPROVED_PROPERTIES, it's not clear if the PROV_NAMES_AES_128_CBC is FIPS-unapproved or not. Perhaps do I need to check the logic in the ossl_aes128cbc_functions? But where is the ossl_aes128cbc_functions implemented?

Better would be looking at the definition of the ALG macro to see that FIPS_DEFAULT_PROPERTIES applies:

openssl/providers/fips/fipsprov.c

Lines 42 to 46 in bd3b026

	#define ALGC(NAMES, FUNC, CHECK) \
	{ { NAMES, FIPS_DEFAULT_PROPERTIES, FUNC }, CHECK }
	#define UNAPPROVED_ALGC(NAMES, FUNC, CHECK) \
	{ { NAMES, FIPS_UNAPPROVED_PROPERTIES, FUNC }, CHECK }
	#define ALG(NAMES, FUNC) ALGC(NAMES, FUNC, NULL)

[t8m]

I see. Thanks for the answer. You know the password based encryption is not FIPS approved, and you know that that the encryption uses unapproved algorithms. However, I want to know that the encryption uses unapproved algorithms from reading the code by myself. Could you tell me how to know that by myself? Otherwise, I have to ask someone in OpenSSL project if a key is FIPS-unapproved every time. I want to avoid it.

Yeah, the current situation with the errors raised (or rather not raised) from decoders is bad and the fact that no error is raised in your testing is a bug that should be fixed - could you please create a concise testcase and report that as a separate bug? But even with that bug fixed you would just see that fetch for the MD5 algorithm as failed and possibly that PEM decoding failed in a subsequent error. That MD5 fetch failed because it is unapproved is a knowledge that you would have to have.

In general the only method that could give you true answer as for whether something is unsupported because of the FIPS rules and no other reasons would be to try to load and use the key with FIPS provider and then with DEFAULT provider if it fails with FIPS. If it then succeeds with DEFAULT provider it means the reason for the failure were the FIPS requirements.

[junaruga]

Yeah, the current situation with the errors raised (or rather not raised) from decoders is bad and the fact that no error is raised in your testing is a bug that should be fixed - could you please create a concise testcase and report that as a separate bug?

I am happy to create the concise testcase and report as a separate bug if I can create the reproducing program written in only C.

However, I am seeing a weird result with a C program that I created to reproduce the issue. Please look at the program. I intended the exactly same use case with the one that I reported above with the AES-128-CBC. However, the ERR_print_errors_fp prints the FIPS case specific errors in the reproducer. See the fips.log. This result is different from the one that I executed the Ruby C extension code. I am investigating the reason why the Ruby C extension doesn't print the errors.