4. System security

The STM32H7Rx/7Sx products are designed with a comprehensive set of security features. This section explains the different security features available on STM32H7Rx/7Sx devices.

4.1 Key security features

4.2 Secure install

The secure firmware install (SFI) is an immutable secure service embedded by STMicroelectronics in the devices. The SFI allows secure and counted installation of OEM firmware in untrusted production environment (such as OEM contract manufacturer).

The confidentiality of the installed images written in the internal flash memory is also protected using the AES.

The SFI native service leverages the following hardware security features:

Further information can be found in the application note Overview secure firmware install (SFI) (AN4992).

4.3 Secure boot

Secure boot is an immutable code that is always executed after a system reset. As a root of trust, this code checks the device static protections and activates available device runtime protections, reducing the risk that invalid or malicious code runs on the platform. As root of trust, the secure boot also checks the integrity and authenticity of the next level firmware before executing it.

The STM32H7Sx offers two options using IROT_SELECT option byte for the immutable code to be executed after a reset. The STiRoT takes advantage of the security services already embedded in the STM32. The other option allows OEMs to manage the secure boot path:

In the devices, the secure boot takes advantage of hardware security features such as:

This section describes the features specifically designed for secure boot.

4.3.1 Unique boot entry

The IROT_SELECT option byte allows boot through the STiRoT or OEM-iROT (user flash memory). This selection is possible only for products embedding cryptographic acceleration (STM32H7Sx).

For more information on the boot mechanisms, see Section 2.6: Boot configuration .

4.3.2 Security services in system flash memory

The security services located in the system flash memory, cover the root secure services (RSS), the STiRoT (immutable root of trust), and ST-DA (debug authentication).

The RSS (root secure service) allows the control of ST extensions loaded in SRAM (called RSS-e). One of the RSS-e manages the SFI (secure firmware Install). SFI allows secure and counted installation of OEM firmware in untrusted production environments (such as OEM contract manufacturer).

The STMicroelectronics immutable code also includes secure runtime services that can be called at runtime when a secure application sets the SBS_RSSCMDR register to a non-null value before triggering a system reset. This runtime feature is deactivated when the product state is different to “Provisioning”.

STM32H7Rx/7Sx products offer the following security services:

STM32H7Sxx products offer the following security services:

For this multi-reset flow, STiRoT secure boot or secure update sequence rely on:

Figure 6. Secure boot process

Diagram of the secure boot process showing memory layout and components.

The diagram illustrates the memory layout and components for the secure boot process. It is divided into two main sections: External memory and STM32H7S only + STiRoT.

External memory: Contains three stacked blocks: "Update slot" (top), "Image 1" (middle), and "Header OEM-uROT" (bottom).

STM32H7S only + STiRoT: Contains two main memory blocks. The top block is "User flash memory", which is divided into "External memory management" (top) and "OEM-iLoader" (bottom). A vertical arrow labeled "WRP" (Write Protection) points to the boundary between these two sections. The bottom block is "System flash memory", which is divided into four stacked blocks: "Bootloader" (top), "Debug authentication", "STiRoT", and "RSS" (bottom). A box labeled "iROT Select" is connected to the "STiRoT" block in the system flash memory.

MSV55536V4

Diagram of the secure boot process showing memory layout and components.

A typical secure boot flow is as follows:

Hypothesis: The IROT_SELECT has been set to STiRoT and the STiRoT has been provisioned. OEM-iLoader code has been installed and write protected in user flash memory. The first updatable boot level has been provisioned in the external memory.

Flow execution:

  1. 1. On the STiRoT initial execution, it verifies then launch the OEM-iLoader.
  2. 2. Then OEM-iLoader is able to read external memories:
    1. a) OEM-iLoader checks if an update image is present for the OEM-uROT. If so, it loads it to the SRAM then launch a reset, to let the STiRoT managing the secure controls before install.
    2. b) If no update image is present then OEM-iLoader loads OEM-uROT from external memory then launch a reset, to let the STiRoT managing the verification of the image before launching it.

4.4 Secure update

The secure update is the capacity of the product to update its firmware, allowing improvement of the product features, or fixing of vulnerabilities.

The product update is considered to be done in almost 2 parts:

When STiRoT is selected, the secure update is executed in several steps. See the previous paragraph for more details.

