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.

[Mikey]

I used AEC GCM acceleration with the STM32H753 and mbedTLS. Following this thread I also based it off the L5 cube gcm_alt.c implementation. I needed to apply the patch suggested by lukasostendorf here to get it to work - not sure if this could be related to your issue?

There is still a threading issue I'm looking into when using multiple sockets, but for a single socket it seems to work fine.

(Edit: For interest, throughput improvement was x4, just using the cryp with polling)