STM32F777 - CRYP Coprocessor AES GCM tag does not match mbedTLS AES GCM tag

[brandongmiche]

Hello,

I am working on a project using mbedTLS and Keil MDK to make an HTTPS server running on an STM32F777. To speed up encryption/decryption, I am trying to make use of the CRYP coprocessor (mostly focusing on speeding up AES GCM calculations). My implementation is based on the example given here: https://github.com/STMicroelectronics/STM32CubeL5/tree/master/Projects/STM32L562E-DK/Applications/mbedTLS/Crypto_Selftest.

However, when I try to run with my alternative AES GCM implementation, the CRYP coprocessor does not calculate the same tag as mbedTLS. This causes the SSL handshake to fail.

I've attached my files for the GCM alternative implementation here. Am I missing something with the way I'm presenting my data?

[thierry BINIGUER]

Hello,

I would suggest to test with a Plaintext placed :

- in a certain memory boundary (even address divisible by 4).

- with a buffer size having extra bytes so that it matches with a multiple of words.

Thierry

[pborto]

Hello brandongmiche,

I'm currently facing the exact same problem you described.

I ported this official implementation template for F4 series to STM32F777.

During handshake I get MBEDTLS_ERR_GCM_AUTH_FAILED error inside mbedtls_gcm_auth_decrypt function.

Have you come to a solution?

Thanks,

Paolo

[Jocelyn RICARD]

Hello,

You have an alternate implementation of aes GCM here:

STM32Cube_FW_L5_V1.5.0\Projects\STM32L562E-DK\Applications\mbedTLS\Crypto_Selftest\Src\gcm_alt.c

This could give you some good imputs.

In the past I remember one issue related to the unalignment of the buffer in update requests.

It is important to always provide 16bytes to encrypt or decrypt. Only last bytes of buffer can be unaligned. In STM32F7, you can check chapter 23.3.8 CRYP Stealing and data padding of RM 0410.

Best regards

Jocelyn

[vk-tg]

Hi Paolo

I am also experiencing the same issue. Have you managed to figure it out ?

Thanks,

VK

[pborto]

Hi vk-tg,
Unfortunately I was unable to identify the problem.
I referred, as suggested, to the instructions in the RM 0410 manual.
I then checked the correctness of the operations both in the gcm_alt.c module and in the ST drivers, but apparently the sequence of operations seems correct.
At this point it would be useful to have further support in this regard since it seems that many people are complaining about the same problem.