When OEM-iROT is selected, it is hosted in the internal flash memory. It can be partially or fully immutable. It must manage the external memories, including the hardware setup, the secure boot, the secure update of the next updatable level (uROT).

The update process is performed in a secure way to prevent unauthorized updates and access to confidential on-device data.

4.5 Resource isolation using hide protect levels

In the STM32H7Rx/7Sx devices, the hardware and software resources used for boot can be isolated using the temporal isolation proposed with the HDPL (HiDe protect level) mechanism.

It is based on a monotonic counter, which by definition allows only incrementing of the levels. When the counter is incremented, the resources of the previous levels become hidden (code and data).

A typical usage of the HDPL, is to allocate the HDPL=1 to the iROT. Then the HDPL=2 to the uROT (including OEM-iLoader), then the application is executed in HDPL=3.

4.5.1 Temporal isolation using secure hide protection (HDP)

The embedded flash memory allows definition of an HDP area associated to an HDPL with an 8-Kbyte page granularity (defined through the option bytes). The code executed in this HDP area, with its related data and keys, can be hidden after boot until the next system reset.

The hide protection is related to HDPL=1 (hidden when HDPL becomes equal or greater than 2) when OEM-iROT is selected.

The hide protection is related to HDPL=2 (hidden when HDPL become equal or greater than 3) when STiRoT is selected.

Typically, the activation of an HDP area in user flash memory is related to HDPL1. This means that as soon as the HDPL becomes greater than or equal to 2. Then data read, write and instruction fetch (on the area defined by HDP_AREA_START and HDP_AREA_END in FLASH_HDP option bytes), are denied until the next device reset.

Note: Bank erase aborts when it contains a write-protected area (WRP or HDP area).

4.6 Secure execution

Through a mix of special software and hardware features, the devices ensure their correct functional operation under abnormal situations. These can be caused by: programmer errors, software attacks through network access, or local attempt for tampering code execution.

This section describes the hardware features specifically designed for secure execution.

4.6.1 Memory protection unit (MPU)

The Cortex-M7 includes a memory protection unit (MPU) that can restrict read and write accesses to memory regions (including regions mapped to peripherals), based on one or more of the following parameters:

4.6.2 Embedded flash memory write protection

The embedded flash memory write protection (WRP) prevents illegal or unwanted write/erase to special sections of the embedded flash memory user area (the system area is permanently write protected).

Any 8 Kbyte sector can be independently write-protected or unprotected by clearing/setting the corresponding WRPS bit in the FLASH_WRPSR register.

The embedded flash memory write-protection user option bits can be modified when HDPL=0 or 1 in the SBS_HDPLSR register, using FLASH_WRPSRP.

Note: Bank erase aborts when it contains a write-protected area (WRP or HDP area).

4.6.3 Tamper detection and response

Principle

The devices include active protection of critical security assets against temperature, voltage and frequency attacks, with the following features:

See Section 50: Tamper and backup registers (TAMP) for more details.

Tamper detection sources

The devices support eight active input/output pins, allowing four independent active-tamper meshes, or up to seven meshes if the same output pin is shared by several input pins (for a total of eight active-tamper I/Os).

The active pins are clocked by the LSE, and are functional in different system operating modes (Run, Sleep, Stop, or Standby), and in VBAT mode. Refer to Section 50.4: TAMP low-power modes for a list of tamper pins and their availability across power modes.

The detection time is programmable, and a digital filtering is available (tamper is triggered after two false comparison in four consecutive comparison samples).

Note: Timestamps are automatically generated when a tamper event occurs.

The internal tamper sources are listed in the table below.

Table 21. Internal tampers in TAMP

Tamper inputNOER bit number in TAMP_CR3Tamper source
itamp10Backup domain voltage continuous monitoring, functional in VBAT mode
itamp21Temperature monitoring, functional in VBAT mode
itamp32LSE monitoring (1) , functional in VBAT mode
itamp43HSE monitoring
itamp54RTC calendar overflow (rtc_calovf)
itamp65JTAG/SWD access
itamp7, 12, 136, 11, 12Voltage monitoring (V CORE , V REF+ ), through ADC analog watchdog
itamp87Monotonic counter overflow (generated internally)
itamp98Fault generation for cryptographic peripherals (SAES, PKA, AES, RNG)
itamp1110IWDG timeout and potential tamper (IWDG reset when at least one enabled tamper flag is set)
itamp1514System fault detection
  1. 1. LSE missing or over frequency detection (> 2 MHz), Glitch filter (> 2 MHz).

