Provisioning by User Code

[martinhaefner9]

Hi,

is there a possibility to do the complete chain to product state "closed" by non secure user code ?

I have a custom bootloader which usually did a set of the old RDP Level.

Now, with a STM32H57 device we have to use the new product state.

 

I'm able to set the state to provisioning. But when i use 

RSSLIB_PFUNC->NSC.DataProvisioning i end up in a hard fault.

 

I tried to set the provisioning data by ST Cube programmer later on which succeeded. But unfortunately i can not regress to open because the password is wrong.

 

Any hints about that ?

 

Thanks in advance.

[Jocelyn RICARD]

Hello @martinhaefner9 ,

yes it is possible to perform provisioning through firmware.

On STM32H573, you need to make sure your device is closed to do the provisioning of the DA keys.

Reason is that DA configuration has to be encrypted using the DHUK, and this key is not available in open state.

To perform the provisioning you can use the helper function provided  in STM32Cube_FW_H5_V1.3.0\Projects\STM32H573I-DK\Applications\ROT\OEMiROT_Boot\Src\low_level_obkeys.c

OBK_Flash_WriteEncrypted.

The sequence should be

1) First start of firmware: Detect it is still in open state : Change product state to PROVISIONING and immediately to CLOSED and launch system reset to have this new product state taken into account

2) Second start of firmware: Detect product state is CLOSED. Check DA provisioning in OBKey: not present. You need to have the obk file somewhat hardcoded in your firmware to be able to provide the input buffer to the obk write function. Once obk written, you are done with the DA provisioning

The best would be to provide you an example but I don't have it right now and not much time available.

I'll try to provide something by next week

Best regards

Jocelyn

 

 

 

 

 

[martinhaefner9]

Hi @Jocelyn RICARD ,

thanks for the really qualified answer, appreciate that.

That brings up some other questions.

I had a look into the obk binary, as i can see there is my passwords sha256 in. I already have this constant available in my code. 

Is there a description of the obk structure somewhere(to generate that in code). Blame on me if i had not read the docs carefully enough.

Another thing, does the content have to be encrypted with AES ?

We use some kind of a custom generic Bootloader which also has to run on H56x devices.

 

And last, am I able to regress my test devices where the provisioning failed with some user code ?

 

Thanks again!

Martin 

[Jocelyn RICARD]

Hello @martinhaefner9 ,

you will find all information in AN6008 : Getting started with debug authentication

The content needs to be encrypted in the OBK if you are using the STM32H573. There is no choice here. But the code to do it is provided as I said in my first post.

In case you have same code that addresses both STM32H573 and STM32H56x, then you have to add a condition and encrypt only on STM32H573.

To do this, you can read content of address 0x40022428. If it is 0 you have a STM32H573, otherwise it is not 0.

This address can be found in UM3125 STM32H573xx security guidance for SESIP 3 Certification

 

For your device where provisioning failed you may regress it if you have a bootloader that can download code.

Best regards

Jocelyn

 

[Jocelyn RICARD]

Hello @martinhaefner9 ,

The encryption of the obk is done by some code inside the chip in the system flash when programmer requests the provisioning with obk file as parameter.

The encryption is done using a derivation of the Hardware Unique Key. This derivation is specific to HDPL1 and epoch counter that is increased at each regression.

This is a normal AES CBC encryption.

 

"Is it right that the SAES wraps the DHUK and that one can be shread to AES ?"

No this is not working that way.

Principle of shared key is 

1) you wrap (encrypt) an AES Key using DHUK in shared mode. This wrapped key is stored in the device. In OBK for instance.

2) Later you provide this wrapped key to the SAES and request unwrap in shared mode targeting normal AES IP. 

The SAES will decrypt the wrapped key using DHUK and sent it to AES key register through a private bus.

So, you can sharing a key with "non secure" AES IP only when using wrapped keys.

DHUK never goes out of Secure AES.

Best regards

Jocelyn

[martinhaefner9]

Hi @Jocelyn RICARD 

to become concrete:

To encrypt my obk blob inside my bootloader i can use the saes and configure it with KEYSEL: 0x01 (DHUK) take the epoch counter of HDLP1 (SBS_EPOCHSELCR = 1) in account, wait until the key is successfully loaded and then encrypt my obk blob before writing it to the OBK section( 0x0FFD0100 ) ?

Thanks again and sorry for my impatience, we are close to a release date.

Kind regards

Martin 

[Jocelyn RICARD]

Hello Martin,

I started creating the example and I get an unexpected issue that encryption made by firmware is not recognized by DA.

I'm working with experts to understand how to get the right encryption. Apparently this is a known issue.

By the way, in your case with TrustZone disabled you should select epoch NS : SBS_EPOCHSELCR=0

I'll come back hopefully with a working setup

Best regards

Jocelyn

 

[Jocelyn RICARD]

Hello @martinhaefner9,

I confirm that today, with STM32H573 you cannot provision the Debug Authentication through the firmware when TrustZone is disabled.

The reason behind is that DA is encrypted in secure state when you use the provisioning process through programmer.

As your code runs with TZ disabled in non secure state, the derived key generated by DHUK is not the same.

This issue is fixed on more recent STM32H533. It will also be fixed on STM32H573 but on next cut but it is not planned yet.

Here are the possible solutions I can think of:

1) Use the "standard" provisioning process provided by programmer. This provisioning is now supported by many third party programmers. This would be the less impacting for your firmware but depends on actual support by your programming tool.

2) Enable TrustZone. In this case, you will need to make adaptations to your firmware. Either you leave all your firmware on secure side or Secure + non secure

• In case of one secure application, every peripheral you are using should be allocated to secure
• In case of Secure + non secure you will have to manage the provisioning in the secure application and jump to the non secure application that is your firmware. 

I think the first solution : full secure is the easiest way to go. With such solution, the DA encryption by the firmware will work because it will use same DHUK as the one used when launching regression.

3) Use STM32H563: This chip does not use encryption, so no issue. But I guess you are using STM32H573 for its hardware cryptography capabilities

4) Use STM32H533: Here it depends if your firmware first inside 512 KB flash which I guess again is unlikely.

 

Best regards

Jocelyn

 

[martinhaefner9]

Hi @Jocelyn RICARD 

thanks for the clarification.

So I deciced to go for having a secure application which will do the provisioning and then jump to the non secure app.

Unfortunately i struggling enabling TZ in the user option bytes.

Are there any steps to do beside/before ?

Device is in non secure "Open" mode.

Thanks in advance

[martinhaefner9]

Ignore my last question please, that was an failure done by myself

[martinhaefner9]

@Jocelyn RICARD am I right if i have enabled TZ i have to use DA by certificates ?

[Jocelyn RICARD]

Hi @martinhaefner9 ,

Yes you get it right.

TZ Disabled: only password possible, and only regression can be triggered using DA

TZ enabled: only certificates possible: Regression/Partial regression/Debug reopening can be triggered

Best regards

Jocelyn