Getting started with STM32H7RS security

Revision as of 16:07, 17 July 2024 by Registered User
This message will disappear after all relevant tasks have been resolved.
Semantic MediaWiki
There are 1 incomplete or pending task to finish installation of Semantic MediaWiki. An administrator or user with sufficient rights can complete it. This should be done before adding new data to avoid inconsistencies.


Introduction

  • If you have already selected the STM32H7RS security solution you need or if you want to try out the different proposed solutions, please refer to chapter1.
  • If you need to define which STM32H7RS security solution is the most suitable for your product, please refer to chapter2.

1. Reference examples

A set of practical examples is proposed to get an overview of and to understand the STM32H7RS security solutions.
These practical examples are based on the boards, tools and code examples provided by ST.

For a self-designed board, all the examples are valid as long as the same external flash and pin mapping as for the Discovery or the Nucleo board have been defined. If it's not the case the examples need to be adapted (external memory flasher, external memory and pin mapping).

More information about the product, including the related tools and software, can be found on the official ST.com pages: STM32H7R3/7S3 and STM32H7R7/7S7

For the examples listed below, each step is described in detail.
It is advised to start with these examples before making your own trials or using other security related examples available in the STM32CubeH7RS.

Product Series STM32H7S picto.png STM32H7S picto.png Prerequisite Introduction article
Development Boards NUCLEO H7S3L8 (MB1737) DISCOVERY H7S78 (MB1167) - -
Embedded flash size 64k 64k - -
On board external flash size 256-Mbit 1-Gbit - -
Debug Authentication
Debug Authentication and Firmware update example Link to How To Link to How To STM32CubeH7RS Link
Code Confidentiality
Code confidentiality on external flash example ^ Link to How To STM32CubeH7RS Link
Immutable Root of Trust (iRoT)
STiRoT example * Link to How To STM32CubeH7RS Link
STM32CubeMX STiRoT example ^ Link to How To STM32CubeMx_V6.11.0 or later Link
STiRoT-OEMuRoT example * Link to How To STM32CubeH7RS Link
OEMiRoT example * Link to How To STM32CubeH7RS Link
  • Note:
    • ^ : supported but no dedicated wiki article example available
    • * : supported for STM32Cube_FW_H7RS_V1.1.0 or later version. The examples provided for the Discovery board needs to be adapted for a Nucleo board, refer to the readme available in \Projects\NUCLEO-H7S3L8\Applications\ROT

1.1. Secure Boot

The secure boot and related root of trust is implicitly used in all the proposed " How to start" step by step examples.
The Security features on STM32H7RS MCUs wiki article also gives technical explanations about the possible boot paths.
The Secure Boot STM32H7RS How to Introduction wiki article gives details about the boot paths used in the different provided getting started examples.

Using STM32CubeMx, a project can be generated from scratch for a chosen boot path.
The table above indicates which example is available to show how to proceed.


1.2. Debug Authentication

It is key to understand how to set the Debug Authentication (DA) in order to define the appropriate rights to reopen the debugger once closed.

  • It is strongly advised to read the Debug Authentication for STM32H7RS wiki article.
  • The Debug Authentication on STM32H7RS how to Introduction wiki article summarizes all the technical know-how to be read before executing the getting started.
  • The How to start with DA access on STM32H7RS wiki article explains step by step how to perform a Debug opening and a Firmware Update.
    • Two examples are described in this article
      • The first example, starting with a device provisioned using the STiRoT example provided in the STM32CubeFW.
      • The second example, starting with a device provisioned using the OEMiRoT example provided in the STM32CubeFW.

1.3. OEMiRoT

An OEM can develop its own customized Immutable Root Of Trust (OEMiRoT).
It is advised to read the Security features on STM32H7RS MCUs wiki article to understand the different possible Root of Trust.

1.4. STiRoT

An immutable root of trust defined by ST is included for the STM32H7S series.
It is an embedded firmware stored in the system flash and it cannot be modified.
It is advised to read the Security features on STM32H7RS MCUs wiki article to understand the different possible Root of Trust.


2. How to choose the security solution you need?

For a product embedding STM32H7RS, very different security solution is required depending on what needs to be protected at which level and which regulation or certification this product has to be complaint to.

The requested security level can be categorized into several profiles:

  1. Without security at all
  2. Confidentiality of the developed application
  3. Debugger access control
  4. Security for IOT products (Internet of Things)
  • Note: It is advised to read the application note: Introduction to security for STM32 MCUs, AN5156.

2.1. Without security at all

  • It could be valid for development phases or demonstrators.
  • But obviously, the know-how of the developed code and the integrity of the product are not protected.
  • Furthermore, the product hardware can be reused to execute any code.
  • Of course, it is not advised for a commercial product

2.2. Confidentiality of the developed application

Confidentiality is the protection of sensitive information from being disclosed to unauthorized parties.

  • When the product is configured, only authorized people should be able to access to the developed code content.
  • On the other hand, confidentiality alone don't protect against different types of attacks, for instance:
    • Don't protect against unauthorized code to be executed (e.g. malware injection)
    • Don't protect against reinstallation of previous code revision (rollback)
    • Don't protect against damages blocking the product to operate correctly (DOS: Denial Of Service)
    • Don't protect the reuse of the product for other usages
    • Don't protect the product against side channel attacks
  • For an example with code confidentiality on external flash:

2.3. Debugger access control

The most obvious access to the device and content is through the debugger (e.g. JTAG/SWD).
The PCB design can be done so that the physical access to the debugger is very difficult.
But depending on the product it could be necessary to keep a solution to access to the debugger.

In any situation, the possibility to close the debugger and allow the reopening only in a very good controlled way is key for the product security.
For the STM32H7RS this feature is provided through the debug authentication.
Refer to the table ... for link to more explanations.

2.4. Security for IOT products (Internet of Things)

Security should be considered for any digital device but is mandatory when the device embeds sensitive data (e.g. people information), is used in a critical environment (e.g. motor control) or can disturb other connected devices.

Connected devices are obviously more subject to attacks.
Attacks on unprotected of not well protected devices can also impact other connected devices even if well protected.
(for instance, DOS (Deny Of Service) attacks on servers).
To limit the risks, regulations are introduced to ensure security for all new IOT devices.
In Europe Radio Equipment Directive (RED) and Cyber Resilience Act (CRA) regulations are coming soon.

  • The recent STM32 products are designed to be ready to fulfil the security regulations.
    • Mandatory features are a Secure Boot and a Secure Firmware Update.
      • The Secure Boot ensures that only unmodified and allowed codes are executed.
      • The Secure Firmware Update ensures that only new unmodified codes are installed (with or without version control). A new code can be needed for firmware evolution but also if applicable to fix a vulnerability.
  • For STM32H7RS two options are proposed to support Secure Boot (SB) & Secure Firmware Update (SFU).
    • The STiRoT (ST Immutable Root of Trust) is a SB & SFU solution embedded in all STM32H7S devices (H7S are devices supporting embedded hardware accelerator).
      • It targets SESIP level 3 certification.
      • STiRoT is natively embedded in the device and can't be modified (immutable).
      • The ST provided solution is using the best of the HW solution and is ready to be used reducing the development cost & effort.
      • A customer can build his own security solution at the top of the STiRoT. To obtain the SESIP level 3 certification, only the added code and data needs to be certified.
      • To certify a product, the significant costs need to be considered: certification lab costs, platform preparation with security expertise (not present in all companies), evaluation target documentation to provide. The STiRoT reduces drastically such costs.
    • The OEMiRoT is a SB & SFU solution developed by a customer or an OEM.
      • For STM32H7RS, ST is providing an OEMiRoT code example that can be modified for own requirements.
      • OEMiRoT is installed in user flash and when protections are set becomes an immutable customized Root of Trust.
      • The STM32H7RS hardware is built to reach SESIP Level 3 certification also with an OEMiRoT security solution. But since OEMiRoT is a customized solution, it's the customer's responsibility to design a solution for his targeted security level and if applicable certification level.
  • Note: STM32H7RS embeds an Arm Cortex-M7 that doesn't support TrustZone. Other ST products based for instance on an Arm Corte-M33 benefit of this additional isolation between two separate running application code.

2.5. Security criteria table

The following table can also help to define which security solution is needed for a defined customer product.

Security Criteria Comment Security solution DA STiRoT OEMiRoT/uRoT Practical example
Confidentiality Code know-how and sensitive data protection Encryption - - - Link to How To
Hardware hijack Prevent reuse of HW to run other application Debug Authentication Introduction article Practical example - -
Debugger (SWD/JTAG) closure Prevent attacks using the debugger - -
Debugger opening to allow regression The owner of the password can perform a full re-initialization (regression) - - Example1 / Example2
Debugger opening to allow regression or debug Code debug and step by step execution by the owner of the key and certificate - - Example1 / Example2
Give debug opening permission to OEM or in the field Give specific authorization using a dedicated certificate - - *Example
Anti-rollback Prevent re-install of old FW version Root of Trust Bootpath introduction - link link
Only authorized code execution Malware protection - Introduction Introduction STiRoT_CubeMx / STiRoT / OEMiRoT
Secure Boot one stage Secure Boot and application execution after authentication and integrity verification - Introduction Introduction STiRoT_CubeMx / STiRoT / OEMiRoT
Secure Boot two stages Additional second customized secure bootstage - - - Example
Secure Firmware update Encrypted FW is only installed after authenticity and integrity verification - link link link
  • Note: * Example provided for another STM32 family product but stay valid.
Retrieved from "https://wiki.st.com/stm32mcu/index.php?title=Security:Getting_started_with_STM32H7RS_security&oldid=56923"