Response to tampers

Each source of tamper in the device can be configured to trigger the following events:

Read/write accesses by software to all these secrets can be blocked, by setting the BKBLOCK bit in the TAMP_CR2 register. Access to device secrets is possible only when BKBLOCK is cleared, and no tamper flag is set for any enabled tamper source.

If \( V_{DD} \) is not present, the secrets that are erased when \( V_{DD} \) is present are only erased at the next \( V_{DD} \) power on.

Note: Device secret erase is also triggered by setting the BKERASE bit in the TAMP_CR2 register, or by performing a PRODUCT_STATE regression, as defined in Section 4.9.2 . Device secrets are not reset by system reset or when the device wakes up from Standby mode.

Software filtering mechanism

Each tamper source can be configured not to launch an immediate erase, by setting the corresponding TAMPxPOM bit in the TAMP_CR2 register (for external tamper pin), or TAMP_CR3 (for internal tamper).

In such situations, when the tamper flag is raised, access to the secrets below is blocked until all tamper flags are cleared:

Once the application is notified by the tamper event, it analyzes the situation. There are two possible cases:

Note: If the tamper software fails to react to such a tamper flag, an IWDG reset automatically triggers the erase of secrets.

Tamper detection and low-power modes

The effect of low-power modes on tamper detection are summarized on the table below.

Table 22. Effect of low-power modes on TAMP

ModeDescription
SleepNo effect on tamper detection features
TAMP interrupts cause the device to exit the Sleep mode.
StopNo effect on tamper detection features, except for level detection with filtering and active tamper modes that remain active only when the clock source is LSE or LSI
Tamper events cause the device to exit the Stop mode.
StandbyNo effect on tamper detection features, except for level detection with filtering and active tamper modes which remain active only when the clock source is LSE or LSI
Tamper events cause the device to exit the Standby mode.

Default tamper configuration after reset on closed/locked product states

From SFSP 2.1.0 onward (refer to AN6022), the security services located in the system flash memory activate internal tampers n°9 and n°15 for their security.

As a result, in Closed/Locked product state (where RSS is the unique boot entry), internal tampers n°9 and n°15 stay enabled when STiRoT launches the next-level firmware, but are disabled when RSS jumps directly into OEM-iROT (user flash memory).

4.7 Secure storage

A critical feature of any security system is how long-term keys are stored, protected, and provisioned. Such keys are typically used for loading a boot image, or handling of critical user data.

Figure 7 shows how a key management-service application can use the AES engine, for example to compute external image decryption keys. Nonvolatile keys are stored in a dedicated flash memory area, including access control (see Section 4.5.1 ), while volatile key storage consists of the battery-powered, tamper-protected SRAM or registers-TAMP.

Figure 7 also shows keys that are manipulated by software (such as MCE keys), or keys that are managed only by hardware (such as DHUK). More information on those hardware keys can be found in Section 4.7.1 .

Figure 7. Key management principle

Figure 7. Key management principle diagram showing the flow of keys from embedded non-volatile storage through hardware key derivation and various AES engines (Secure AES, AES with DPA, AES without DPA, MCE) to different storage types and peripheral usages.

The diagram illustrates the key management principle. It starts with 'Embedded non-volatile storage (software secret)' on the left. An arrow points to 'Hardware key derivation' in the center. From 'Hardware key derivation', an arrow points to 'Derived hardware unique key' in the 'Secure AES' block. Below 'Secure AES' is 'AES with DPA'. Below 'AES with DPA' is 'AES without DPA'. Below 'AES without DPA' is 'MCE'. To the right of 'AES with DPA' is 'Embedded volatile storage (tamper resistant)'. To the right of 'AES without DPA' is 'Embedded non-volatile storage'. Arrows indicate key transfers: 'HW key' from 'Derived hardware unique key' to 'AES with DPA', 'HW key' from 'AES with DPA' to 'Embedded volatile storage', 'HW key' from 'AES without DPA' to 'Embedded non-volatile storage', and 'Key' (software transfer) from 'MCE' to 'Embedded non-volatile storage'. A legend at the bottom left shows a solid arrow for 'Hardware transfer of key' and a dashed arrow for 'Software transfer of key'. The diagram is labeled MSv55537V1.

