OpenSSL doesn't handle refpem key correctly, nxp scheme is working

[tksec]

Hi all,

I'm trying to integrate the SE050 to be used in a node.js webserver. I successfully compiled the middleware including the OpenSSL provider and also got the ssscli to work.

With ssscli I created a keypair, injected it into the SE and created a refpem key. I also adapted the openssl.cnf of the system to match the one in simwtop/demos/linux/common/openssl30_sss_se050.cnf.

But any TLS connection to the server fails in the handshake as OpenSSL uses the reference to the key slot as actual private key instead of calling the SE050 provider.

I also tried to get it to work with OpenSSL CLI, i.e., openssl s_server. I can get a connection using the nxp:<slot> scheme but not using the refpem key file.

The following command leads to the error:

openssl s_server -accept 12345 -cert server.pem -key server.refpem.key -CAfile root.pem

 Error:

SSL3 alert read:fatal:decrypt error
SSL_accept:error in error
ERROR
20203CA4FFFF0000:error:1B80006E:lib(55):ossl_parse_query:trailing characters:../openssl-3.0.13/crypto/property/property_parse.c:454:HERE-->/usr/lib/libsssProvider.so
20203CA4FFFF0000:error:0A00041B:SSL routines:ssl3_read_bytes:tlsv1 alert decrypt error:../openssl-3.0.13/ssl/record/rec_layer_s3.c:1590:SSL alert number 51 
shutting down SSL

If I use the nxp url scheme, though, I can successfully connect to the server.

openssl s_server -accept 12345 -cert server.pem -key nxp:0x6789ABCD -CAfile root.pem

However, I can't specify the nxp:0x6789ABCD key reference in the node.js code but have to use the refpem file. Is there anyway to do that?

I also tried to make OpenSSL prioritize the SE050 provider over the default one by specifiying a propquery in the config file. But no luck so far.

# Relevant parts from openssl.cnf
[openssl_init]
providers = provider_sect
alg_section = evp_properties

[provider_sect]
default = default_sect
nxp_prov = nxp_prov_sec

[default_sect]
 activate = 1

[nxp_prov_sec]
identity = nxp_prov
module = /usr/local/lib/libsssProvider.so
activate = 1

[evp_properties]
default_properties = ?provider=nxp_prov

Any help would be highly appreciated!

[thomas_ha]

Hi @tksec,

have you found a suitable way to use the key reference in node.js?

