Skip to main content
TVare.1
Associate III
November 28, 2023
Question

AES ECB initialization fails

  • November 28, 2023
  • 2 replies
  • 2741 views

Hi,

I'm trying to encrypt and decrypt in my device, running on a STM32H753, using AES ECB.

I'm initializing crypto like this:

 

 

hcryp.Instance = CRYP;
hcryp.Init.DataType = CRYP_DATATYPE_8B;
hcryp.Init.KeySize = CRYP_KEYSIZE_256B;
hcryp.Init.DataWidthUnit = CRYP_DATAWIDTHUNIT_BYTE;
hcryp.Init.pKey = AESKey256;
hcryp.Init.Algorithm = CRYP_AES_ECB;

 

 

 With following clocks:

 

 

 /* Enable CRYP clock */
 __HAL_RCC_CRYP_CLK_ENABLE();
 
 /* Force the CRYP Peripheral Clock Reset */ 
 __HAL_RCC_CRYP_FORCE_RESET();
 
 /* Release the CRYP Peripheral Clock Reset */ 
 __HAL_RCC_CRYP_RELEASE_RESET();

 

 

 

After that, I just call HAL_CRYP_EncryptHAL_CRYP_Decrypt and everything goes fine. At least in the first two devices I used.
When testing in more devices (same hardware, same firmware), I found many of them that were getting blocked inside HAL_CRYP_Encrypt. Debugging a bit, they are blocked in the actual encryption function CRYP_TDES_Process. It is the exact blocking point someone had already pointed out in this post: https://community.st.com/t5/stm32-mcus-security/hal-stm32f2-version-1-9-2-potential-locked-in-cryp-tdes-process/td-p/210046 
However, it should not even be in TDES function, as it should be AES. That's how I found that was is actually not working correctly is the initialization. Inside HAL_CRYP_Init, following piece of code is making no effect in the crypt handler:
 

 

 MODIFY_REG(hcryp->Instance->CR, CRYP_CR_DATATYPE | CRYP_CR_KEYSIZE | CRYP_CR_ALGOMODE,
 hcryp->Init.DataType | hcryp->Init.KeySize | hcryp->Init.Algorithm);

 

 
When debugging, HWs that work OK run that code as expected, changing values of the CRYP control register. However, in those devices with the problem, after this Modify_reg line I see that CR is all in 0.
 
Any ideas why this could happen? it bugs me the fact that it is actually working in some hardwares but not in others...
 
TIA, regards.
 
 
This topic has been closed for replies.

2 replies

TVare.1
TVare.1Author
Associate III
November 28, 2023

I've seen this post https://community.st.com/t5/stm32-mcus-security/how-to-enable-the-stm32h750vbt6-hw-crypto/td-p/165187 which seems to show the same problem. There, ST explains that there is a batch from 2020 with no cryptographic features.

From my side, it seems I have two different batches of microcontrollers:

1- STM32H753IIKb with date code 946 (2019 week 46?): these ones are working fine.

2- STM32h753IIKb with date code 133 (2021 week 33?): these ones not working, with registers in zero even after writing into them, as if clock was not initialized.

Did I just bump into another batch without crypto? how could I get a confirmation from ST?

Tesla DeLorean
Guru
November 28, 2023

Submit on Online Support Request via the ticket submission process.   https://www.st.com/content/st_com/en/support/support-home.html

Alternatively talk directly with your local sales office, or FAE supporting your account.

As I recall Pavel provided a means to check if the unit is enabled, or not. Begin enabled or not is likely a final test fuse, but could be a mask-set metal layer. The parts could also be counterfeit, or mismarked. You should share the trace codes on the packaging or reels with ST privately.

@STOne-32 @Billy OWEN 

Tips, Buy me a coffee, or three.. PayPal VenmoUp vote any posts that you find helpful, it shows what's working..
Tesla DeLorean
Guru
November 28, 2023

Some of the other threads / links are borked..

This is the one with Pavel's code   https://community.st.com/t5/stm32-mcus-security/stm32h750vbt6-access-crypt-registers-all-read-back-zero/td-p/204834

Tips, Buy me a coffee, or three.. PayPal VenmoUp vote any posts that you find helpful, it shows what's working..
STOne-32
Technical Moderator
November 28, 2023

Dear @Tesla DeLorean ,

Thank  you for the insight,  @TVare.1 I confirm that we had in second half of 2020 a test program issue at our factories, during manufacturing, leading to cryptographic feature disabled (CRYP and HASH). In case these cryptographic features would be used in final application, functionality failure will be visible immediately (100% failure rate) as you have seen with 0x000..

We sent a Quality Alert to all of our customers/distributors at that time by December 2020 and then Issue is fixed at our Factories, To be very specific not all parts are impacted by few Lots at specific factory where date code is from 2020 Week 22 to 2020 Week 47 . 022 to 047 may be impacted.

In case customer application would require these specific cryptographic features and to avoid any customer manufacturing burden, ST recommends recalling all unused impacted material and will issue a return material acceptance (RMA) accordingly, so please to go in touch with your local distributor or ST sales Offices. Our customers not using theses features, they will not see such impact.

Now it seems your Date code is different and from 2021, we need to check it if coming from ST and may be the issue happened again but we are not aware of it so far.

Hope it is more clear now.

Ciao,

STOne-32.