UM2852 STM32U585xx Security Guidance for PSA Certified™ Level 3 with SESIP Profile

Introduction

This document describes how to prepare STM32U585xx microcontrollers to make a secure system solution compliant with SESIP Profile for PSA Level 3 using the STM32Cube_FW_U585_Security_certification_V1.0.0 software package included in the STM32CubeU5 MCU Package. The B-U585I-IOT02A board integrating the STM32U585AI microcontroller is used as the hardware vehicle to implement and test a nonsecure application using secure services, but it does not bring any additional security mechanism. The security guidance described in this document applies to any boards based on STM32U585xx microcontrollers.

UM2852 - Rev 1 - June 2021. For further information, contact your local STMicroelectronics sales office. Visit www.st.com.

1 General Information

The STM32CubeU5 TFM application runs on STM32U585xx 32-bit microcontrollers based on the Arm® Cortex®-M processor. Arm® is a registered trademark of Arm Limited (or its subsidiaries) in the US and/or elsewhere.

List of Acronyms

2 Reference Documents

3 Preparative Procedures

This chapter describes the procedures to prepare the environment and the product before starting to use or test the product.

3.1 Secure Acceptance

Secure acceptance is the process in which the user securely receives the TOE and verifies the integrity and authenticity of all its components. The TOE is distributed as an MCU with a source code package.

The integrator receives the MCU directly from ST via a secure courier. To ensure that the MCU is not manipulated during TOE delivery, the integrator must verify that the user Flash is virgin (reading 0xFF everywhere with STM32CubeProgrammer) or must do an RDP regression (Level 1 -> Level 0) that erases the user Flash.

The software package can be obtained through the standard ST support channels. Note that it is the responsibility of the integrator to choose the correct STM32CubeU5 MCU Package version.

How to accept the STM32U585xx microcontroller:

• Read, using STM32CubeProgrammer (refer to UM2237), the DBGMCU_IDCODE register value (0x20016482) at the 0xE0044000 base address (refer to RM0456).
• Check the bits 0, 2, 5, and 7 of the byte at the 0x0BFA0501 base address in system memory, which should all be set:
• DBGMCU identity code register (DBGMCU_IDCODE): Base address: 0xE0044000, Address offset: 0x00, Reset value: 0x20016482. Bits [31:16] REV_ID[15:0]: revision 0x2001 (revision X). Bits [11:0] DEV_ID[11:0]: device identification (0x482 for STM32U575/585).
• System memory byte at 0x0BFA0501: Bit 7 (DPA enable): 1, Bit 5 (OTFDEC enable): 1, Bit 2 (PKA enable): 1, Bit 0 (AES enable): 1.

How to accept STM32Cube_FW_U585_Security_certification_V1.0.0 software package:

• Compare the SHA256 value of the STM32Cube_FW_U585_Security_certification_V1.0.0.exe file obtained with the sha256sum.exe tool to those in the [Security Target] document.

How to check the complete TOE once implemented on the STM32U585xx chip:

• Compare values in the [Security Target] document to those the TOE provides through the PSA Initial Attestation services (psa_initial_attest_get_token function).
• Hardware version: Contains the decimal format of REV_ID and DEV_ID fields of the DBGMCU_IDCODE register, identifying the STM32U585xx hardware (04080202000001).
• Implementation ID: Contains the SHA256 value computed on the immutable software code part of the TOE (TFM_SBSFU_Boot code binary data). This value is fixed after TOE configuration, corresponding to the immutable part. It changes if the integrator modifies the Flash memory layout or TOE software configuration.
• SPE measurement value: Contains the SHA256 value computed on the up-datable software code part of the TOE (secure image code). This value is related to the TOE and can be verified only if the secure application code is not changed.
• NSPE measurement value: Contains the SHA256 value computed on the non-secure image code. This value is not related to the TOE and changes as soon as the non-secure image code is changed.

These TOE values can be obtained with the following procedure:

1. Run TFM User Application menu, then press #2 (Test TFM), then #7 (TFM - Test EAT).
2. Copy the token response in Middlewares\Third_Party\trustedfirmware\tools\iat-verifier\st_tools\eat.txt.
3. Decode token response from Middlewares\Third_Party\trustedfirmware\tools\iat-verifier\st_tools: python build.py cbor ./eat.txt ./eat.cbor check_iat -k ../../../../../../Projects/B-U585I-IOT02A/Applications/TFM/TFM_SBSFU_Boot/Src/tfm_initial_attestation_key.pem ./eat.cbor -p

