Debug Authentication STM32H5 How to Introduction

Introduction to debug authentication for STM32H5 MCUs

1. Debug authentication

Debug authentication controls debug opening and regressions. It can be used during development, manufacturing and for field return analysis.

• Features
  • When TrustZone^© is disabled, the usage of a password is the only regression possible.
  • When TrustZone^© is enabled, the usage of cryptography (certificates) can be used for regressions and debug opening.
• Debug authentication principle
  • Use of JTAG dedicated access point (ap0) to communicate with the chip.
  • Secure protocol defined by ARM: ARM PSA ADAC V1.0. (authenticated debug access control).

2. Debug authentication for STM32H503 product lines

Provisioning with password management

• STM32H503 does not provide OB-Key area and uses OTP (One time programming) to store the provisioning data. Once the password is provisioned, it cannot be changed.
• Provisioning data is the HASH (SHA256) of the password.
• A script is used to generate the HASH of the password chosen by the user (16 bytes), adding SHA256 to ensure integrity.

Debug authentication controls

• Full regression with the debug authentication password.
• Debug authentication password must be provisioned in OTP to allow this regression.

Getting started with debug authentication

Refer to the following page for an example on getting started with debug authentication access on STM32H503 product lines:

How to start with debug authentication access on STM32H503

3. Debug authentication on STM32H523/533/563/573 product lines when TrustZone^© is disabled

Provisioning with password management

• Provisioning data is located at the beginning of the OBKeys-HDPL1 area.
• Provisioning data is the HASH (SHA256) of the password.
• STM32TrustedPackageCreator is used to generate the OBKeys files containing the HASH of the debug authentication password adding SHA256 to ensure integrity.

* For further details on OBKeys access per HDP level, refer to Table 45. Option-byte key area of RM0481 STM32H5x3/562 Reference Manual.

Debug authentication controls

• Full regression with the debug authentication password.
• Debug authentication password has to be provisioned in OBKeys to allow this regression.

Getting started with debug authentication

Refer to the following page for an example on getting started with debug authentication access when TrustZone^© is disabled:

How to start with debug authentication access on STM32H573 when TrustZone^© is disabled

4. Debug authentication on STM32H523/533/563/573 product lines when TrustZone^© is enabled

Provisioning with certificate management

• Provisioning data is located at the beginning of the OBKeys -HDPL1 area.
• Provisioning data contain:
  • HASH (SHA256) of the root Certificate Public Key.
  • SOC_PERMISSION: 16 bits defining the permissions authorized by default.
• STM32TrustedPackageCreator generates the OBKeys files containing the provisioning data adding SHA256 to ensure integrity.

* For further details about OBKeys access per HDP level, refer to Table 45. Option-byte key area of RM0481 STM32H5x3/562 Reference Manual.

Debug authentication controls

• Reenabling debug possibility.
• Partial or full regression.

To perform debug authentication

• The chip must be provisioned with:
  • ECC public key.
  • SOC_PERMISSION: 16 bits defining the permissions authorized by default.
• A certificate signed by a private ECC key has to be created to be able to authenticate, which embeds the following:
  • ECC public key.
  • PERM_MASK_CERT, which describes the capabilities associated with this certificate.

Getting started with debug authentication

Refer to the following pages for an example on getting started with debug authentication access when TrustZone^© is enabled:

• How to start with OEMiRoT on STM32H573 – TrustZone^© enabled - Debug authentication
• How to start with STiRoT on STM32H573 - Debug authentication

5. Debug authentication - certificates

When debug authentication control is based on certificates (when TrustZone^© is enabled (TZEN = 0xB4)), the device must be provisioned with the ECC public key and the SOC_PERMISSION, which is a mask defining the different permissions allowed by the debug authentication (full regression / partial regression / debug secure / debug nonsecure).

5.1. Certificate for debug authentication access

To be able to connect to a closed device, the user needs a certificate that embeds the following elements:

• ECC public key.
• PERM_MASK_CERT, which describes the capabilities associated with this certificate.

This certificate must be created in a secure environment. It is signed by a private ECC key to be kept secret.

STM32TrustedPackageCreator is used to create the certificate. The user enters the public root key and defines the 16-bytes permission mask, which allows a lot of flexibility: Full or partial regression, open the debug for nonsecure or secure application (setting 1 gives the permission):

