X-CUBE-AZURE-H7 hw cryptographic acceleration

[JDosp.1]

Hi Team,

Is there roadmap for implementation hardware cryptography acceleration for NetX Secure using CRYP peripheral at STM32H7?

I am using STM32H735@520MHz and I am not able achieve more than 800kBit/sec for HTTPs connection (TLS 1.2 TLS_RSA_WITH_AES_128_GCM_SHA256). With HTTP only I ave no issue to achieve to 80Mbit/sec. I use 100Mbit PHY (DP83826). From this reason I think that bottleneck is a software cryptography at NetX secure.

I am try to implement AES GCM support into _nx_crypto_method_aes_gcm_operation() inside nx_crypto_aes.c but without success yet.

Thanks for answer or any hint.

Regards,

Jan

[Jocelyn RICARD]

Hello Jan,

As you know Microsoft decided to disengage from development on Azure RTOS and provide the code to opensource community.

Following this decision, ST is evaluating the consequences on the support of AzureRTOS on STM32.

The strategy is today to support all the products that are released and already in the pipe.

This support is only addressing already existing features. No further specific development is planed

The hardware acceleration of the cryptography is currently not available so will not be supported.

About your actual performance issue, I would like to raise the point that usage of hw accelerated cryptography only concerns the AES block encryption.

The improvement you can expect is lowered by all the software overhead involved by the usage of the cryptography in general and the setup of the hw cryptography peripheral each time it is used. I'm not saying you will not gain anything but this will surely not be 10 times faster!

Besides, you may know that we provide mbedTLS alternates to plug the crypto acceleration. Unfortunately, the GCM is not available for STM32H7 (see here). But it exists for STM32L5 that has similar accelerator (see here)

This code used on mbedTLS should be a good starting point to do the same on NETXDuo

Best regards

Jocelyn

[JDosp.1]

Hi Jocelyn,

Thank you for answer. I hope you understand my frustration that feature promised by the Field Application Support Manager from ST was never implemented.

Yes, I know that STM32H7 does not have PKA peripheral. But i still think that hardware encryption will significantly improve performance. But maybe not 10x but it will be very close. According my tests with CRYPT peripheral and WolfSSL and CycloneCRYPTO benchmarks.

I think mbedTLS implementation is not much applicable. Because logic of mbedTLS cryptography routines is slightly different than that at NetX Crypt. Especially padding handling and data alignment is different. Proper hardware cryptography implementation requires high level of knowledge of cryptography and cryptography hardware itself. Hardly imagine that this can be delivered someone else that by manufacturer itself. But as you said ST doesn't care about this topic.

Regards,

Jan

[Bubbles]

@JDosp.1,

we do care, but AzureRTOS is not our product and neither will be the successor developed by Eclipse. We do not plan further development with NetX, which is not the best option anymore. But in the near future you can expect a better solution based on FreeRTOS and mbedTLS with full HW support.

BR,

J

[JDosp.1]

Hi Bubbles,

OK, how do you call that ST is providing software packages with critical security vulnerability and does not case about updating them?

I think product management at ST does not understand how embedded development at real word looks like. It is need to have stable and predictable environment. It is not possible switch development environment in the middle of project. In the past we have done many project with TI parts. What I noticed that support engineers at TI does not understand how embedded development at real word looks like. Unfortunately similar kind of  the not-understanding see at ST side as well. Before you will say that I don't understand how technical support should look like, you can check TI e2e forum where I am between top contributors (~2k7 posts).

Regards,

Jan

[Bubbles]

Hi @JDosp.1,

I said no development, which means no new features. In case there is a vulnerability that's not development, but support of the existing solution, which continues. But adding HW AES is not addressing vulnerability, it's new feature development.

And as you pointed out earlier, it's not trivial.

BR,

J

[JDosp.1]

Hi Bubbles,

All X-CUBE-AZRTOS-* packages contains multiple critical security vulnerabilities which are know for two months. But still no update from ST side or at leat ST PSIRT report. If support continues, what is roadmap to fix this vulnerabilities?

Regards,

Jan

[Jocelyn RICARD]

Hello @JDosp.1 ,

The CVEs on Azure RTOS were shared with ST in November.

Managing vulnerabilities takes time and some are more important than others so are addressed with higher priority.

Normally, all Azure RTOS CVEs are fixed in Azure RTOS 6.4.0.

• Azure RTOS 6.4.0 is available on Eclipse GitHub since January 2024. 
• Azure RTOS 6.4.0 will be available on ST GitHub in 24Q1 (ST flavor).
• X-CUBE-AZRTOS-H7 V3.3.0 update with Azure RTOS 6.4.0 is planned in 24Q2. 

I hope this answers your question

Best regards

Jocelyn

[JDosp.1]

Hi Jocelyn,

Thank you for sharing information about plans for mitigating security vulnerabilities at X-CUBE-AZRTOS-* packages.

I have last question. Does ST have somewhere document describing security policies at software and hardware meaner? At ST PSIRT web I haven't found anything like that. At ST webpages I found only privacy policy which does not cover this topic.

Thanks for answer

Jan

[Clement7]

Hello,

I'm facing the same issue on NetX but on STM32MP13 Bare Metal project. (I tried on the H7 and the result is identic. My application needs to transfer large data over HTTPS connection so I need AES GCM.
Did you get the hardware acceleration to work?

Thank you for your help.

Regards

[JDosp.1]

Hi Clement7,

Unfortunately I was not able move forward this topic because my knowledge of cryptography is not such strong. I have discussed this topic at NetX git, and then I realised that proper implementation of hardware is not quick task. It is easy to ends with the security vulnerability, if things are not implemented properly. Test datasets need to be carefully selected to cover all possibilities. Hard to imagine that someone else than manufacturer can do this.

But if you try by yourself, I think best start-point is Renesas implementation of hardware cryptographic accelerators. Unfortunately Renesas AES driver and ST HAL have different approaches. Main issue is with data alignment and padding, when you implementing zero-copy approach. But if you will be able implement this, I can do some validation tests.

Jan