Product state

1. What is new product state

The product lifecycle is used to control the product security configuration. It allows the activation of the platform security mechanisms. A new lifecycle is introduced to the latest microcontrollers, based on a new state machine with an updated set of rules.

1.1. New product lifecycle

A new product lifecycle is being introduced to the STM32H5 family, to bring added flexibility to product manufacturing and maintenance.

The new product lifecycle includes the following phases:

- Development phase, offering full debug capabilities to the developer.

- Provisioning phase, the main asset areas are protected (no longer accessible)

- Final phase, the product is in the field.

- Maintenance phase, including field return management.

During the product life, the solution must guarantee that the ROT (Root Of Trust) and user assets are never disclosed.

This must be true for all four phases stated above.

The new product lifecycle lists all the product states:

Information

When TrustZone® (TZ) is not proposed, the TZ-Closed does not exist.

Information

This simplified version does not show the debug authentication part (regressions and debug reopening). The complete version is available in the dedicated debug authentication section.

Warning

The debug authentication configuration (DA-config) must be provisioned in provisioning state.

1.2. Up to three parties

In the development and provisioning phases, the product lifecycle allows up to three parties to develop the same product.

Different third parties means that for development and provisioning, the product can be set to protect (isolate) the different parties. This means three different responsibilities, and potentially three different keys (Firmware & data key pairs for install and update).

ST lifecycle allows the installation of up to three main parts on the product. They rely on three different parties

The figure below represents the product states to cover this three party model.

The three parties identified with their own colors: orange for immutable code, blue for updatable code running in TrustZone^®, then grey for the non secure application(s).

To summarize:

- iROT-Provisioned is used once the iROT is provisioned (code and data).

- TZ-Closed is used once the iROT and security (TrustZone^®) are provisioned.

- Closed or locked is used as soon as the full device is provisioned.

1.3. Device provisioning

The device provisioning is carried out by completing the initial provisioning, initial product setup and any one of the following steps.

This depends on the manufacturing constraints, and on the number of parties to provision:

• Initial provisioning

• Initial setup of the product, that determines who controls the ROT

• Could be only the [iROT] : in this case the product is set in iROT-Provisioned

• Could be [iROT+TZ-application] : in this case the product is set in TZ-Closed

• Could be [iROT+TrustZone^®+non secure application]

• Updates are possible when several third parties are considered:

• when the initial provisioning is not complete

• then the installed firmware oversees new firmware and keys to install

1.3.1. ST lifecycle development and provisioning using up to three parties

The figure below represents proposed distribution models for a development lifecycle of up to three parties.

To summarize:

- 1 party: All firmware development is owned by one entity.

- 2 parties: All secure firmware is owned by one party, then the non secure application is owned by a second party. This means two different responsibilities, and potentially two different key pairs to manage install and updates.

- 3 parties: iROT, secure and non secure applications are owned by three different parties. This means three different responsibilities, and potentially three different key pairs to manage install and updates.

1.3.2. ST lifecycle initial provisioning (from open or provisioning)

The device can be provisioned in up to three steps. This depends on the device usage, on the manufacturing constraints, and on the number of third parties to provision. Overall, we assume the device to be provisioned is a blank device. We recommend to make provisioning for final product in provisioning product state. While in development, all the lifecycle can use open product state.

The figure below represents the initial provisioning taking into account the different distribution models.

• Initial setup of the product, that determines which controls its iROT

• Could be only the [iROT]: in this case the product is set in iROT-Provisioned
• Could be [iROT+TrustZone^®]: in this case the product is set in TZ-Closed
• Could be [iROT+TrustZone^®+non secure]

It is recommended to use the SFI (Secure Firmware Install) solution for initial provisioning in untrusted manufacturing.

It is also recommended to protect all key provisioning, even if the manufacturing is trusted.

1.3.3. ST lifecycle to complete the initial provisioning

When several third parties are considered, the initial provisioning can only cover a part of the installation process.

The end of the provisioning is based on the firmware which is already installed at the initial provisioning state:

- Secure Firmware Update / Secure Key Provisioning

- Both secure and non secure firmware parts can be installed either, at the same time, or in two steps: the secure part is installed first, followed by the non secure part.

1.4. ST lifecycle / product states

1.4.1. ST lifecycle / product states = Open

The open state corresponds to the default state of the product when it is delivered.

This state is ideal to use while under development, as the debug is fully available.

In this state, the BOOT path configuration can be done using TZEN and UBE option bytes, and most of the features can be used as HDPL, TrustZone^®, and so on.

1.4.2. ST lifecycle / product states = provisioning

The provisioning state allows the provisioning of the device, while taking care of the asset protection.

It is recommended to manage the product provisioning in this state, in order to benefit of:

- the asset protection ==> in this state, the debug is limited to HDPL3-NonSecure.

- the encryption of the assets done using a valid DHUK to encrypt the OBKeys or other information, when the SAES is available. In fact, the RHUK is not differentiated in the open state, whereas it is unique for each product in all of the other states.

- the bootloader and JTAG/SWD availability for HDPL3-NS

1.4.3. ST lifecycle / product states = iROT-Provisioned

The iROT-Provisioned state corresponds to an intermediate state of the product.

The iROT code and data are provisioned.

From this state, the next level can be updated with firmware update mechanism.

1.4.4. ST lifecycle / product states = TZ-Closed

The TZ-Closed state corresponds to an intermediate state of the product. All the secure firmware is installed, the non secure application can be developed, or loaded in a second instance.

The iROT + uROT (optional) + Secure-OS code and data are provisioned.

From this state, the non secure application can be updated using the firmware update mechanism, or directly programmed through the flash loader (embedded in the IDE).

1.4.5. ST lifecycle / product states = Closed/Locked

The closed state corresponds to the final state of the product. All debug accesses are closed, and only accessible through debug authentication.

From closed state, the debug authentication can be used to launch partial or full regressions, or to open the debug.

The locked state corresponds to the final state of the product. All debug accesses are locked.

Warning

This state is final, the debug authentication is NO LONGER accessible.

1.5. ST lifecycle / debug authentication

The debug authentication feature allows the control of the product lifecycle when it is in the field (maintenance).

The debug authentication feature can also be used during the product configuration, to manage partial and full regressions, or to activate intrusive debug. This is represented by green arrows in the figure below.

For more details, refer to: Debug authentication wiki article