Our application connects to a server in the cloud and recently we migrated from a proprietary AES256 encryption to Mbed TLS based solution.
By default Mbed TLS does NOT offer out-of-the-box hardware acceleration for AES, MD5, SHA etc. By accident I was triggered to look at Mbed OS 5 that includes Mbed TLS as one of its features. In the targets directory of the mbed TLS feature within Mbed OS, I’ve found support for hardware acceleration that uses the STM32 Crypto and Hash peripherals (provided by STM32F7xx_HAL_Driver). In my application this works fine.
While using the cipher suite TLS-ECDHE-ECDSA-WITH-AES-256-GCM-SHA384, I was wondering why there is only a aes_alt.c implementation and not a gcm_alt.c implementation to support AES-GCM hardware acceleration by STM32 crypto peripheral (these alternative implementations have a STmicroelectronics copyright notice).
Searching the Mbed OS code base for AES, I only found the AES-ECB and AES-CBC modes use the HW STM32 crypto.
See stm32f7xx_hal_cryp_ex.h that offers the following interfaces for AES-GCM support by HW:
HAL_CRYPEx_AESGCM_Encrypt();
HAL_CRYPEx_AESGCM_Decrypt();
HAL_CRYPEx_AESGCM_Finish();
I would expect performance benefits if a gcm_alt module is implemented that uses the STM32 crypto peripheral for AES-GCM as well?
Is anyone already working or thinking about a gcm_alt implementation for STM32?
Hi Robert,
You are correct that the Mbed TLS library is NOT supplied with out of hte box hardware acceleration.
It does, however, supply means of easy porting to a hardware acceleration engine. See this article for more information. The alternative hardware accelerations implementations are supplied as part of Mbed OS.
The gcm_alt is intended for alternative implementation of gcm, which uses AES but is more than AES only. ( GMAC as well)
Without an alternative implementation for gcm, there will be some acceleration, because it still uses AES ( assuming you integrated the alternative AES ), however probably not as meaningful as the full alternative implementation for the GCM (depending on the implementation).
Regards,
Mbed TLS Team member
Ron
The alt_aes, alt_md5, alt_sha1 and alt_sha256 as provided in Mbed OS for hardware acceleration are integrated within my application and working fine with Mbed TLS on my STM32F777. Even date and time validation of the certificates is working well with my own implementations for time(), gmtime() and gmtime_r().
Furthermore I tried to make a full alternative implementation based on alt_aes but failed getting the gcm_selftest() up and running due to problems with the length of the initialization vectors of the test cases.
Nevertheless, as you already indicated, it is running with some acceleration at least due to alt_aes.
Until STmicroelectronics will also provide the alt_gcm.c/alt_gcm.h, I will stick to the current implementation.
Hi Robert,
I’m currently working with STM32F777 too, but only alt_aes is working.
I’ve ported this implementations of alt_md5, alt_sha1 and alt_sha256 to my project but I’m currently not able to get it working.
Could you please share what you had done to make it work?
