Eclipse ThreadX - NetXDuo is an advanced, industrial-grade TCP/IP network stack designed specifically for deeply embedded real-time and IoT applications
In our platforms with secure elements support, we are trying to use the NeXDuo version 6.2.0 release and found a bug in the NetXSecure code.
To evaluate NX_SECURE_X509_KEY_TYPE_HARDWARE key type and using the private key from secure element I have done the following
In the _nx_crypto_ciphersuite_lookup_table_ecc lookup table in nx_crypto_generic_ciphersuites.c file, I have provided my own public_auth function. For example I have replaced crypto_method_ecdsa with my_crypto_method_ecdsa, and all the callback functions in the my_crypto_method_ecdsa also replaced with my own functions.
Also in the Lookup table for X.509 digital certificates(_nx_crypto_x509_cipher_lookup_table_ecc) I have replaced crypto_method_ecdsa with my_crypto_method_ecdsa.
In my nx_crypot_operation function I have done my own implementation to generate the signature.
Called nx_secure_x509_certificate_initialize with key type as NX_SECURE_X509_KEY_TYPE_HARDWARE, actual device certificate and for private key I have given a string identifier like "hardware key".
With the above approach, NetXSecure as TLS client and with TLS1.2 the functionality is working as expected. With TLS1.2, during TLS handshake my nx_crypto_operation callback function is getting called and with the signature generated with my own function TLS handshake is successful.
To summarize I am able to use the NX_SECURE_X509_KEY_TYPE_HARDWARE for the private key in secure element when I am using NetXSecure as TLS1.2 client. But I am not able to enable secure element for NetXSecure as TLS1.2 server or TLS1.3 Client or TLS1.3 Server. And I think the root-cause of the issue is NetXSecure code is trying to access the hardware key content which I think it should not.
Hi,
In our platforms with secure elements support, we are trying to use the NeXDuo version 6.2.0 release and found a bug in the NetXSecure code.
To evaluate NX_SECURE_X509_KEY_TYPE_HARDWARE key type and using the private key from secure element I have done the following
With the above approach, NetXSecure as TLS client and with TLS1.2 the functionality is working as expected. With TLS1.2, during TLS handshake my nx_crypto_operation callback function is getting called and with the signature generated with my own function TLS handshake is successful.
But when I enable TLS1.3 and try for TLS1.3 client handshake the TLS handshake is failing. With my debugging found that handshake process fails at https://github.com/azure-rtos/netxduo/blob/v6.2.0_rel/nx_secure/src/nx_secure_tls_process_certificate_request.c#L152. The reason for this failure is at line https://github.com/azure-rtos/netxduo/blob/v6.2.0_rel/nx_secure/src/nx_secure_tls_process_certificate_request.c#L140 it is trying to access hardware private key content which is not the actual private key.
Similarly NetXSecure as TLS1.2 server also fails because of accessing the hardware key content at line https://github.com/azure-rtos/netxduo/blob/v6.2.0_rel/nx_secure/src/nx_secure_tls_ecc_generate_keys.c#L814.
To summarize I am able to use the NX_SECURE_X509_KEY_TYPE_HARDWARE for the private key in secure element when I am using NetXSecure as TLS1.2 client. But I am not able to enable secure element for NetXSecure as TLS1.2 server or TLS1.3 Client or TLS1.3 Server. And I think the root-cause of the issue is NetXSecure code is trying to access the hardware key content which I think it should not.