cancel
Showing results for 
Search instead for 
Did you mean: 

Provisioning by User Code

martinhaefner9
Associate II

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.
10 REPLIES 10
Jocelyn RICARD
ST Employee

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

 

 

 

 

 

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 

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

 

Hi @Jocelyn RICARD 

thanks again. Got the provisioning struct out of the docs.

For the provisioning in an H57 device, does the AES initialization vector has to have a special value, or is anything allwed ?

My bootloader is able to get some code by download. So if I know what to do, I can regress the devices.

 

Thank you and kind regards

Hello @martinhaefner9 ,

I'm sorry, I didn't have time yes to prepare the example.

The IV is fixed. You can have a look the the OBK_Flash_WriteEncrypted function.

To perform the regression you just need to change product state to REGRESSION. For this , you need to be in HDPL1. So, if your bootloader changed the level of the application it will not work.

But I would advice waiting for the full example :)

Best regards

Jocelyn

 

Hi @Jocelyn RICARD ,

thanks again. That clarifys some questions.

But there are more questions. Just for my understanding.

When I do data provisioning by STM32CubeProgrammer, the generated obk coming from the TrustedPackageGenerator, is encrypted while flashed to the obk area ?

When i do the same by code, i have to encrypt my blob, too. 

The initialization vector is clearly pointend out by the example you send.

But which key is used ? Is it the DHUK  ?

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

 

Thanks again and kind regards.

 

Jocelyn RICARD
ST Employee

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

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 

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