Secure Storage for STM32H5

Target description

1 Introduction

Before proceeding with this article, read the article Introduction to secure storage.

A critical security feature is a dedicated memory location where secret data such as keys can be stored in a very safe way.
A STM32H5 device provides five secure storage areas to fulfill this requirement, called OB Keys secure storage.
Every secure storage area is temporarily isolated through the HDPL level.

The figure below shows the five OB Keys secure storage areas, one for every HDPL level (HDPL0, HDPL1, HDPL2, HDPL3 secure, and HDPL3 nonsecure).

Figure 1 STM32H5 OB Keys secure storage

2 The secure storage areas for STM32H5 (OB key area)

The secure storage areas are also called option-byte Key (OBKeys) areas or secure key storage areas.
As mentioned in the introduction, the STM32H5 provides five secure storage areas that can be used to store keys but also any sensitive or secret data.
Any of these areas is related to a specific temporal isolation level HDPL. This will be explained in the next chapter.
It can be chosen if the stored data are encrypted or not.
Note:The stored data can be encrypted only for the STM32H57x. For STM32H56x, see dedicated chapter secure storage for STM32H56x

The five areas are described in the table below.

Temporal isolation level	Storage size (bytes)	Usage	Regression
HDPL0	256	Reserved for STMicroelectronics	Never erased
HDPL1	2048	iRoT keys	Erased through regression
HDPL2	768	uRot, OS, or secure application	Erased through regression
HDPL3S	3072	Secure application keys	Erased through regression
HDPL3NS	2032	nonsecure application keys	Erased through NS-Regression

Notes:

• A full regression erases all the secure storage areas, except the HDPL0 secure storage that is never erased. This secure storage is an STMicroelectronics reserved domain.
• A partial regression (NS-Regression) erases only the HDPL3 nonsecure storage.
• In case of a tamper detection, the DHUKs (see chapter Secure storage protection) are not usable anymore until the next reset. So, if the contents of the secure storages are encrypted, these contents will not be accessible anymore. But the contents of the secure storages are not erased through a tamper event. The wanted actions related to the tamper event needs to be done through the interrupt handler.

3 Temporal isolation

Reminder: the different boot stages of the STM32H5 are protected through temporal isolation.
See Secure Boot for STM32H5.
The firmware execute in HDPL[N] has no access to any firmware that has been executed in HDPL[N-1] and earlier (HDPL[N-x]).

For the secure storage, it is a similar principle. The firmware currently executed in a specific HDPL[N] has no possibility to access to the secure storage HDPL[N-x].
On the other hand, this firmware can access to the secure storage HDPL[N] and also to any secure storage HDPL[N+x].

The SBS (system configuration, boot, and security), embedded in the device, controls the secure storage access (see RM0481).
The OBK-HDPL (that can be equal or higher than HDPL of the current executed firmware) selects the secure storage area.
The control of the access is also taken into account if the executed firmware is secure or nonsecure (see figure in next chapter).

4 Secure storage protection

The protection of the secure storages is guaranteed through the access control of the flash interface.
The access is controlled through:

• RHUK: Root hardware unique key. It is a 256-bit nonvolatile key that is unique for each STM32H5 device and is never visible from any software.
• DHUK: Derived Hardware unique key. A 256-bit key that is different for every secure storage (HDPL0, HDPL1...), and is generated by the SAES based on RHUK.
• EPOCH: Monotonic counter (24 bits) increased at each regression. It helps to protect from the installation of an older firmware/data version (antirollback/antireplay).
• HDPL: Temporal isolation level explained in the previous chapter.

The SAES is the cryptographic hardware embedded in the STM32H5 that is side channel attack resistant. It embeds the key generator to provide the different DHUKs.

• Note: the SAES and related functionalities are only available for the STM32H57x. For STM32H56x, refer to the dedicated chapter Secure storage for STM32H56x

The figure below gives an overview of the access control.
The SBS (see previous chapter) controls the OBK-HDPL, but also the EPOCH selection.

• NEXTHDPL[1:0] of SBS register (SBS_NEXTHDPLCR) is used to select an OBK-HDPL higher than the HDPL of the current executed firmware.
  
• EPOCH_SEL[1:0] of SBS register (SBS_EPOCHSELCR) is used to select between the EPOCH counter for secure or nonsecure application. See the corresponding reference manual (RM0481).

Figure 2 Data encryption using SAES/DHUK

The figure below shows that there are two EPOCH counters: one related to a secure application (EPOCH-S) and one related to a nonsecure application (EPOCH-NS).

Figure 3 EPOCH counter, secure and nonsecure

• After a partial regression (NS-Regression), only the EPOCH-NS counter is incremented.
• After a full regression, both the EPOCH-NS and the EPOCH-S counters are incremented.

A regression is erasing the data storage.
But through the EPOCH counter, it is insured that the data stored before a regression cannot be retrieved anymore since the DHUKs are new.

In summary:

• Cloning protection is guaranteed through the RHUK. Unique for every device, it ensures that all the derived keys and encrypted data are valid only for a specific device.
• Antirollback protection is insured through the EPOCH counters. They help to control that previously encrypted data cannot be reused. It means that new DHUKs are requested after a regression. The data related to the secure and nonsecure applications are protected through two different EPOCH counters.
• Temporal isolation is insured through the SBS to forbid the access of the secure storage HDPLx lower than the HDPLx of the current executed code.

Note: The EPOCH counters incrementation that modify the DHUKs prevent against the typical rollback use case described below:

• Assuming a hacker finds a way to dump the encrypted data of the secure storage.
• If he is doing a product regression, he can install his own firmware.
• He can also store again the dumped encrypted data.
• This firmware can then use the SAES to decrypt these data.
• With the modified DHUKs, the previously encrypted data are not usable anymore.

5 Provisioning secure storage content

For the provisioning of the data, the security mechanism explained previously are used.

• Through the temporal access control, the HDPL[N] secure storage of the current executed firmware can be written.
• The HPL[N+x] secure storage can also be written, but the HDPL[N-x] access is not possible. (See previously NEXTHDPL[1:0]).
• The data are encrypted through the SAES by using the DHUK key dedicated to the related HDPL[N].

Figure 4 Secure storage data provisioning

Example of the above figure:

• The current executed firmware is running in HDPL2 (for instance an uRoT, see Secure Boot for STM32H5)
• The data to be stored (keys or any secret data) are encrypted through the SAES using the dedicated DHUK.
• These data are then stored in the dedicated secure storage.
• The current HDPL is 2.
  However, it is possible to add an offset (as explained above SBS_NEXTHDPLCR) and to access to the HDPL3S secure storage.
  But the access to HDPL1 and HDPL0 secure storages are blocked through the flash access control.
  To write to the HDPL3NS, the EPOCH selection needs to be changed to NS-EPOCH (see above EPOCH_SEL[1:0]).
  The programming of the above mentioned selection bits is done through the firmware executed in HDPL2.

6 Secure storage content readout

To read a secure storage content, the same mechanisms, as explained above, are controlling the access:

• The readout is done through unwrapping the encrypted data using the dedicated DHUK[N] key for the specific HDPL[N] secure storage.
• Secure storage readout of the current executed firmware HDPLx (temporal isolation)
• Possible readout of higher HDPL level secure storage (offset bits programming NEXTHDPL[1:0] of SBS register (SBS_NEXTHDPLCR)).
• The readout of data is allowed only if valid for the executed firmware version (EPOCH counter in case of regression).
• Selection of the secure or nonsecure EPOCH counter (programming EPOCH_SEL[1:0] of SBS register (SBS_EPOCHSELCR).

7 Secure storage for STM32H56x

The STM32H56x devices do not support the hardware cryptographic accelerator. They also do not support the SAES.
For the secure storage access control, the temporal isolation and the isolation between secure and nonsecure are supported by the STM32H56x.
But the secure storage encryption/decryption through the DHUKs and the related protection mechanism are not supported by the STM32H56x.

The figure below gives an overview of the secure storage access control for the STM32H56x.

Figure 5 STM32H56x secure storage

Comparing with figure 4, the gray box hides the features that are not supported for STM32H56x devices.