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.
• STM32TrustedPackageCreator 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 STM32H563/573 product lines when TrustZone^© is disabled

Provisioning with password management

• Provisioning data is located at 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 STM32H563/573 product lines when TrustZone^© is enabled

Provisioning with certificate management

• Provisioning data is located at 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

• Re-enabling 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 authentification (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 which embeds the following elements:

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

This certificate should 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. 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 an other 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 intermediate private key defines the permission for the owner of the private leaf key. Leaf certificate gives equal or less permissions than the intermediate certificate.
  

5.2.2 Certificate chain use case

We can imagine 3 teams :

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

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 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 - Debug Authentication
• How to start with STiRoT on STM32H573 - Certificate chain generation