The measurement is decoded from the EAT token response obtained and displayed.

3.2 Secure Installation and Secure Preparation of the Operational Environment (AGD_PRE.1.2C)

Installation of the TOE corresponds to generating the binary image and loading it into the MCU memory. For the B-U585I-IOT02A development board, this can be performed using STM32CubeProgrammer via USB. Before installation, the integrator must implement required drivers; for the B-U585I-IOT02A, these are provided in the software package. This section describes the hardware and software setup procedures.

Hardware Setup

To set up the hardware environment, the B-U585I-IOT02A development board must be connected to a personal computer via a USB cable. This connection allows the user to flash the board, interact with it via a UART console, and debug when protections are disabled.

The ST-LINK firmware programmed on the development board must be the V3J8M3 version.

Software Setup

This section lists the minimum requirements for the developer to set up the SDK on a Windows® 10 host, run the sample scenario, and customize applications delivered in the STM32Cube_FW_U585_Security_certification_V1.0.0 software package.

• STM32Cube_FW_U585_Security_certification_V1.0.0 software package: Copy the package to a short path on the Windows® host hard disk, e.g., C:\data.
• Development toolchains and compilers: For security certification, TFM tests use IAR Systems® projects. IAR Embedded Workbench® (version 8.50.6) and its patch for STM32U585xx devices (EWARMv8_STM32U57x-58x_V0.10.zip) must be installed.
• Software tools for programming STM32 microcontrollers: STM32CubeProgrammer (STM32CubeProg) is a multi-OS tool for programming STM32 microcontrollers via debug (JTAG, SWD) or bootloader (UART, USB) interfaces. It supports memory programming, option programming, verification, and automation via scripting. The required version for TFM tests is v2.8.0. Refer to UM2237 for details.
• Terminal emulator: Software like Tera Term (open-source) is needed to display debug information and interact with the non-secure application. Ymodem protocol support is required.

3.3 Secure Installation

The STM32U585xx product preparation involves 4 steps: MCU initialization, software compilation, software programming into the chip's internal Flash memory, and static security protection configuration. All 4 steps must be completed for full security activation.

Refer to UM2851 for the description of these four steps. The TFM_SBSFU_Boot project must be compiled in production mode for security certification.

The certified configuration includes:

• RDP level 2 with password capability
• Two firmware images
• Two slots per firmware image
• Image upgrade in overwrite mode
• Hardware-accelerated cryptography enabled
• RSA 2048 asymmetric crypto scheme
• Image encryption in AES-CTR 128 mode enabled
• Internal Anti-tamper
• Standalone external loader capability
• Application RoT partition disabled

The option bytes configuration for the certified configuration is detailed, including RDP level, SECBOOTADD0, NSBOOTADD0, NSBOOTADD1, BOOT_LOCK, SECWM1, HDP1, WRP1A, SECWM2, HDP2, and WRP2A settings.

Figure 1. Flash memory layout for certified configuration: This figure illustrates the memory partitioning of the STM32U585xx microcontroller's flash memory for the certified configuration. It defines specific areas for bootloader, secure application, non-secure application, and other data, specifying addresses and sizes.

4 Operational User Guidance

4.1 User Roles

The following user roles are distinguished for this TOE:

Integrator

The integrator receives the TOE, performs preparative procedures, and integrates the TOE into a full IoT solution. The integrator is responsible for personalizing product data and configuring security according to STMicroelectronics guidelines. They have full access to the source code, STM32U585xx security features, and programming tools.

4.2 Operational Guidance for the Integrator Role

4.2.1 User-accessible Functions and Privileges (AGD_OPE.1.1C)

The main task of the integrator is to integrate the TOE into a full IoT solution. The system integrator has access to interfaces unavailable to other users. Changes made by the integrator can impact the certified configuration.

Figure 2. TOE scope: This diagram outlines the boundaries of the Target of Evaluation (TOE), indicating which components and memory regions are included in the secure system evaluation. It differentiates between secure and non-secure domains, and potentially privileged versus unprivileged secure domains.