The STM32CubeH5 package provides examples of public keys and certificates in
STM32Cube_FW_H5_V1.0.0\Projects\STM32H573I-DK\ROT_Provisioning\DA\Certificates,
STM32Cube_FW_H5_V1.0.0\Projects\NUCLEO-H563ZI\ROT_Provisioning\DA\Certificates,
STM32Cube_FW_H5_V1.0.0\Projects\STM32H573I-DK\ROT_Provisioning\DA\Keys, and
STM32Cube_FW_H5_V1.0.0\Projects\NUCLEO-H563ZI\ROT_Provisioning\DA\Keys folders.

These default key pairs and certificates can be used to make a provisioning and a full or partial regression without creating a certificate.

5.2. Certificate chain

A certificate chain is used to delegate debug authentication access with the capability to restrict the possible permissions to another stakeholder (OEM, third-party, in the field).

5.2.1. Certificate chain composition

The permissions are handled through a certificate chain composed of three different certificates:

• The root certificate: it defines the permissions allowed to the owner of the root certificate.
  
• The intermediate certificate: the owner of the root key defines the permission for the owner of the intermediate key. Intermediate certificate gives equal or less permissions than the root certificate.
  
• The leaf certificate: the owner of an intermediate private key defines the permission for the owner of the private leaf key. Leaf certificate ives equal or less permissions than the intermediate certificate.
  

5.2.2. Certificate chain use case

We can imagine three teams:

• Team A, a secure development team, which must have access to the complete software/hardware platform.
• Team B, a nonsecure development team, which must have only access to nonsecure resources.
• Team C, a field engineer, who must only have the capability to do a regression to check hardware.

The Team A tasks to create the debug authentication chain are the following:

• Provisioning of the OB key and the permission mask.
• Creating the ROOT certificate, which allows full and partial regression, secure and nonsecure debug.
• Creating a certificate for Team B to debug nonsecure code and regressions: LEAF certificate 1.
• Creating an intermediate certificate, which allows Team B to create a certificate to Team C.

The Team B tasks to create the debug authentication chain are the following:

• Creating a certificate for Team C allowing only full regression, thanks to the intermediate certificate delivered by Team A: LEAF certificate 2.

Team B certificate is delivered by Team A: Leaf Certificate 1 - Regressions and nonsecure debug is allowed. Team C certificate is delivered by Team B. Team C will only be allowed to do a full regression with the Leaf certificate 2.

This team use case in an example that users can adapt.
Refer to the following articles to create a chain certificate:

• How to start with OEMiRoT on STM32H573 - TrustZone^© enabled - Certificate chain generation
• How to start with STiRoT on STM32H573 - Certificate chain generation

6. Appendix

6.1. Certificate and certificate chain linked to a SOC class and SOC ID

It is possible to generate a certificate or certificate chain valid only for one product family and even for a specific device.
An example is provided for STM32H573/STM32H563 but is applicable for all STM32H5 except STM32H503 where only the debug authentication through password is supported.
The two following identifiers are used to generate such specific certificates.

• SOC class
  • In the reference manual, the SOC class is called the device ID (DEV_ID).
  • For instance, it is 0x484 for STM33H56x/57x.
  • This ID is called the SOC class, naming in accordance with the ARM PSA ADAC specification, and is specific to these products.

• SOC ID:
  • In the reference manual, the SOC ID is called the unique device ID (UID).
  • Each single device has a unique ID stored in the UID register (see reference manual).
  • This value is indicated when, for instance, performing a discover using STM32CubeProgrammer.
  • This ID is called the SOC ID, naming in accordance with the ARM PSA ADAC specification.

How to proceed to generate such specific certificate / certificate chain is explained in the How to start with certificate linked to SOC class and ID on STM32H5.

Note:

There is a limitation for STM32H56x devices embedding SFSP2.5.0 (or previous SFSP).

On these devices, when the product state is set to CLOSED, the SOC ID cannot be readout using the discover function of the STM32CubeProgrammer.

Unless the SOC ID is stored before closing the device, it will not be possible to retrieve this identifier needed to generate a certificate chain specific to this device.

The SFSP version can be readout at the address: 0x0BF960CC; for SFSP2.5.0 the value is: 0x02050000.