This message will disappear after all relevant tasks have been resolved.
Semantic MediaWiki
There are 1 incomplete or pending task to finish installation of Semantic MediaWiki. An administrator or user with sufficient rights can complete it. This should be done before adding new data to avoid inconsistencies.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 the STM32H5 family, we are introducing a new product lifecycle, in order to allow more flexibilities on product manufacturing and maintenance.
- The new product lifecycle encompasses different phases.
- The phases are:
- - development phase, offering all debug capabilities to the developer.
- - provisioning phase, where the main assets areas are protected (no more accessible) …
- - final phase, where the product is in the field.
- - maintenance phase, field return management.
- During the product's 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 :
1.2. Up to three parties
- In the development and provisioning phases, the product lifecycle allows to consider the product being developed by up to three parties.
- Different third parties means that for development and provisioning, we are able to set the product in a state that allows to protect (isolate) the different parties. This means also three different responsibilities, and potentially three different Keys (Firmware & data key pairs for install and update).
- ST Lifecycle considers three main parts to be installed in the product that could rely on three different parties
- The below figure represents the considered product states to cover this three party model.
- We are identifying the three 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
- • When several third parties are considered
- • Initial Provisioning
1.3.1. ST Lifecycle Development and Provisioning considering up to three parties
- The below figure represents the considered distribution models to considering up to three 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 three different parties. Means three 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 represents 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.
- The end of the provisioning can be done based on firmware(s) already installed (at initial provisioning)
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 corresponds 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 corresponds to the 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 corresponds to the final state of the product. All debug accesses are Locked.
1.5. ST Lifecycle / Debug Authentication
- The Debug Authentication feature allows to control the product lifecycle when it is in the field (maintenance).
- It can also be used during product configuration, to manage partial/full regressions or to activate intrusive debug. This is represented by green arrows in the below figure.
For more details, refer to: Debug authentication wiki article
2. References