STM32F777 - CRYP Coprocessor not setting the key

[brandongmiche]

Hello,

I'm currently using an STM32F777 MCU with the Keil MDK. I want to run an HTTPS serer on this system, and I set up mbedTLS with Keil's network component (using the TLS_ECDHE_ECDSA_AESGCM128 cipher suite). By default, it takes around 6 seconds for a resource to load, so I tried adding in hardware acceleration using the CRYP coprocessor in the STM32F7. However, I ran into some issues with it.

AES GCM did not work, and when debugging my code it looked as though the AES key registers (CRYP_Kx{L/R}R) were not being set. Any time I would try to set them, the registers would report back that they were 0x00. Should I be able to see these registers set to the key that I am using, or are these blind registers? If they are blind registers, is there another way to verify that the AES key is being properly set in the CRYP processor?

Any help would be appreciated.

Thanks,

Brandon

[Tesla DeLorean]

Make sure the unit's clock is enabled in the RCC, and that you really have an F777 and not an F767

Perhaps try AES demo codes in CubeF7 for EVAL/NUCLEO's

[brandongmiche]

Both are verified. The chip is truly an STM32F777, and the CRYP clock is running (enabled with an __HAL_RCC_CRYP_ENABLE() call).

The other registers for the CRYP processor are being set correctly, it is just the key registers that don't seem like they're being set.

[brandongmiche]

Looking at the registers using STM32CubeProgrammer's register view, it says those registers are write only. I'm guessing I should not be able to read them back with a debugger. Is there another way to verify that the key is getting set properly?

[Tesla DeLorean]

In a general sense?

You could use a test pattern, with known plain and cipher texts.

You could CRC32 the plain text, and check that. If that's ahead of your data it would also be a random IV