AES ECB initialization fails

[TVare.1]

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_Encrypt & HAL_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.

[TVare.1]

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]

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 

[Tesla DeLorean]

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

[STOne-32]

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.

[TVare.1]

Thanks all for the answers.

Indeed I checked Pavel's code in my main, and it is consistent with my description. In those devices from 2019 it works fine, but when used in 2021 uCs it returns false.

It happens both for HASH and CRYP, for which I adapted like this:

// Test if the STM32H7 crypto is actually working,
// so this is H7 variant with crypto (ex. H753 vs H743)
// Check that CR regster of HASH or CRYP holds written value
bool H7_hw_crypto_test()
{
    // Test if HASH->CR is writable
    __HAL_RCC_CRYP_CLK_ENABLE();
    HAL_Delay(5);
    CRYP->CR = 0;
    __DSB();
    CRYP->CR = 0x20; // set HASH_CR_DATATYPE=HASH_DATATYPE_8B
    __DSB();
    uint32_t u = CRYP->CR;
    bool y = ((u & 0x30) == 0x20);
 
    if (!y) {
    __HAL_RCC_CRYP_CLK_DISABLE();
    }
    return y;
}

I'll continue in private with @STOne-32 to check the trace codes. Thanks!