Using TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 with Secure Manager

[amos3]

Hello,

We are currently facing issues using cipher suites that use AES-GCM in conjunction with the Secure Manager.

Our understanding is that in order to make use of Secure Manager functionalities, we should use PSA APIs, however they currently only implement AES-CBC algorithms.

As gathered in this other post, it seems that we need to implement a PSA version of the GCM algorithm. We appreciate this is a very technical task, involving a deeper knowledge of cryptographic algorithms and were hoping ST could offer their knowledge and support in developing such function. In particular the `NX_CRYPTO_KEEP UINT  _nx_crypto_method_aes_psa_gcm_operation(...)` function, that needs to be added to Projects\STM32H573I-DK\Applications\ROT\Nx_Azure_IoT\NetXDuo\psa_crypto_ciphersuites\nx_crypto_aes_psa.c.

Many thanks,

Alex

[Jocelyn RICARD]

Hello @amos3 ,

I had a look to how this is implemented.

This gcm mapping on PSA API is today not possible because it requires the implementation of GCM multipart which is not available in the Secure Manager.

Now, is using NetXDuo software GCM implementation for TLS an issue for you ?

Thank you

Best regards

Jocelyn

[amos3]

Hi @Jocelyn RICARD,

Thank you for your response.

We don't necessarily have to use the PSA implementation, but our understanding was that we have to if we wanted to make use of the Secure Manager?

We are currently generating our ECC keys pair using PSA APIs so that they are not accessible outside the Secure Manager. Would we be able to use these keys for TLS connection with NetXDuo?

Thanks,

Alex

[Jocelyn RICARD]

Hello @amos3 ,

OK, I understand that the point would be to retrieve the session key generated by Secure Manager in order to be used by NetXDuo. I guess this should be possible using psa api to get the key value but this need to be checked if key generated can be transmitted to non secure.

One dummy question. What imposes you the usage of GCM crypto instead of CBC for TLS?

Thank you

Best regards

Jocelyn

[amos3]

Exactly, I don't think private keys can be exposed outside the Secure Manager so we would need the NetXDuo library to be able to interact with it, hence why we were hoping for the PSA APIs. Do you believe there are alternatives that would work for our use case?

Unfortunately, we can't use CBC because the system we need to connect to uses an HSM that doesn't support it (as it is no longer considered secure).

Many thanks,

Alex

[Jocelyn RICARD]

Hello Alex,

For short term I would leave the setup of secure communication only on NetXDuo side.

I raised the point to dev team and come back to you when I have more information.

Best regards

Jocelyn

[amos3]

Hi Jocelyn,

Thank you very much for the support and your quick replies.

We see the potential the Secure Manager provides and are very keen to make use of its features, would be great if we could move this forward.

Looking forward to the dev team response!

Many thanks,

Alex

[torntrousers]

Hello Jocelyn, could you give any update from the dev team on the CBC issue?

I work with Alex and our STM32 H5 project is stalled because of this.

Many organisations such as Qualys SSL Labs, Microsoft etc consider CBC ciphers to be weak and discourage their use these days. Major browsers have deprecated or disabled support for vulnerable CBC ciphers, and the general recomendation is that CBC ciphers should be avoided and instead use GCM where possible. This Cloudflare Blog post is from 2016: https://blog.cloudflare.com/padding-oracles-and-the-decline-of-cbc-mode-ciphersuites

Do you think ST might start supporting GCM with Secure Manager?

Looking forward to hearing from you.

Anthony

[Guillaume K]

Hello

Currently it's not possible to use multi part AES GCM in secure manager.

I understand your goal is to use secure manager's EC crypto. The use of Secure manager's AES is incidental due to current state of X-cube-azure-h5 code to connect to Microsoft Azure IoT server with MQTT and TLS.

I found a way to change the Azure IOT client code to use Netxduo crypto's AES instead of Secure Manager PSA. It still uses Secure Manager's ECDSA crypto to be able to use STM32H5 DUA private key.

This  allows to have a separate AES GCM connection to an HTTPS server (using netxduo AES GCM crypto) in the same application. 

To do so:

In Projects/STM32H573I-DK/Applications/ROT/Nx_Azure_IoT/NetXDuo/App/app_azure_iot_config.h, keep the standard config. In particular, keep enabled the #define ENABLE_PSA_CRYPTO_CIPHERSUITES.

