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

[Bubbles]

Hi @JDosp.1,

I believe your deduction is correct, but I don't know about any planned update.

What seems to the the problem? Is the encryption result incorrect or is there a crash?

BR,

J

[JDosp.1]

Hi Bubbles,

That is sad that there are no plans for hardware acceptilation for NetX secure for STM32 like have Renesas for RA family. I think this is missed opportunity.

Software implementation of cryptography from NetX secure works but performance is not optimal. Cryptography using CRYP peripheral is at least 10x faster. From this reason make sense to use CRYP peripheral for TLS acceleration. I have done some simple comparison with AES CTR mode software vs CRYP peripheral. Results are similar like results at CycloneCRYPTO Benchmark webpages.

Regards,

Jan

[Bubbles]

Hi @JDosp.1,

I know what's the performance difference between SW and HW implementation. It's just that the example is a generic thing, supposed to run on most HW. It's then up to the user to adapt and optimize it. And in case of replacing SW AES with HW accelerated one, that's usually a trivial matter.

BR,

J

[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

[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