I have a similar issue. I am using the se05x-openssl-provider (v01.00.03) with OpenSSL 3.0.14 to generate a key pair, but I am unable to use "Reference Keys in file format" as described in the Readme-File of the Github Repo of the openssl provider.
The other two versions (Labels with reference key (Example - nxp:"path to reference key file") and
Labels with key id (Example - nxp:0x12345678) just work fine.

The Readme says the following: "NOTE: When using this method, the sss provider has to be loaded first. This will ensure that the sss provider can decode the key id information present in the reference key."
Unfortunately, I don't know how to do this. Loading the provider by adding it to the openssl.cnf file did not work for me. I still get an decrypt error if I want to use the Reference Key in file format.

Thank you in advance.

Best regards

Thomas

[tksec]

Hi @Kan_Li 

thanks for clarifying that the refpem key is only useable for the openssl engine. The issue with node.js in particular is that they call the PEM_read_bio_PrivateKey function directly on any key string that is provided, which obviously fails when the key string is not a PEM string or file path but a uri. There is no direct support for OpenSSL providers, yet.

I reverted back to using the OpenSSL engine instead and got into similar problems. While using an EC key is working perfectly, using an RSA key fails again while parsing the PEM file with error:1E08010C:DECODER routines::unsupported from OpenSSL. I debugged the code and could trace the error back to the function PEM_read_bio_PrivateKey which is called from within EmbSe_LoadPrivKey in the engine's code.

Are you aware of such an issue to handle an RSA refpem key in the OpenSSL engine? How can this be solved? For me it looks like the refpem is more invasive for RSA than it is for EC keys which might be an issue?

[Kan_Li]

Hi @tksec ,

How did you generate the refpem for RSA key? by the tool of ssscli? which version of MW are you using now? Please kindly clarify.

Have a great day,
Kan

-------------------------------------------------------------------------------
Note:
- If this post answers your question, please click the "Mark Correct" button. Thank you!
- We are following threads for 7 weeks after the last post, later replies are ignored
Please open a new thread and refer to the closed one, if you have a related question at a later point in time.
-------------------------------------------------------------------------------

[tksec]

Hi @Kan_Li ,

yes, I used the ssscli tool. I'm running MW v4.05.00. I created the original key with OpenSSL on a different system. Loaded it into SE using ssscli set command and created the refpem with ssscli refpem command. The key can successfully be used and parsed when using the openssl commands like s_client, s_server, rsa, etc. It can also be converted to a EVP_PKEY using OSSL_STORE API (what the openssl commands do internally) but it fails to parse using PEM_read_bio_PrivateKey which is used by both the NXP engine (in EmbSe_LoadPrivKey) and node.js.

Thanks!

[Kan_Li]

Hi @tksec ,

Thanks for the information! What is the use case you are using with refpem file? sign&verify? I may try to reproduce this issue here.

Best Regards,

Kan

[Kan_Li]

Hi @tksec ,

The refpem key file is only for openssl engine, but since you use openssl 3.xx with provider, please use "nxp:key_id" instead. You may compare "se05x_mw_v04.05.01\simw-top\demos\linux\tls_client\scripts\tlsSeClient.sh" with "se05x_mw_v04.05.01\simw-top\demos\linux\tls_client\scripts\tlsSeClient_3_0.sh" to check the difference.  and I am also wondering if you have any security concern regarding this, actually from my option, it is just a string should be accepted by most of the scripts, why not able to specify the nxp:0x6789ABCD key reference in the node.js code? Please kindly clarify.

Have a great day,
Kan

-------------------------------------------------------------------------------
Note:
- If this post answers your question, please click the "Mark Correct" button. Thank you!
- We are following threads for 7 weeks after the last post, later replies are ignored
Please open a new thread and refer to the closed one, if you have a related question at a later point in time.
-------------------------------------------------------------------------------

[meslor]

I am experiencing the same exact problem of @tksec.

If using OpenSSL cli tools everything is fine, I can establish a TLS connection that uses a key in the SE052 module via libsssProvider.so.

On Node.js, I verified that libsssProvider is loaded, but handshake always fails, as per error below:

SSL3 alert write:fatal:decrypt error
SSL_connect:error in error
20109DB6FFFF0000:error:0A00007B:SSL routines:tls_process_cert_verify:bad signature:/usr/src/debug/openssl/3.2.1/ssl/statem/statem_lib.c:584:

It seems that referring the key by id as suggested by @Kan_Li  does not actually work:

-  If I provide in options.key the path to the refpem file, server starts w/o issues and listens for connections, but handshake fails as reported.

- If I provide in options.key the key path as urk (nxp:<path>) applications crashes

- If I provide in options.key the key reference (nxp:<keyid>) applications crashes

So, can you @Kan_Li  please share a piece of Node.js code that can successfully initialize a server, assuming that, as stated, this should just work fine?

Thanks

[meslor]

I forgot to mention that the Node version I'm using is 20.12.2.
Versions later than 20.x may not have this issue, I have no way to verify this at this time.

After further investigation, it emerged that the client-side decryption issue was caused by an incorrect provider loading order.

That said, it turns out that this version of Node has a problematic handling of random number generation.

The problem is related to how Node initializes providers.

Specifically, in the initialization of the random generators, which leads to an infinite loop of calls to sss_rand_get_ctx_params.
The node.cc file contains a fix (with a comment in the source), but it doesn't work with libsssProvider.so.

I'm sharing a series of workarounds in case anyone finds themselves in a similar situation.
I'll start by saying that these are all related to the libsssProvider and are primarily intended to NOT change Node or OpenSSL, so other much cleaner solutions are obviously possible.

I can't share the code; I hope the information below is clear enough.

Available options:
1. In the CMakeLists.txt file, set the SSS_PROV_DISABLE_SE05X_RNG variable.
This completely disables the use of SE05X for randoms.
It's not ideal, but if you don't have any special needs, it works.
2. In the sssProvider_main.c file, change the algorithms of the srands structure so that the name provided is NOT one of the known ones (and especially NOT the default). This still makes it possible to use the SE05X random module if needed, by setting the random key in the openssl config file.
3. Similar to point 2, but in this case the name is optionally provided with an environment variable (srands obviously can't be constant). This way, only in the case of Node applications you can avoid using the SE05X random generator, leaving it active for other uses instead.

The refpems work correctly with these options.