In Projects/STM32H573I-DK/Applications/ROT/Nx_Azure_IoT/NetXDuo/App/nx_azure_iot_ciphersuites.c , comment the PSA AES and SHA256 crypto methods, and use the Netxduo one:

const NX_CRYPTO_METHOD *_nx_azure_iot_tls_supported_crypto[] =
{
    &crypto_method_hmac,
    &crypto_method_hmac_sha256,
    &crypto_method_tls_prf_sha256,
//#ifdef ENABLE_PSA_CRYPTO_CIPHERSUITES
//    &crypto_method_sha256_psa,
//    &crypto_method_aes_cbc_128_psa,
//#else
    &crypto_method_sha256,
    &crypto_method_sha384,
    &crypto_method_aes_cbc_128,
//#endif /* ENABLE_PSA_CRYPTO_CIPHERSUITES */
    &crypto_method_rsa,
#ifdef NX_SECURE_ENABLE_ECC_CIPHERSUITE
    &crypto_method_ecdhe,
#ifdef ENABLE_PSA_CRYPTO_CIPHERSUITES
    &crypto_method_ecdsa_psa_crypto,
#else
    &crypto_method_ecdsa,
#endif /* ENABLE_PSA_CRYPTO_CIPHERSUITES */
    &crypto_method_ec_secp384,
    &crypto_method_ec_secp256,
#endif /* NX_SECURE_ENABLE_ECC_CIPHERSUITE */
};

Note that crypto_method_ecdsa_psa_crypto is still present.

In Projects/STM32H573I-DK/Applications/ROT/Nx_Azure_IoT/NetXDuo/App/nx_secure_user.h , comment the special redefinition of NX_SECURE_HASH_METADATA_CLONE:

/* USER CODE BEGIN 2 */
//UINT nx_crypto_hash_clone_psa(VOID *dest_metadata, VOID *source_metadata, ULONG length);
//#define NX_SECURE_HASH_METADATA_CLONE nx_crypto_hash_clone_psa
/* USER CODE END 2 */

NX_SECURE_HASH_METADATA_CLONE should be defined to its standard value from nx_secure_tls.h (NX_SECURE_MEMCPY)

The connection to Azure IoT should work correctly using netxduo's AES CBC.

Note: the azure_iot IoT hub and DPS client code use _nx_secure_tls_session_create_ext() API with raw crypto arrays. I couldn't find a way to specify AES GCM instead of CBC because it uses _map_tls_ciphersuites() that expects a crypto method for NX_CRYPTO_ROLE_MAC_HASH and it doesn't exist.

Now about the HTTP+TLS connection in same application:

if you use nx_web_http_client_secure_connect() and provide a tls_setup_callback:

in the TLS setup callback you have to call nx_secure_tls_session_create() with a TLS configuration NX_SECURE_TLS_CRYPTO where you can specify netxduo's AES GCM crypto and secure manager's ECDSA PSA if you want to use it.

example (modified from nx_crypto_generic_ciphersuites.c):

NX_SECURE_TLS_CIPHERSUITE_INFO _nx_crypto_ciphersuite_lookup_table_ecc[] =
{
#ifdef NX_SECURE_ENABLE_AEAD_CIPHER
    {TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256, &crypto_method_ecdhe,     &crypto_method_ecdsa_psa_crypto,     &crypto_method_aes_128_gcm_16,  16,      16,        &crypto_method_null,            0,         &crypto_method_tls_prf_sha256},
#endif /* NX_SECURE_ENABLE_AEAD_CIPHER */
}

Note: you have to define NX_SECURE_ENABLE_AEAD_CIPHER in your nx_secure_user.h file.

[Jocelyn RICARD]

Hello @amos3 , @torntrousers ,

After sharing the concern internally, I had information that GCM multipart will be in a future version of the Secure Manager. It will take some time as it needs to be added on top of already committed evolutions. 

Until then, you may use the full software implementation proposed by Guillaume.

Another intermediate solution could be to adapt the code to perform key agreement using  psa_raw_key_agreement to get the shared secret and then do the rest in non secure. But I'm not sure this is worth the adaptation effort.

Best regards,

Jocelyn