OEMuRoT key update via STiRoT data-image update not initiated

[JC_Vdr]

I am evaluating STiRoT + OEMuRoT on an STM32H5F5J-DK using the STM32CubeH5 v1.7.0 package by following the ST documentation:

1. Security:OEMiRoT OEMuRoT for STM32H5 - stm32mcu
2. How to start with STiRoT_OEMuRoT on STM32H573 - stm32mcu
3. Getting started with STiRoT (ST immutable Root of Trust) for STM32H5 MCUs - Application note

The board can be provisioned and the following currently work correctly:
-  STiRoT starts successfully.
-  OEMuRoT starts successfully.
-  Secure and non-secure applications are authenticated and executed normally.
-  Application updates (swap mode) through the OEMuRoT flow are functional.

The next step is to confirm whether the OEMuRoT authentication and encryption keys can be updated after the board has already been provisioned, without reprovisioning the complete board. Test procedures as below:

1. Generate new OEMuRoT keys
   Using STM32TrustedPackageCreator (TPC), a new set of OEMuRoT authentication/encryption keys were generated through ‘OEMuRoT_Config_Keys.xml’
2. Generate the OEMuRoT configuration binary ‘OEMuRoT_Config_intermediate.bin’
3. Generate the ‘OEMuRoT_Config.bin’ by using TPC Image Gen through ‘OEMuRoT_ST_Settings_1.xml’
4. Generate the ‘OEMuRoT_Config.hex’ by using TPC Image Gen through ‘STiROT_Data_Image.xml’
5. Enter Bootloader from the non-secure application menu via TeraTerm
6. Connect via STM32CubeProgrammer and download the ‘OEMuRoT_Config.hex’ to the dev board. Memory address to be downloaded is 0x81E6000 which is correct (refer to the OEMuROT data download slot in the below diagram)
7. After resetting the board, the existing application still passed authentication / integrity verification and started normally

At this point, I would expected the new OEMuRoT key configuration have been installed into HDPL2 OBKeys and the existing application to fail verification if the authentication/encryption keys had actually changed.

Additionally, when inspecting memory at 0x081E6000 via CubeProgrammer, the downloaded data image is still present after reset. I would expect the STiRoT data-download area to be erased after the installation attempt, whether installation succeeded or failed.

I have also tried to recompile the NS app with the new key and downloaded the generated ‘rot_tz_ns_app_enc_sign.hex’ into the board. However, it could not pass the verification stage and was reported invalid. It looks like the keys are still old which failed the authentication process on the newly encrypted / signed NS app.

Am I doing anything wrong in the below steps? Could you please confirm if this is possible to update the OEMuRoT authentication and encryption keys after provisioning? Your help is very much appreciated.

 

The following projects have been used for my testing:

-  Projects\STM32H5F5J-DK\Applications\ROT\OEMiROT_Boot
-  Projects\STM32H5F5J-DK\Applications\ROT\OEMiROT_Appli_TrustZone
-  Projects\STM32H5F5J-DK\ROT_Provisioning\STiROT_OEMuROT

 

 

 

[Jocelyn RICARD]

Hello ​@JC_Vdr ,

This is a known issue, and it is related to a missing alignment of the OBK The fix should come in next release.

I join 3 files that should help you make this update work

The low_level_obkeys.h adds necessary alignments

OEMuROT_Config_Keys.xml also adds 16 bytes alignment for AES encryption

STiROT_Data_Image.xml generates the well formated data_enc_sign.hex file containing the new OEMuROT keys.

The official solution that will be probably delivered in November may differ a bit, probably regarding file names that may be confusing but should result in same behaviour.

Also, on my side I tested it on STM32H573 only but I don’t see why it wouldn’t work on STM32H5F5

Best regards

Jocelyn

[JC_Vdr]

Hi ​@Jocelyn RICARD ,

Thanks a lot for your quick reply and very much appreciated.

I have recompiled the OEMiROT_Boot project using the new ‘low_level_obkeys.h’ and used the new ‘OEMuRoT_Config_Keys.xml’ to create a new ‘OEMuRoT_Config_intermediate.bin’ (that leads to an updated ‘OEMuRoT_Config.obk’ during the provisioning steps). The provisioning was completed without an error. However, the OEMuROT was not started normally after resetting the board and I can only see the below message on TeraTerm.

[INF] TAMPER Activated

I then tried to revert all the changes (used the original .h and .xml) but the result is the same. I could not see the OEMuROT and NS app running normally as before. It also stopped after showing ‘TAMPER Activated’.

