Under construction.png Coming soon

1. What is new product state

PRODUCT Lifecycle is used to control the product security configuration. It allows to control the activation of the platform’s security mechanisms. In the latest microcontrollers we are introducing a new lifecycle, based on a new state machine and different rules.

1.1. New product lifecycle

Starting from STM32H5 family, we are introducing a new product lifecycle , in order to allow more flexibilities on product manufacturing and maintenance.
The new product lifecycle considers different phases.
The considered phases are:
- development phase, offering all debug capabilities to developer.
- provisioning phase, where main assets area are protected (no more accessible) …
- final phase, where the product is in the field.
- maintenance phase: field return management.
During all product life, the solution must guarantee that ROT (Root Of Trust) and user assets are never disclosed.
This must be true for development, provisioning, final, and field return phases.
The new product lifecycle proposes the below product states :
Info white.png Information
When Trust zone is not proposed, the TZ-Closed does not exist.
Info white.png Information
This Simplified version does not show the Debug Authentication part (Regressions and Debug reopening). The complete version can be seen in Debug Authentication dedicated section.
Warning white.png Warning
The Debug Authentication configuration (DA-config) must be provisioned in Provisioning state.

1.2. Up to 3 parties

In the development and provisioning phases, the product lifecycle allows to consider the product being developed by up to 3 parties.
Different third parties means that for development and provisioning, we are able to set the product in a state that's allow to protect (isolate) the different parties. This means also 3 different responsibilities, and potentially 3 different Keys (Firmware & data key pairs for install and update).

1.2.1. ST Lifecycle consider 3 main parts to be installed in the product that could rely on 3 different parties

The below figure represent the considered product states to cover this 3 parties model.
We are identifying the 3 parties with different colors: orange for immutable code, blue for updatable code running in Trust Zone, then grey for the non secure application(s).
In short
- iROT-Provisioned is used as soon as iROT is provisioned (code and data).
- TZ-Closed is used as soon as iROT and Secure (Trust Zone) are provisioned.
- Closed or Locked is used as soon as the full device is provisioned.

1.3. Device provisioning

The device provisioning is done in one or several steps.
This depends on the manufacturing constraints, and on the number of parties to provision, ….
• Initial Provisioning
• Initial setup of the product, that will determine who is controlling its ROT
• Could be only the [iROT] : in that case the product will be set in iROT-Provisioned
• Could be [iROT+TZ-application] : in that case the product will be set in TZ-Closed
• Could be [iROT+TrustZone+none-secure application]
• Updates
• When several Third parties are considered
• the Initial Provisioning is not complete,
• then the installed firmware oversees new firmware & keys to install

1.3.1. ST Lifecycle Development and Provisioning considering up to 3 parties

The below figure represent the considered distribution models to considering up to 3 parties.
In short
- 1 party: All Firmware owned by one entity.
- 2 parties: All Secure part owned by one part, then Non-Secure application owned by a second part. Means 2 different responsibilities, and potentially key pairs (to manage install and updates).
- 3 parties: iROT, Secure and Non-Secure appli owned by 3 different parties. Means 3 different responsibilities, and potentially key pairs (to manage install and updates).

1.3.2. ST Lifecycle Initial provisioning (from Open or Provisioning)

The device can be provisioned in one or several steps. This depends on its usage, on the manufacturing constraints, and on the number of third parties to provision. Overall, we are considering the inital provisioning as starting from 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 below figure represent the initial provisioning considering the different distribution models.
  • Initial setup of the product, that will determine who is controlling its ROT
  • Could be only the [iROT]: in that case the product will be set in iROT-Provisioned
  • Could be [iROT+TrustZone]: in that case the product will be set in TZ-Closed
  • Could be [iROT+TrustZone+Non-Secure]
We recommend to use SFI (Secure Firmware Install) solution for initial provisioning in untrusted manufacturing.
We also recommend 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 cover only part of the installation.
The end of the provisioning can be done based on firmware(s) already installed (at initial provisioning)
- Secure Firmware Update / Secure Key Provisioning
- In one step: both Secure and Non-secure installed on same time or in 2 steps: Secure is installed then non-secure in a second step.

1.4. ST Lifecycle / Product states

1.4.1. ST Lifecycle / Product states = Open

The Open state corresponds to the default state of product when 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 thanks to TZEN and UBE Option Bytes, and most of features can be used as HDPL, Trust Zone, …

1.4.2. ST Lifecycle / Product states = Provisioning

The Provisioning state allows to Provision the device, taking care of the assets protection.
We recommend to manage the product provisioning in this state, in order to take benefit of:
- the assets protection ==> in this state, the Debug is limited to HDPL3-NonSecure.
- When SAES available, encryption of the assets using a valid DHUK (to encrypt the OBKeys or other information). Effectively, the RHUK is not differentiated in Open state, whereas it is unique per product in all other states.
- Bootloader and JTAG/SWD availability for HDPL3-NS

1.4.3. ST Lifecycle / Product states = iROT-Provisioned

The iROT-Provisioned state correspond to an intermediate state of the product
The iROT code and data are provisioned.
From this state the next level can be updated, thanks to Firmware Update mechanism

1.4.4. ST Lifecycle / Product states = TZ-Closed

The TZ-Closed state correspond to an intermediate state of the product. All the secure is installed, the non-secure application can be developped, or loaded later.
The iROT + uROT (optional) + Secure-OS code and data are provisioned.
From this state the non-secure application can be updated, thanks to Firmware Update mechanism, or directly programmed through flash loader (embedded in IDE).


1.4.5. ST Lifecycle / Product states = Closed/Locked

The Closed state correspond to final state of the product. All debug access are closed, 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 correspond to final state of the product. All debug access are Locked.
Warning white.png Warning
This state is final, the Debug Authentication is NOT usable.

1.5. ST Lifecycle / Debug Authentication

The Debug Authentication feature allows to control the product lifecycle when it is in the field (maintenance).
It is also used during product configuration.


File:Security:ProductLifecyle-TZEN1-Full.png

For more details, refer to: Debug authentication wiki article

2. References