[STM32H563] NetX Duo with hardware accelerators

[Sander_UP]

Hello!

I have an MQTT project using NetX Duo, which publishes MQTT messages to a remote server. But, before it can do that, a secure connection must be established using TLS v1.2, which takes about 18-20 seconds (checked while debugging and stepping through the connect function). So, I wanted to find a way to make that process faster.

I found this post on the forums, here (porting Mbed TLS to the STM32H5 platform with hardware crypto acceleration
). But this raised some questions for me. Firstly, how to exactly implement this in the NetX Duo's TLS setup (if even possible)? And secondly, I am missing the AES option in the CubeMX settings - is that correct or I am missing something? I only have PKA, HASH, RNG and GTZC options.

I checked the included files in the above linked post on how to port the mbedTLS, but was a bit overwhelmed as how would one implement it into the NetX Duo's TLS connection setup. I am using an RSA key(s) for the secure connection. I was hoping that someone might give some initial steps or even has an example of how they implemented and used it with NetX Duo.

[mbarg.1]

Before looking for the holy graal, try to understand basic of your problem.

Many process rely on NO-REPLY validation - that mean system has to send challenges and wait to see if anybody replies in order to validate, a reply choice bad, no reply choice good - an example: SLAAC.

TLS require access to remote resources, via network: on weak, slow or unreliable connections, system will wait some timeout before re-trying.

Computation overhead by CPU, can cause some milliseconds of CPU time, not seconds; obviously, if you have some near.real time process, it is preferrable to outsource.

Crypto code is very large, easy to corrupt: having tested code running cerified is always welcome, will shorten validation process and make you product more reliable. 

For 20 seconds delay, look at NetX code and choices you did - use DHCPv6 instead of SLAAC, try multiple IP addresses instead of waiting for timeput ... hardware solutions are great but will not help in this case.