Integrators must follow guidelines to maintain the certified configuration. Failure to do so means the TOE is not used in the certified configuration.

RDP Level

The TOE is certified in RDP level 2 with an OEM2 password, allowing regression to level 1 and then level 0 (which erases Flash). The integrator provides the OEM2 password (64 bits) when RDP is level 0. If the OEM2 password is not defined, RDP level 2 is a final state. Using the certified configuration requires setting RDP to Level 2, and the usage of the OEM2 password is also part of the certified configuration.

Number of Images

The TOE is certified in a 2-image configuration (separate secure and non-secure application binaries). The MCUBOOT_IMAGE_NUMBER define in Linker\flash_layout.h controls this (2 for separate images). A single image configuration is possible for reduced boot time, but the certified configuration requires separated SPE and NSPE images.

Slot Mode

The TOE is certified in primary and secondary slots configuration, allowing over-the-air firmware updates. The MCUBOOT_PRIMARY_ONLY define must be commented out in Linker\flash_layout.h for this configuration. A primary-only slot mode maximizes slot area but prevents over-the-air updates. The certified configuration requires both primary and secondary slots.

Image Upgrade Strategy

The TOE is certified in overwrite mode for image upgrades (applicable with primary/secondary slots). The new image in the secondary slot overwrites the previous one. Reversion is not possible. The MCUBOOT_OVERWRITE_ONLY define must be activated in Linker\flash_layout.h. Swap mode is an alternative but not the certified configuration.

Hardware-Accelerated Cryptography

The TOE is certified with hardware-accelerated cryptography enabled for secure boot, secure firmware update, and TFM cryptography services, improving performance and resistance to side-channel attacks. Activation is done via BL2_HW_ACCEL_ENABLE in TFM_SBSFU_Boot\Inc\config-boot.h and TFM_HW_ACCEL_ENABLE in TFM_Appli\Inc\tfm_mbedcrypto_config.h. Disabling hardware acceleration is possible but not the certified configuration.

Crypto Scheme

The TOE is certified with the RSA 2048 asymmetric cryptoscheme for signing firmware images. This provides a balance between boot time and security. The configuration is set via the CRYPTO_SCHEME define in TFM_SBSFU_Boot\Inc\mcuboot_config\mcuboot_config.h. Other schemes like RSA3072 and ECDSA256 have also been assessed, but RSA2048 is required for the certified configuration.

Image Encryption

The TOE is certified with image encryption capability enabled using AES-CTR 128 mode. This ensures confidentiality of image data. The MCUBOOT_ENC_IMAGES define in TFM_SBSFU_Boot\Inc\mcuboot_config\mcuboot_config.h enables this. Using a clear image is possible but not the certified configuration.

Anti-tamper

The TOE is certified with internal tamper detection enabled, monitoring backup domain voltage and cryptographic IP faults. This is configured by setting TFM_TAMPER_ENABLE to INTERNAL_TAMPER_ONLY in TFM_SBSFU_Boot\Inc\boot_hal_cfg.h. Enabling more tamper detection is possible but not the certified configuration. Disabling internal tamper detection is also possible but not the certified configuration.

Standalone External Loader Capability

The TOE is certified with standalone external loader capability enabled. This loader allows downloading a new firmware image when no valid image is present or when a user button is pressed during reset. The MCUBOOT_EXT_LOADER define in Linker\flash_layout.h enables this. Using a custom loader is possible, but the certified configuration requires using the provided standalone loader without modifications.

TOE Specific Information Personalization

The integrator is responsible for configuring cryptographic keys for image authentication and for computing the token value for platform attestation. These must be kept confidential until provisioned and security is activated. If a trusted environment is not available, the secure firmware installation service (AN4992) can be used. Failure in this responsibility can lead to malicious firmware or incorrect attestation data. Integrators must implement appropriate security measures to protect keys and data. Personalization data is built as Integrator Perso data binary data and programmed in the Integrator Perso data area. Personalization is in the scope of the certified configuration.

Integrator Specific Secure Functions Integration

The integrator can enable the application RoT partition and add its own secure functions in the unprivileged secure domain. This requires using PSA APIs and complying with TOE rules. Memory layout may need adaptation if the secure application exceeds the secure image primary slot size. The TOE is certified without any secured functions in the application RoT. The compilation option TFM_PARTITION_APP_ROT must be de-activated in Linker\flash_layout.h for the certified configuration.

Secure Storage Size Change

The integrator can change the size of secure storage areas (Protected Storage API or Internal Trusted Storage API). While the security of modifying these sizes has been assessed, the certified configuration does not allow modification of secure storage sizes.

Non-secure Application Change

The integrator can change the non-secure application without altering the Flash memory layout defined in UM2851. The certified configuration allows the installation of any non-secure application.

Non-secure Application Size Change

The integrator can change the size of the non-secure application, altering the global internal Flash or SRAM layout. While the security of modifying non-secure image slot sizes has been assessed, the certified configuration does not permit modifying these sizes.

External Memories Use

The integrator can use external Flash or SRAM memories for its non-secure application. However, the certified configuration prohibits the use of external memories for non-secure applications.

TOE Functions Changes

Modifying functions implemented in the TOE software (e.g., replacing cryptographic implementations or removing unused functions) is not within the scope of this evaluation and is not the certified configuration.

4.2.2 Available Interfaces and Methods of Use (AGD_OPE.1.2C and AGD_OPE.1.3C)

The integrator can access different interfaces for product development:

• Physical chip interface
• Secure image secondary slot interface
• Nonsecure image secondary slot interface
• PSA API interface
• JTAG interface
• GPIO port C pin 13 (user button on B-U585I-IOT02A)

There are no specific instructions regarding effective use or security parameters for these functional interfaces, as the TOE implements mechanisms to validate inputs and protect secured data.

Important Note on Extending Security Services: Extending security services in the secure or unprivileged domain (Application RoT services) may compromise other security services or hardware resources due to the lack of isolation between secure services. Therefore:

• Any input from an IoT application must be validated within the Application RoT services API (e.g., bounds checking).
• Be aware of data sent to the IoT application to prevent unintentional leaks of sensitive information.
• Properly handle errors by checking return codes.
• Always initialize or clear allocated memory to prevent residual information leakage.
• API extensions must not modify global system variables; use only local private variables and carefully manage memory to avoid revealing sensitive system variable values (e.g., keys).
• API extension source code must be reviewed and thoroughly tested.
• Use static analysis tools to avoid common bugs (null pointer dereference, memory leaks, buffer overflows).
• Utilize secure coding standards (MITRE, CWE, CERT) to avoid pitfalls and improve code readability.
• Using interfaces other than those described does not fall within the certified configuration and would fail the TRUSTED_INTEGRATOR environment objective.

Physical Chip Interface

After each product power-on or reset, the TOE executes the immutable TFM_SBSFU_Boot application, which manages secure platform initialization.

• Method of use: Power-on the system, reset the STM32U585xx, and run the non-secure application which generates a reset.
• Actions: Execute code at the fixed secure entry point (SECBOOTADD0 address). The TFM_SBSFU_Boot application performs Secure Boot and Secure Firmware Update checks.
• Errors: STM32U585xx option bytes values violation detected by the TOE secure boot procedure will block execution (reset generated, except for RDP option bytes where an infinite loop is executed).

Secure Image Secondary Slot Interface

This interface is used for remote firmware updates of the secure image. A new candidate image is placed here and can be written via physical, wireless, or standalone external loader interfaces. After reset, if magic 16 bytes are present, the TOE attempts to interpret the data as a candidate image and applies it to the secure image primary slot after verification. Invalid images are deleted from the secondary slot.

• Method of use: Write data in the correct image format to the secure image secondary slot area (FLASH_AREA_2_OFFSET) and write the Magic 16 bytes at the slot area end location.
• Parameters: The candidate image is written in the secure image secondary slot.
• Actions: At each product reset, the TOE (TFM_SBSFU_Boot application) checks for a new image in the secure image secondary slot. The new secure image must be programmed at the beginning of the slot and comply with the image format (header, payload, TLV). The TFM_Appli secure project generates the signed binary (e.g., tfm_s_enc_sign.bin). The TFM_SBSFU_Boot application launches the update procedure upon detecting a new image.
• Errors: The candidate image is not installed in the secure image primary slot in case of version dependency failure, image size inconsistency, flash errors, version check failure, or image signature failure. Flash writing/erasing errors may also occur.

Figure 3. Flash layout: This figure presents the memory map of the STM32U585xx flash memory, detailing the organization of various slots and partitions. This includes primary and secondary slots for secure and non-secure images, along with other memory regions utilized by the system.

Figure 4. Image format: This figure describes the structure of a firmware image as expected by the bootloader. It typically includes a header with metadata (e.g., version, image size), the firmware payload, and a Trailer (TLV - Tag-Length-Value) structure, which often contains signature or other verification data.

Non-secure Image Secondary Slot Interface

This interface is used for remote firmware updates of the non-secure image. Similar to the secure image interface, a new candidate non-secure image is placed here. After reset, if magic 16 bytes are present, the TOE attempts to apply it to the non-secure image primary slot after verification. Invalid images are deleted.

• Method of use: Write data in the correct image format to the non-secure image secondary slot area (FLASH_AREA_3_OFFSET) and write the Magic 16 bytes at the slot area end location.
• Parameters: The candidate image is written in the non-secure image secondary slot.
• Actions: At each product reset, the TOE checks for a new image in the non-secure image secondary slot. The new non-secure image must be programmed at the beginning of the slot and comply with the image format. The TFM_Appli non-secure project generates the signed binary (e.g., tfm_ns_enc_sign.bin). The TFM_SBSFU_Boot application launches the update procedure upon detecting a new image.
• Errors: Similar errors as the secure image interface can occur, including version dependency failure, image size inconsistency, flash errors, version check failure, or image signature failure.

PSA API Interface

The PSA API interfaces secure services hosted in the secure application RoT. These APIs are called by the Non-secure world or secure application RoT to trigger secure functionalities. The integrator calls these C APIs and builds a secure application by compiling the TOE source code with application RoT code. Detailed parameters, actions, and error messages are described in the PSA developer APIs [PSA_ST_API], [PSA_CRYPTO_API], and [PSA_ATTESTATION_API].

• Method of use: Call the relevant PSA C functions.
• Parameters: Refer to the PSA API documentation.
• Actions: Execute secure functionalities via the API.
• Errors: Any PSA API access violations result in an infinite loop in the secure domain.

JTAG Interface

Standard JTAG with SWD interface allows debugging. When RDP is Level 2 with an OEM2 password provisioned, debug features are disabled. JTAG/SWD remains enabled under reset only to inject the OEM2 password for RDP regression to level 1.

• Method of use: When RDP is Level 2, inject the OEM2 password using STM32CubeProgrammer CLI command: ./STM32_Programmer_CLI -c port=SWD mode=UR --hardRst -unlockRDP2 <OEM2 password>. The OEM2 password must first be provisioned when RDP is level 0 using: ./STM32_Programmer_CLI -c port=SWD mode=UR --hardRst -lockRDP2 <OEM2 password>.
• Parameters: OEM2 password (64 bits), e.g., 0xFACEB00C 0xDEADBABE.
• Actions: When RDP is level 2 and OEM2 password is injected, RDP changes from level 2 to level 1.
• Errors: RDP level remains set to level 2 if the wrong OEM2 password is provided or if it was not previously provisioned.

GPIO Port C, Pin 13 (User Button on B-U585I-IOT02A)

After reset, the TOE checks the state of GPIO port C pin 13. Depending on its state, the TOE can start a standalone external loader application instead of the secure or non-secure firmware images.

• Method of use: Reset the STM32U585xx and press the user button (GPIO port C pin 13) when the TFM_SBSFU_Boot application is starting execution.
• Parameters: None.
• Actions: After checking static protections and configuring dynamic protections, the TOE starts the standalone external loader, which allows the user to download a new firmware image.
• Errors: The standalone local loader execution fails if the Flash content where the loader is located is corrupted.

4.2.3 Security-Relevant Events (AGD_OPE.1.4C)

Once configured, the TOE detects unauthorized access and unexpected configurations:

• Secure peripheral access violation from any non-secure domain masters (CPU or other masters) generates a reset.
• Secure Memories access violation from non-secure domain (accessing secure memories without going through the secure domain entry point) generates a reset.
• Secure memory or peripheral access privilege violation (secure unprivileged domain accessing Secure privilege domain without going through the privilege domain entry point) resets the product.
• Secure DMA privilege access violation on privilege peripherals from the secure unprivileged domain is transparent (read operations return 0, write operations are ignored).
• Secure DMA privilege access violation on privilege memories from the secure unprivileged domain is transparent; DMA can be used in the secure unprivileged domain.
• Root of Trust Access violation during application execution: After execution, access to the RoT (TFM_SBSFU_Boot) is no longer possible. Access violations from Non-Secure generate a reset. Violations from Secure privilege or unprivileged domains have no effect (reads return 0, writes are ignored, executions are ignored).
• Images authenticity or integrity violation: Corrupted images are detected during the TOE secure boot procedure after reset. The TOE starts the non-secure immutable standalone external loader instead of corrupted images. New valid images can be downloaded and verified. Corruptions during application execution are detected at the next product reset.
• STM32U585xx option bytes values violation: If option bytes are not correctly configured, the TOE secure boot procedure detects the problem and blocks execution (reset generated, except for RDP option bytes where an infinite loop is executed). Option bytes must be correctly programmed and the product reset to unlock.
• PSA APIs violation: Calls to PSA APIs go through a secure or privilege fix entry point managed by the TOE. Access violations result in an infinite loop in the secure domain.
• JTAG access violation: Once TOE security is fully configured, the product cannot be debugged via JTAG. With RDP set to Level 2, JTAG connection is only possible to inject the OEM2 password and obtain device identification.
• Tampering attempt: STM32U585xx anti-tamper mechanisms detect internal tamper events. The product resets upon detected tampering.
• RDP regression: With RDP level 2 and OEM2 password provisioned, regression to level 1 is possible via JTAG/SWD. After reaching level 1, the TOE blocks the boot process in an infinite loop. Regression to level 0 erases all Flash and protected memories. Wrong OEM2 password injection when RDP is level 2 raises an intrusion signal, blocking access to protected memories.
• Protection against debugging: In RDP level 2 with OEM2 password, JTAG debug is not possible. It is possible to revert to RDP level 1, then level 0 (erasing memories). Intrusion signal is raised upon JTAG connection, blocking access to protected memories.

4.2.4 Security Measures (AGD_OPE.1.6C)

To achieve the TRUSTED_INTEGRATOR objective:

• Follow all guidelines described and referenced in Section 3.2.
• Follow all guidelines in Section 4.2.1 and 4.2.2 regarding implementation of user drivers.
• Compile the TOE in production mode (TFM_DEV_MODE compilation switch disabled) to validate the IoT device in the final security configuration.
• Securely provision TOE immutable data specific to the integrator or product.
• Set STM32U585xx hardware static protections to disable JTAG interface debug capability (RDP level 2 with OEM2 password) and lock hardware static protections (RDP Level 2 locks all option bytes).

To achieve TOE_SECRETS:

• Protect the integrity and confidentiality of private cryptographic keys used to build new authentic firmware images.
• Protect the integrity of the immutable part of the TOE (TFM_SBSFU_Boot application) until it is programmed and protected inside the device.
• Personnel involved must have required skills and be aware of security issues.
• If preparative procedures are executed by a third party, the integrator must guarantee sufficient guidance is provided.

To achieve TOE_PERSONALIZATION:

• Implement a system (e.g., a database) for unique data generation (EAT public key, EAT private key). HUK is hardware-hidden and unique per chip.
• Protect the integrity of all TOE personalization data until provisioned and protected inside the TOE. Protect the confidentiality of private cryptographic keys within personalization data.
• Program personalization data in the correct format and location, and protect them (write protection, security protection).

4.2.5 Modes of Operation (AGD_OPE.1.5C)

After reset, the TOE executes the TFM_SBSFU_Boot application. Interfaces are Flash memory slots for new image downloads. The TOE verifies and installs new images or verifies installed images if no new ones are available. If installed images are valid, the TFM_SBSFU_Boot application starts the secure application, which then starts the non-secure application. The non-secure application uses PSA APIs to execute secure services.

If no valid images are installed and no new images are available in secondary slots, the TOE jumps to the standalone external loader application, which can be used to download new images.

If STM32U585xx option bytes are not correctly configured, the TOE secure boot procedure detects the problem, blocks execution, and generates a reset. To unlock, option bytes must be reprogrammed (potentially after RDP regression to level 0). Follow preparation procedures in Section 3.3.

If the TOE detects any violation (as described in Section 4.2.3), it generates a reset.

Revision History

List of Tables

List of Figures