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 signed by a CA with challenge-response mechanism:
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 regression or Debug re-opening.
Debug Authentication is tightly related to:
- STM32 life cycle
- STM32 ARM TrustZone enablement or not.
2. Debug Authentication and STM32 life cycle
Before configuring STM32 in a product state higher than "provisioning", user must provision either:
- The hash of the CA Public Key + authorized action on Certificate reception.
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 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.
3.2.2. Debug reopening