Figure 7. Key management principle diagram showing the flow of keys from embedded non-volatile storage through hardware key derivation and various AES engines (Secure AES, AES with DPA, AES without DPA, MCE) to different storage types and peripheral usages.

Details of tamper protection are given in Section 4.6.3 .

4.7.1 Hardware secret key management

As shown in the previous figure, the devices propose a better protection for application keys by using hardware secret keys. These AES keys can be made usable to the application, without exposing them in clear-text (unencrypted). Such keys also become immediately unusable in the case of tamper.

There are three different sources of hardware secret keys:

These keys can be used in the following modes:

4.7.2 Unique ID

The devices store a 96-bit ID that is unique to each device (see Section 67.1: Unique device ID register (96 bits) ).

Application services can use this unique identity key to identify the product in the cloud network, or to make it difficult for counterfeit devices or clones to inject untrusted data into the network.

Alternatively, the 256-bit device unique key (DHUK) can be used (see Section 4.7.1 ).

4.8 Crypto engines

The devices implement state-of-the-art cryptographic algorithms featuring key sizes and computing protection as recommended by national security agencies. These agencies include: NIST for the U.S.A, BSI for Germany or ANSSI for France. The algorithms are used to support privacy, authentication, integrity, entropy and identity attestation.

The crypto engines embedded in STM32 reduce weaknesses in the implementation of critical cryptographic functions. They prevent, for example, the use of weak cryptographic algorithms and key sizes. They also enable shorter processing times and lower power consumption when performing cryptographic operations, by offloading those computations from Cortex-M7. This is especially true for asymmetric cryptography.

For product certification purposes, ST can provide certified device information on how these security functions are implemented and validated.

For more information on crypto engine processing times, refer to their respective sections in the reference manual.

4.8.1 Crypto engines features

The table below lists the accelerated cryptographic operations available in the devices. Two AES accelerators are available. One is side-channel attack protected (SAES), while the second is more performance oriented (CRYP).

Note: Additional operations can be added using firmware.

The PKA can accelerate asymmetric crypto operations (like key pair generation, ECC scalar multiplication, point on curve check). See Section 40: Public key accelerator (PKA) for more details.

Table 23. Accelerated cryptographic operations

OperationsAlgorithmSpecificationKey lengths (in bit)Modes
Get entropyRNGNIST SP800-90B (1)N/ASoftware and hardware (2) modes running in parallel
Encryption, decryptionAESFIPS PUB 197
NIST SP800-38A		128, 256ECB, CBC, CTR (3)
Authenticated encryption or decryptionNIST SP800-38C
NIST SP800-38D		128, 256GCM, CCM
Cipher-based message authentication codeNIST SP800-38D128, 256GMAC
Table 23. Accelerated cryptographic operations (continued)
OperationsAlgorithmSpecificationKey lengths (in bit)Modes
ChecksumSHA-1N/ADigest 160-bit
Cryptographic hashSHA-2FIPS PUB 180-4-SHA-224, SHA-256
SHA2-384, SHA2-512
Keyed-hashing for message authenticationHMACFIPS PUB 198-1
IETF RFC 2104		Short, long
(>64 bytes)		-
Encryption/decryption key-pair generation (4)RSAIETF RFC 8017
NIST SP800-56B		Up to 4160RSAES-OAEP
Signature (4) with hashing
Signature verification		RSAIETF RFC 8017
FIPS PUB 186-4		Up to 4160PKCS1-v1_5, PSS
ECDSAANSI X9.62
IETF RFC 7027
FIPS PUB 186-4		Up to 640Refer to Table 392: Family of supported curves for ECC operations for details
Key agreementECDHANSI X9.42
  1. 1. Certifiable using STMicroelectronics reviewed documents.
  2. 2. Random numbers distribution to SAES and PKA using a dedicated hardware bus.
  3. 3. ECB and CBC chaining modes protected against side-channel and timing attacks in SAES (see Section 4.8.2 ).
  4. 4. Private key cryptography protected against side-channel and timing attacks.

Note: Binary curves, Edwards curves and Curve25519 are not supported by the PKA.

4.8.2 Secure AES co-processor (SAES)

