Debug Authentication

Revision as of 13:41, 2 March 2023 by Registered User

1. What is Debug Authentication ?

User leverages Debug Authentication security feature to either:

  • Perform regression to product states OPEN or TZ-CLOSED in a secured way, erasing user data in user Flash, SRAM and OBKeys.
  • Re-open Debug Access on the STM32 in a secured way.

Debug Authentication only grants such services to legitimate user thanks to Password or Certificate.

Debug Authentication is tightly related to:

  • STM32 life cycle
  • STM32 ARM TrustZone enablement or not.

1.1. Password

Regression by Password

On Password reception, STM32 verifies that Password corresponds to the one provisioned.

1.2. Certificate

Full Regression by Certificate

When user triggers Debug Authentication feature (Regression or Debug Re-opening), he sends firt a Certicate and a Debug Authentication Action Request to the STM32. On Certificate reception (Step 1), STM32 verifies that:

  • Certificate fits the one provisioned.
  • The Authorised Actions carried by the Certificate fit the ones provisioned.
  • The Action Request fits with Authorised Action list carried by the Certificate.

STM32 starts challenge-response procedure (Step 2 and Step 3): STM32 verifies that Host owns the Debug Authentication Private Key before performing the requested action (regression or Debug re-opening). The Certificate carries the requested action.

In the scheme below STM32 blocks Debug Authentication Action Request because Authorised Actions within Certificate do not map Provisioned Authorised Actions.

Picture 1: Security Debug Authentication Request Blocked



In the scheme below STM32 blocks Debug Authentication Action Request because Action Request does not fit with Certificate Authorized Actions.

Picture 2: Security Debug Authentication Request Blocked



In the scheme below, Certificate Authorized Actions fit Provisioned Authorized Action and Action Request fits Certificate Authorized Actions, then STM32 grants Debug Authentication Action Request.

Picture 3: Security Debug Authentication Request Granted

2. Provisioning

Debug Authentication Life Cycle

Before configuring STM32 in a product state higher than PROVISIONING (i.e PROVISONED, TZ-CLOSED or CLOSED) , user must provision either:

  • The hash of the CA Public Key + authorized actions on Certificate reception. Authorized actions are a combination of Regression, Partial Regression and Debug re-opening.

or

  • The hash of the Password + authorised action on Password reception.

After running regression, STM32 comes back either in product state OPEN or TZ-CLOSED.

3. Regression

3.1. Full regression

Debug Authentication erases full user Flash, SRAM and OBKEys1.

Full Regression by Certificate



3.2. Partial regression

Debug Authentication erases non-secure user Flash, non-secure SRAM and non-secure OBKEys1.

Partial Regression

Please note that STM32 not supporting TrustZone or not enabling TrustZone do not support Partial regression.
Note1: When STM32 supports OBKeys.

4. Debug Re-opening

Debug Reopening
Info white.png Information
After regression STM32 DHUK is changed, secure storage sections (protected by DHUK) extracted before regression can't be reused after regression
No categories assignedEdit