Revision as of 10:25, 22 May 2023 by Registered User (→ST Lifecycle / Product states = TZ-Closed)
|
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 :
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
- • When several Third parties are considered
- • Initial Provisioning
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.
- 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 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.
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