The devices provide an on-chip hardware AES encryption and decryption engine, which implements countermeasures and mitigations against power and electromagnetic side-channel attacks.

Clocked by the AHB bus clock, the SAES offers very good performance for a DPA resistant hardware accelerator. The SAES engine supports 128-bit or 256-bit keys in electronic code book (ECB), cipher block chaining (CBC), (CTR), (GCM), (CCM), (GMAC) modes.

As shown in Section 4.7 , the SAES can be used for extra-secure on-chip storage for sensitive information.

For more information, refer to Section 36: Secure AES coprocessor (SAES) .

4.8.3 Memory cipher engine (MCE)

Three MCEs propose on-the-fly encryption and decryption on external non volatile or volatile memories. Up to 4 regions can be defined on each MCE, with a granularity of 4 kbytes. Access filtering can be applied on different regions (privilege, write).

When a tamper event is confirmed in TAMP, all MCE keys are erased.

4.9 Product life cycle

The product life cycle of the STM32H7Rx/7Sx is the result of combining the following settings:

Figure 8. Product life-cycle security

Flowchart of Product life-cycle security showing stages: Product development, Product manufacturing, and In the field return.
graph TD; subgraph Product_development [Product development]; Open[Open]; end; subgraph Product_manufacturing [Product manufacturing]; Provisioning[Provisioning]; end; subgraph In_the_field_return [In the field return]; Closed[Closed]; Locked[Locked]; Debug_auth{Debug authentication}; Full_regression[Full regression]; Debug_constrained[Debug constrained]; end; Open --> Provisioning; Provisioning --> Closed; Provisioning --> Locked; Closed --> Debug_auth; Debug_auth --> Full_regression; Debug_auth --> Debug_constrained; Debug_constrained --> Open; Full_regression --> Open;

The diagram illustrates the product life-cycle security flow for the STM32H7Rx/7Sx. It is divided into three main stages: Product development , Product manufacturing , and In the field return .

MSv55538V2

Flowchart of Product life-cycle security showing stages: Product development, Product manufacturing, and In the field return.

Table 24. Product life-cycle states

PRODUCT_STATESelecting PRODUCT_STATEDescription
OpenNVSTATE = OPENThis state allows product development, as it provides the code debug. Using the boot pin allows the bootloader to be launched.
ProvisioningNVSTATE = CLOSE
OEM_PROVD=!0xB4
and/or
DBG_AUTH = Not set (!0xB4, !0x51, !0x8A)		This state allows product provisioning (partial or full). It allows launching of secure firmware Install, or bootloader to provision the product. Boot from SRAM is not permitted.
ClosedNVSTATE = CLOSE
OEM_PROVD=0xB4
DBG_AUTH=0x51 or 0x8A		This state considers that the product configuration is finalized. It allows support of debug authentication for in-the-field repair (read the dedicated application note).
LockedNVSTATE = CLOSE
OEM_PROVD=0xB4
DBG_AUTH=0xB4		This state considers that the product configuration is finalized. The debug authentication is not permitted. The product is definitively in this state.

The features described below contribute to secure the device life-cycle.

4.9.1 Product configurations and security services

The product is provisioned with ST native security services. However, the product can be configured to leave full control of the boot chain to OEMs.

This is done by means of the unique boot entry (FLASH_ROTSRP: IROT_SELECT) option byte. This allows selection between the security services (STiRoT: ST immutable root of trust), or OEM boot implementation (OEM-iROT: OEM immutable root of trust) to be installed in the user part of the flash memory. The product boots on the STiRoT only when the IROT_SELECT is set to STiRoT and when the product state is Closed or Locked.

Security services are provisioned by ST in system flash memory (immutable). They provide the root of trust of the platform managing the verification, and update of the first updatable code (uROT).

STiRoT and OEM-iROT are only available on products embedding cryptographic acceleration (STM32H7Sx).

To ease the product maintenance (in-the-field), we recommend taking advantage of the called debug authentication control feature. This enables product maintenance by activating debug, and makes regression management possible, while considering the security of sensitive information.

This implies setting the product state to provisioning state then provision the DA-config and selecting the final product state (closed)

A dedicated application note is available to help when configuring the debug authentication control of the platform.

4.10 System memory

4.10.1 Introduction

