Hello,
How mbed tls should be compiled so that it uses STM32F437 (or STM32F439) hardware cryptoengine for AES, (3)DES and SHA?
Is there some kind of configuration flag/define?
I assume that there’s already support for STM32F437/STM32F439 hardware acceleration and there’s no need to implement it by myself.
Is there need to use mbed os in addition to get hardware acceleration?
Or is the correct way to use polarSSL version provided by STMicroelectronics? This is fairly old (mbed tls v2.6.1)?
Hi Sami,
There isn’t a need to use Mbed OS to get hardware acceleration, but it’s the most straightforward way. In Mbed OS, we (by default) enable all hardware acceleration available for your chosen target. For TARGET_STM32F437xG and TARGET_STM32F439xI, hardware acceleration is available in Mbed OS for AES, SHA1, SHA256, and MD5 (but not DES).
In general, hardware acceleration is enabled through the use of the ALT configuration options. For AES, SHA, and DES, these are: MBEDTLS_AES_ALT, MBEDTLS_SHA1_ALT, MBEDTLS_SHA256_ALT, and MBEDTLS_DES_ALT.
Enabling one of those options in your configuration file will cause Mbed TLS to look for source code implementing hardware acceleration support. Source files that implement the required functions need to be present (whether Mbed OS or not).
Regards,
Jaeden
Mbed TLS Team member
Hello,
So how much exactly I have to manually configure&enable and write code to get hardware acceleration to work with mbed tls (when using STM32F437/STM32F439)?
I assume that atleast I have to figure out correct implementation to functions that are enabled by those MBEDTLS_x_ALT defines. Is this correct? Or is there some easier way?
Does Mbed OS make this configuration needless and somehow it configures mbed TLS to use those _ALT interfaces automatically?
PS. I’m not familiar with mbed OS, but I have tried mbed TLS.
Hi Sami,
You can see how Mbed OS selects to use hardware acceleration in the configuration file used with STM32F439. You can also see the hardware acceleration code provided by ST to Mbed OS. With both implementation files and the configuration file all included in your build, Mbed TLS will select to use the hardware acceleration provided by the implementation files.
It’s up to you to ensure you have a hardware acceleration implementation in your build. After that, you can opt-in to using it by adding MBEDTLS_AES_ALT , MBEDTLS_SHA1_ALT , MBEDTLS_SHA256_ALT, or MBEDTLS_DES_ALT to your Mbed TLS configuration file. Mbed TLS does not provide any ALT implementations on its own (the hardware acceleration implementation comes from ST or Mbed OS or elsewhere).
Regards,
Jaeden
Mbed TLS Team member
Hello,
Thank you for the advice and clarification!
I’ll study those.
Hello again,
Tried to run mbedtls_aes_self_test() using hw acceleration with STM32F437, but self test fails immediately in the ecb mode test. If I use the mned tls default software aes implementation (MBEDTLS_AES_ALT not defined), then the test is run succesfully).
So how this should be used/configured to get it working?
I uses (as suggested) aes_alt.c/.h files from mbed os (https://github.com/ARMmbed/mbed-os/tree/master/features/mbedtls/targets/TARGET_STM/TARGET_STM32F4).
It’s a little confusing that with STM32F439 hw acceleration is not enabled (https://github.com/ARMmbed/mbed-os/blob/master/features/mbedtls/targets/TARGET_STM/TARGET_STM32F4/TARGET_STM32F439xI/mbedtls_device.h), but with STM32F437 (https://github.com/ARMmbed/mbed-os/blob/master/features/mbedtls/targets/TARGET_STM/TARGET_STM32F4/TARGET_STM32F437xG/mbedtls_device.h) hw acceleration is enabled.
As far as I understand, both of these MCUs uses same crypto hardware.
If sha256_alt.c/.h is used (get from here: https://github.com/ARMmbed/mbed-os/tree/master/features/mbedtls/targets/TARGET_STM), then mbedtls_sha256_self_test() is run succesfully (and got about 10x faster execution time than with mbed tls default software sha256 implementation; no MBEDTLS_SHA256_ALT defined). So I assume that the environment is probably correctly configured.
I have used mbed tls version (which is provided by ST’s CubeMX tool).
#define MBEDTLS_VERSION_NUMBER 0x020B0000
#define MBEDTLS_VERSION_STRING “2.11.0”
#define MBEDTLS_VERSION_STRING_FULL “mbed TLS 2.11.0”
mbed OS forum had a lot of conversation about STM32F437/STM32F439 hw acceleration status, but final conclusion wheter hw acceleration works or not with STM32F437/STM32F439 is not clear to me.
So can you help me?
PS. Target is to use (if hw acceleration is fast enough) DTLS with AES and SHA256.
I tried to update mbed TLS. Result is similar. Hw acceleration with AES (ECB test is the first and the first fails) doesn’t work.
Version information from mbed tls library used.
#define MBEDTLS_VERSION_NUMBER 0x02100300
#define MBEDTLS_VERSION_STRING “2.16.3”
#define MBEDTLS_VERSION_STRING_FULL “mbed TLS 2.16.3”
Hello,
I studied this little further. For now it seems that there’s problem with context store/restore: just started with first selftest (AES-ECB) and got it working somehow, but I think that my current solution doesn’t work properly, if some other encryption/decryption is done between successive calls.
Similar issue appears with the next AES test (AES CBC). I assume that all AES accelerations are affected.
E.g.: HAL_CRYP_AESECB_Decrypt @ stm32f4xx_hal_cryp.c:
…
/* Check if initialization phase has already been performed */
if(hcryp->Phase == HAL_CRYP_PHASE_READY)
Just skipping this after first round, fixes this selftest with AES-ECB, but in general correct context must be saved and restored.
So does someone already have corrected implementation for this?
Hi @sapeku
As you referenced, you can look at the AES implementation on Mbed OS, and tweak the relevant context to your platform.
You can take take the implementation of aes_alt and similar implementation of the hal layer,to save context between sessions.
Regards,
Mbed TLS support
Ron
Hello,
I think that there is a couple of problems.
mbed tls doesn’t support STM32F437/F439 hw crypto engine, but just uses sw implementation.
mbed os might have earlier supported hw crypto, but about a month ago, there were not working combination of mbed os (incl. mbed tls + stm32f4 hal library + modified sha256_alt/aes_alt + enabled hw crypto support). For me, the problem shows as failing sha256/aes selftest when enabled hw crypro (the x_ALT configuration options).
In the mbed os forum, there is (from my point-of-view) misleading information due that there where discussion about STM32F439 hw crypto support (broken), but STM32F437 is working: as far as I understand, both of these MCUs use the same hw crypto (difference between MCUs is lack of Ethernet MAC); other of them had some hw support enabled (but not working) and the latter one (F439) had all the hw support disabled in mbed os package.
I got the selftests (sha256, aes (ecb, cbc, ctr)) to work, but due to lack of time, I hadn’t yet been able to test it with mbed TLS (DTLS) due that some of the fixes that I made, needs to be moved to aes_alt.c file (away from aes.c).
The problem was that latest (v1.24.1) ST’s HAL driver interfaces and mbed TLS (+x_alt implementations) are not compatible. There were at least two problems: byte endian of keys (BigEndian vs. LittleEndian) and data format/pointers (uint8() vs. uint32()).
Due to endian problems, selftest might be better, if they use some other key than plain 0.
But I hope that I manage to get this working (when I have again time to study this little further).
Unfortunately the aes ccm/gcm hw support is still missing… ST’s HAL library has some interface to that too, but requires extra work to implement them (similarly to sha256_alt/aes_alt)…
Hi @sapeku
mbed tls doesn’t support STM32F437/F439 hw crypto engine, but just uses sw implementation.
Correct; Mbed TLS is released with sw implementation only, without any external driver support. It is up to the developer \ target manufacture to supply the hw accelerated driver version(e.g. the _alt version)
Unfortunately the aes ccm/gcm hw support is still missing… ST’s HAL library has some interface to that too, but requires extra work to implement them (similarly to sha256_alt/aes_alt)…
Yes, there is a need for extra work, if you want to call directly hw CCM\GCM.
However, not the these module use a symmetric alogrithm within(such as AES), and if this was accelerated, the AEAD versions would be partly accelerated as well.
Regards,
Mbed TLS Support
Ron