Could you please advise what I might have done wrong and how could I recover from this situation?

Do we need to update the ‘STiRoT_Data.obk’ and ‘OEMuRoT_Data.obk’ when the new ‘low_level_obkeys.h’ is used?

My ROT and ROT_Provisioning directories are attached for inspection.

Thanks again!

[Jocelyn RICARD]

Hello ​@JC_Vdr ,

Yes, I missed one file that needs a change : OEMuROT_Data.obk 

This file is not supposed to be regenerated as it contains only zeros but the base address is indirectly impacted by the low_level_obkey.h modification.

I join this binary file. The difference is only the base address that moved 16 bytes  further: 0x0FFD0A60 instead of 0x0FFD0A50

Best regards

Jocelyn

 

 

[JC_Vdr]

Hi ​@Jocelyn RICARD ,

Thanks for your help and the OEMuROT and NS app can run as expected now. The STiROT data image update seems to work after the newly generated ‘data_enc_sign.hex’ is downloaded to the board. The existing apps in primary slot could not pass the authentication which is expected too. See below log from TeraTerm.

[INF] TAMPER Activated
[INF] Flash operation: Op=0x0, Area=0x0, Address=0x0
[INF] Starting bootloader OEMuROT 33.2.3.4.5...
[INF] Primary image: magic=good, swap_type=0x1, copy_done=0x3, image_ok=0x1
[INF] Scratch: magic=unset, swap_type=0x1, copy_done=0x3, image_ok=0x3
[INF] Boot source: primary slot
[INF] Swap type: none
[INF] Primary image: magic=good, swap_type=0x1, copy_done=0x3, image_ok=0x1
[INF] Scratch: magic=unset, swap_type=0x1, copy_done=0x3, image_ok=0x3
[INF] Boot source: primary slot
[INF] Swap type: none
[INF] Starting validation of primary slot(s)
[INF] verify counter  0 1000000 1000000
[INF] counter  0 : ok
[ERR] Image in the primary slot is not valid!
[ERR] Unable to find bootable image
[INF] Jumping to bootloader
[INF] Disconnect COM port if used by bootloader

After disconnecting the COM in TeraTerm and tried to connect via CubeProgrammer to download the two app images (‘rot_tz_s_app_enc_sign.hex’ and ‘rot_tz_ns_app_enc_sign.hex’), the following error is reported and stopped me proceeding. I was using the same UART connection configuration for uploading the ‘data_enc_sign.hex’ to the board before. Could you please share your insight here? Thanks again.

 

[Jocelyn RICARD]

Hello ​@JC_Vdr ,

I double checked this use case on STM32H573 and it worked fine.

So, I checked on STM32H5F5 and I can reproduce your issue.

This can be reproduced outside your specific keys update, by just using the user button to force the jump to the system bootloader from OEMuROT during reset.

So, issue is located in OEMuROT code used to jump to the bootloader.

I will raise an internal ticket for that.

A rapid debug shows that it fails before jumping

You can comment these lines in the boot_hal.c (from 1176 to 1180)

static void tamper_loader_cfg(void)
{
  /* configuration stage */
  if (uFlowStage == FLOW_STAGE_CFG)
  {
    /* TAMP */
    TAMP->SECCFGR  = TAMP_INIT_SECCFGR_VAL;
    FLOW_CONTROL_STEP(uFlowProtectValue, FLOW_STEP_TAMP_L_EN, FLOW_CTRL_TAMP_L_EN);
  }
  /* verification stage */
  else
  {
    uint32_t tamp = TAMP->SECCFGR;

//    if (tamp != TAMP_INIT_SECCFGR_VAL)
//    {
//      Error_Handler();
//    }
//    else
    {
      FLOW_CONTROL_STEP(uFlowProtectValue, FLOW_STEP_TAMP_L_CH, FLOW_CTRL_TAMP_L_CH);
    }
  }
}

#endif /* MCUBOOT_EXT_LOADER */

 

This is just a workaround.

Best regards

Jocelyn

 

 

[JC_Vdr]

Hi ​@Jocelyn RICARD ,

Thanks for your suggestion and I can finally manage to get the Bootloader connection working with CubeProgrammer after implementing the workaround in OEMuROT. After the newly generated 'rot_tz_ns_app_enc_sign.hex' and 'rot_tz_s_app_enc_sign.hex' are downloaded to the dev board and restart, the NS app can be started without issue.

I will wait for the formal fix in the future version of the H5 firmware package for the above issue.

Thanks for your support and very much appreciated.