AES-128-CTR using SAES through MCUboot is slower than software on STM32H533 — is this expected?

[parato]

Hello,

I am evaluating cryptographic performance for a secure boot using a NUCLEO-H533RE board and the OEMiRoT example from STM32CubeH5.

I compared two AES-128-CTR implementations:

• Software: mbedtls_aes_crypt_ctr().
• Hardware-backed: bootutil_aes_ctr_encrypt() using SAES.

The mean encryption times are:

Input size	Software	SAES-backed implementation
32 bytes	10.55 µs	29.46 µs
256 bytes	76.70 µs	222.88 µs
1024 bytes	303.50 µs	886.02 µs

 

For an academic comparison, is it accurate to describe this result as “software AES-CTR versus SAES ECB with software CTR and driver protection overhead”?

 

Thank you!

[Jocelyn RICARD]

Hello ​@parato ,

As you may see in the implementation, the AES CTR is implemented through AES ECB

You have a flag that enables usage of AES CTR (CRYPTO_AES_CTR_HW_SUPPORTED) that needs to be enabled.

I’m not 100% sure it is fully functional in all cases but I could test this on H573 without issue.

Another thing you may have seen is the implementation of bootutil_aes_randomize_key_instance that is a countermeasure against side channel attack.

Combination of AES ECB + this randomization is very impactful for performance. Use AES CTR directly, randomization is far less impacting.

Last point, the implementation uses secure AES IP (SAES) that implements counter mesures against side channel attack.

The usage of SAES in this case is important for this reason.

Usually performance of firmware update is not critical.

So, just try enabling CRYPTO_AES_CTR_HW_SUPPORTED, you should see much better performance

Best regards

Jocelyn

[Jocelyn RICARD]

One small point to be added: if you enable the flag please also change CRYP_IVCONFIG_ONCE by CRYP_KEYIVCONFIG_ALWAYS to support the swap case.

 

[parato]

Thanks Jocelyn.