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.
- Password
On Password reception, STM32 verifies that Password corresponds to the one provisioned.
- Certificate
On Certificate reception, STM32 verifies that Certificate is the one provisioned (Step 1). 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.
Debug Authentication is tightly related to:
- STM32 life cycle
- STM32 ARM TrustZone enablement or not.
2. Debug Authentication provisioning
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. Debug Authentication and TrustZone
3.1. TrustZone disabled
Debug Authentication grants authorized action on Password reception.
3.1.1. Regression
Full regression: Debug Authentication erases full user Flash, SRAM and OBKEys.
3.2. TrustZone enabled
Debug Authentication only grants authorized action on Certificate reception.
3.2.1. Regression
- Full regression: Debug Authentication erases full user Flash, SRAM and OBKEys.
- Partial regression: Debug Authentication erases non-secure user Flash, non-secure SRAM and non-secure OBKEys.