System memory stores RSS (root secure services) firmware programmed by ST during production. The RSS provides runtime services to user firmware.

4.10.2 RSS user functions

The RSS provides runtime services thanks to RSS library, whose functions are exposed to user within the CMSIS device header file provided by the STM32CubeH7RS firmware package (see UM3294 Getting started with STM32CubeH7RS for STM32H7Sx/7Rx MCUs).

RSS provides services through the RSSLIB library, dedicated to secure user firmware. Before calling RSSLIB functions, if MPU is enabled, the secure user firmware must:

Table 25. Macros for RSS services

C defined macroLocation in system memory
RSSLIB_PFUNC0x1FF1FD4C
--

RSSLIB

The user firmware calls RSSLIB functions using RSSLIB_PFUNC C defined macro, which points to a location within non-secure system memory.

Table 26. RSS lib interface functions

LibraryCallable function
RSSLIB_PFUNCSetSecOB (1)
GetRssStatus (1)
SetProductState (1)
DataProvisioning (1)
JumpHDPLvl2
JumpHDPLvl3
GetProductState (1)

1. Functions used for OEM personalization done using provisioning tools.

SetSecOB

Prototype:

uint32_t SetSecOB(uint32_t ObAddr, uint32_t ObMask, uint32_t ObValue,
uint32_t ObPos)

User code function call example:

RSSLIB_PFUNC->SetSecOB((uint32_t) ObAddr, (uint32_t) ObMask, (uint32_t)
ObValue, (uint32_t) ObPos);

Arguments:

The user calls SetSecOB to configure secure OB, the configuration is done by RSS after reset. This function is only available in provisioning product state.

On successful call, the function does not return and does not push LR onto the stack.

In case of failure (bad product state), SetSecOB returns 0xF5F5F5F5.

To retrieve OB change status (after RSS execution), need to call GetRssStatus function or read back the OB (for example read FLASH_WRPSR register).

GetRssStatus

Prototype:

uint32_t GetRssStatus(void)

User code function call example:

RSSLIB_PFUNC->GetRssStatus();

Arguments: None

The user calls GetRssStatus to get RSS execution status of previous RSSLIB function call that trigger a reset for execution by RSS ( SetSecOB or DataProvisioning ).

Returned values:

0xEA EA EA EASuccess
0xF5 F5 F5 F5Error
0xF5 F5 E0 E0Bad input address range
0xF5 F5 E0 EBad size
0xF5 F5 E0 0EBad encryption value in DoEncryption
0xF5 F5 08 80Hardware cryptography not available (H7R)
0xF5 F5 0E E0Encryption error
0xF5 F5 08 08Programming error
0xF5 F5 00 08Bad value in Destination

SetProductState

Prototype:

uint32_t SetProductState(uint32_t ProductState)

User code function call example:

RSSLIB_PFUNC->SetProductState((uint32_t) ProductState);

Arguments:

User calls SetProductState to change STM32 product state, the configuration is done by RSS after reset.

On successful call, the function does not return and does not push LR onto the stack.

To retrieve new product state (after RSS execution), need to call GetProductState function.

In the case of failure (bad product state), SetProductState returns 0xF5F5F5F5.

DataProvisioning

Prototype:

uint32_t DataProvisioning(RSSLIB_DataProvisioningConf_t *pConfig)

User code function call example:

RSSLIB_PFUNC->DataProvisioning((RSSLIB_DataProvisioningConf_t*)pConfig));

Arguments:

pConfig : input parameter. RSSLIB_DataProvisioningConf_t

C structure definition is described below:

typedef struct
{
    uint32_t *pSource;
    uint32_t Destination;
    uint32_t Size;
    uint32_t DoEncryption;
    uint32_t Crc;
} RSSLIB_DataProvisioningConf_t;

Structure elements

  1. pSourceProvides the address of data to be provisioned. Must be within SRAM3 address range.
    DestinationProvides the destination information (where to provision the data).
    0xDADAHHII:
    • – II provides OBKey starting index.
    • – HH provides OBKey HDPL.
    • – DADA provides Debug Authentication configuration, only relevant when OBKey HDPL0.
    SizeProvides the size of data to be provisioned (the number of bytes, must be a multiple of 32).
    DoEncryptionNotifies the DataProvisioning function if it must encrypt or not data within OBKeys.
    DoEncrypt can be either 0xF5F5A0AAU or 0xCACA0AA0U (mandatory on STM32H7Rx)
    • – 0xF5F5A0AAU: notifies the DataProvisioning to encrypt data with relevant AHK before programming it within OBKeys. AHK is selected according to the Destination value.
    • – 0xCACA0AA0U: notifies DataProvisioning to program in clear data within OBKeys.
    CrcCRC over full source data buffer, pConfig->Destination value, pConfig->Size value and finally pConfig->DoEncryption value.
    CRC computation uses CRC-32 (Ethernet):
    • – CRC polynomial: 0x04C11DB7U
    • – Initial value: 0xFFFFFFFFU

Returned values

0xEAEAEAEAUSuccess
0xF5F5F5F5UError: bad product state
DataProvisioning only available in Open product state (encryption not supported) and Provisioning product state (encryption supported only on STM32H7Sx).
0xF5F5E0E0UError: bad input address range.
pConfig or pSource are not in SRAM3
0xF5F5E0EUError: bad provisioning size
– Size is not a multiple of 32
– OBKey starting index + Size does not fit within an OBKey section
0xF5F58080UError: computed CRC is not the expected one provided within pConfig->CRC
0xF5F5E0EUError: wrong DoEncryption parameter value
0xF5F58080UError: OBKeys programming error
0xF5F50008UError: bad Destination information
– OBKey index not in the range 0 to 31
– OBKey HDPL not in the range 0 to 2 (representing HDPL0, HDPL1 and HDPL2)
– On OBKey HDPL0, debug authentication not one of ECDSA, PASSWORD or LOCKED

DataProvisioning receives in input a data buffer and programs it within OBKeys. A CRC prevents any data and parameters tampering issue.

When requested through the pConfig->DoEncryption parameter, DataProvisioning encrypts data before programming them within OBKeys.

DataProvisioning uses AES CBC 128 bits with:

Note: Data encryption within OBKeys is supported only by STM32H7S devices.

JumpHDPLv12

Prototype:

uint32_t JumpHDPLv12(uint32_t VectorTableAddr, uint32_t MPUIndex)

User code function call example:

RSSLIB_PFUNC->JumpHDPLv12((uint32_t)NextVectorTableAddr, 1U );

Arguments:

JumpHDPLvl2. The function enables the MPU region before jumping to the reset handler of the vector table. The vector table reset handler function belongs to the MPU region.

User calls JumpHDPLvl2 to close user Flash HDPL1 area by incrementing HDPL to 2, then jump to the reset handler embedded within the vector table, whose address is passed as input parameter.

After closing HDPL1, JumpHDPLvl2 enables the MPU region provided as input parameter. Once the MPU is enabled, the function sets the SP to the address provided by the passed vector table, and jumps to the reset handler function supported by it. JumpHDPLvl2 does not set the new vector table.

On successful execution, the function does not return and does not push LR onto the stack.

In case of failure (bad input parameter value), JumpHDPLvl2 returns 0xF5F5F5F5.

JumpHDPLvl3

Secure attribute: Secure callable function.

Prototype:

uint32_t JumpHDPLvl3(uint32_t VectorTableAddr, uint32_t MPUIndex)

User code function call example:

RSLLIB_PFUNC->JumpHDPLvl3((uint32_t)NextVectorTableAddr, 1U );

Arguments:

User calls JumpHDPLvl3 to close user Flash HDPL1 and HDPL2 areas by incrementing HDPL up to 3, then jump to the reset handler embedded within the vector table, whose address is passed as input parameter.

After closing HDPL1/2, JumpHDPLvl3 enables the MPU region provided as input parameter. Once the MPU region is enabled, the function sets the SP to the address provided by the passed vector table, and jumps to the reset handler function supported by the vector table. JumpHDPLvl3 does not set the new vector table.

On successful execution, the function does not return and does not push LR onto the stack.

In the case of failure (bad input parameter value), JumpHDPLvl3 returns 0xF5F5F5F5.

GetProductState

Prototype:

uint32_t GetProductState(void)

User code function call example:

RSSLIB_PFUNC->GetProductState();

Arguments: None

User calls GetProductState to get STM32 product state.

In case of failure (bad product configuration), GetProductState returns 0xF5F5F5F5 (Bad state).

On successful call, the function return one of the following product state: