STMicroelectronics X-CUBE-SBSFU User Manual

UM2262

User manual

Getting started with the X-CUBE-SBSFU

STM32Cube Expansion Package

Introduction

This user manual describes how to get started with the X-CUBE-SBSFU STM32Cube Expansion Package.

The X-CUBE-SBSFU Secure Boot and Secure Firmware Update of the STM32 microcontroller built-in program with new firmware versions, adding new features and correcting potential issues. The update process is performed in a secure way to prevent unauthorized updates and access to confidential on-device data.

The Secure Boot (Root of Trust services) is a system reset, that checks STM32 static protections, activates STM32 runtime protections, and then verifies the authenticity and integrity of user application code before every execution to ensure that invalid or malicious code cannot be run.

The Secure Firmware Update application receives the with the Ymodem protocol, checks its authenticity, and checks the integrity of the code before installing it. The firmware update is done on the complete firmware image, or only on a portion of the firmware image. Examples are provided for single-slot configuration to maximize firmware image size, and for dual-slot configuration to ensure safe image installation and enable over-the-air firmware update capability commonly used in IoT devices. For a complex system, the firmware image configuration can be extended up to three images. Examples can be configured to use asymmetric or symmetric cryptographic schemes with or without firmware encryption.

The secure key management services provide cryptog application through the PKCS #11 APIs (KEY ID-based APIs) that are executed inside a protected and isolated environment. User application keys are stored in the protected and isolated environment for their secured update: authenticity check, data decryption, and data integrity check.

STSAFE-A110 is a tamper-resista certified) used to host X509 certificates and keys and perform verifications that are used for firmware image authentication during Secure Boot and Secure Firmware Update procedures.

nt secure element (Hardware Common Criteria EAL5+

n immutable code, always executed after a

firmware image via a UART interface

raphic services to the user

solution allows the update

X-CUBE-SBSFU is built on top of STM32Cube software technology across different STM32 microcontrollers easy. It is provided as a reference code to demonstrate the best use of STM32 security protections.

X-CUBE-SBSFU is classified ECCN 5D002.

October 2020 UM2262 Rev 8 1/103

, making the portability

www.st.com

Contents UM2262

Contents

1 General information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

1.1 Terms and definitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

1.2 References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .11

2 STM32Cube overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

3 Secure Boot and Secure Firmware Update (SBSFU) . . . . . . . . . . . . . . 14

3.1 Product security introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

3.2 Secure Boot . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

3.3 Secure Firmware Update . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

3.4 Cryptography operations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

4 Key management services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

5 Protection measures and security strategy . . . . . . . . . . . . . . . . . . . . . 20

5.1 STM32L4 Series and STM32L0 Series . . . . . . . . . . . . . . . . . . . . . . . . . . 21

5.2 STM32F4 Series, STM32F7 Series, and STM32L1 Series . . . . . . . . . . . 24

5.3 STM32G0 Series, STM32G4 Series, and STM32H7 Series . . . . . . . . . . 26

5.4 STM32WB Series . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

5.5 STM32L4 Series combined with STSAFE-A110 . . . . . . . . . . . . . . . . . . . 32

6 Package description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

6.1 General description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

6.2 Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

6.2.1 STM32CubeHAL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

6.2.2 Board support package (BSP) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

6.2.3 Cryptographic Library . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

6.2.4 Secure Engine (SE) middleware . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

6.2.5 Key management services (KMS) middleware . . . . . . . . . . . . . . . . . . . 38

6.2.6 STSAFE-A middleware . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

6.2.7 Secure Boot and Secure Firmware Upgrade (SBSFU) application . . . . 39

6.2.8 User application . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

6.3 Folder structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

2/103 UM2262 Rev 8

UM2262 Contents

6.4 APIs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

6.5 Application compilation process with IAR™ toolchain . . . . . . . . . . . . . . . 43

7 Hardware and software environment setup . . . . . . . . . . . . . . . . . . . . . 45

7.1 Hardware setup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45

7.2 Software setup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45

7.2.1 Development toolchains and compilers . . . . . . . . . . . . . . . . . . . . . . . . . 45

7.2.2 Software tools for programming STM32 microcontrollers . . . . . . . . . . . 45

7.2.3 Terminal emulator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46

7.2.4 X-CUBE-SBSFU firmware image preparation tool . . . . . . . . . . . . . . . . 46

8 Step-by-step execution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

8.1 STM32 board preparation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48

8.2 Application compilation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51

8.3 Tera Term connection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52

8.3.1 ST-LINK disable . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52

8.3.2 Tera Term launch . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52

8.3.3 Tera Term configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52

8.3.4 Welcome screen display . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54

8.4 SBSFU application execution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54

8.4.1 Download request . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54

8.4.2 Send firmware . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54

8.4.3 File transfer completion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56

8.4.4 System restart . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57

8.5 User application execution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57

8.5.1 Download a new firmware image . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57

8.5.2 Test protections . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59

8.5.3 Test Secure Engine user code . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59

8.6 Programming a new software when the securities are activated . . . . . . . 60

9 Understanding the last execution status message at boot-up . . . . . . 61

Appendix A Secure Engine protected environment . . . . . . . . . . . . . . . . . . . . . . 63

A.1 Firewall-based Secure Engine Isolation . . . . . . . . . . . . . . . . . . . . . . . . . . 64

A.1.1 SE core call gate mechanism . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64

A.1.2 SE interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65

UM2262 Rev 8 3/103

Contents UM2262

A.2 MPU-based Secure Engine Isolation . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66

A.2.1 Principle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66

A.2.2 Constraints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69

Appendix B Dual-slot configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70

B.1 Elements and roles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70

B.2 Mapping definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72

Appendix C Single-slot configuration. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73

C.1 Elements and roles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73

C.2 Mapping definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73

Appendix D Cryptographic schemes handling . . . . . . . . . . . . . . . . . . . . . . . . . . 74

D.1 Cryptographic schemes contained in this package. . . . . . . . . . . . . . . . . . 74

D.2 Asymmetric verification and symmetric encryption schemes . . . . . . . . . . 75

D.2.1 Cryptographic schemes with full software implementation . . . . . . . . . . . 75

D.2.2 AES CTR decryption with OTFDEC peripheral . . . . . . . . . . . . . . . . . . . 76

D.3 Symmetric verification and encryption scheme. . . . . . . . . . . . . . . . . . . . . 77

D.4 X509 certificate-based asymmetric scheme without firmware encryption. 78

D.5 Asymmetric verification and symmetric encryption schemes . . . . . . . . . . 79

D.6 Secure Boot and Secure Firmware Update flow . . . . . . . . . . . . . . . . . . . . 80

Appendix E Firmware image preparation tool . . . . . . . . . . . . . . . . . . . . . . . . . . . 82

E.1 Tool location . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82

E.2 Inputs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82

E.3 Outputs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83

E.4 IDE integration. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83

E.5 Partial Image . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84

Appendix F KMS. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85

F.1 Key update process description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85

F.2 SBSFU static keys generation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86

F.3 Using KMS & X509 cryptographic scheme . . . . . . . . . . . . . . . . . . . . . . . . 87

F.4 UserApp menu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88

4/103 UM2262 Rev 8

UM2262 Contents

Appendix G SBSFU with STM32 and STSAFE-A110 . . . . . . . . . . . . . . . . . . . . . . 90

G.1 Introduction to STSAFE-A110 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90

G.2 Certificate generation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92

G.3 STSAFE-A110 provisioning. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93

G.4 STM32 and firmware image provisioning . . . . . . . . . . . . . . . . . . . . . . . . . 93

G.5 STSAFE-A110 ordering. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94

Appendix H STM32WB Series specificities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95

H.1 Compilation process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95

H.2 Key provisioning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95

Appendix I STM32H7 Series specificities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96

I.1 JTAG connection capability with configured secure memory . . . . . . . . . . 96

I.2 External Flash on STM32H7B3 devices . . . . . . . . . . . . . . . . . . . . . . . . . . 96

Appendix J Validation of the new firmware image . . . . . . . . . . . . . . . . . . . . . . . 99

Revision history . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101

UM2262 Rev 8 5/103

List of tables UM2262

List of tables

Table 1. List of acronyms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

Table 2. List of terms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

Table 3. Cryptographic scheme comparison . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

Table 4. MPU regions in the STM32F4 Series, STM32F7 Series, and STM32L1 Series. . . . . . . . . 26

Table 5. MPU regions in the STM32G0 Series, STM32G4 Series, and STM32H7 Series. . . . . . . . 28

Table 6. Error messages at boot-up . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61

Table 7. MPU regions for Secure Engine isolation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67

Table 8. Cryptographic scheme list . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74

Table 9. Document revision history . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101

6/103 UM2262 Rev 8

UM2262 List of figures

List of figures

Figure 1. Secure Boot Root of Trust . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

Figure 2. Typical in-field device update scenario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

Figure 3. KMS functions overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

Figure 4. SBSFU security IPs vs. STM32 Series (1 of 2). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

Figure 5. SBSFU security IPs vs. STM32 Series (2 of 2). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

Figure 6. STM32L4 and STM32L0 protection overview during SBSFU execution . . . . . . . . . . . . . . 22

Figure 7. STM32F4, STM32F7 and STM32L1 protection overview during SBSFU execution . . . . . 24

Figure 8. STM32G0, STM32G4, and STM32H7 protection overview during SBSFU execution . . . . 26

Figure 9. STM32G0, STM32G4, and STM32H7 protection overview

during user application execution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

Figure 10. STM32WB protection overview during SBSFU execution . . . . . . . . . . . . . . . . . . . . . . . . . 30

Figure 11. STM32L4 / STSAFE-A110 protection overview during SBSFU execution . . . . . . . . . . . . . 32

Figure 12. Software architecture overview. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

Figure 13. Project folder structure (1 of 2) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

Figure 14. Project folder structure (2 of 2) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

Figure 15. Application compilation steps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44

Figure 16. Firmware image preparation tool IDE integration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46

Figure 17. Step-by-step execution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

Figure 18. STM32 board preparation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48

Figure 19. STM32CubeProgrammer connection menu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49

Figure 20. STM32CubeProgrammer Option bytes screen. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50

Figure 21. STM32CubeProgrammer erasing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50

Figure 22. STM32CubeProgrammer connection menu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51

Figure 23. Tera Term connection screen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52

Figure 24. Tera Term setup screen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53

Figure 25. SBSFU welcome screen display. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54

Figure 26. SBSFU encrypted firmware transfer start . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55

Figure 27. SBSFU encrypted firmware transfer in progress . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55

Figure 28. SBSFU reboot after encrypted firmware transfer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56

Figure 29. User application execution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57

Figure 30. Encrypted firmware download via a user application . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58

Figure 31. User application test protection menu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59

Figure 32. Option Bytes menu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60

Figure 33. FLASH mass deletion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60

Figure 34. Firewall call gate mechanism . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64

Figure 35. Secure Engine call-gate mechanism . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65

Figure 36. Secure Engine interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66

Figure 37. SBSFU running in the unprivileged level of software execution for standard operations . . 67

Figure 38. SBSFU requesting a Secure Engine service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68

Figure 39. Exiting a Secure Engine service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69

Figure 40. Internal user Flash mapping: Example of the NUCLEO-L476RG with 512-byte headers . 71

Figure 41. User application vector table (example of the STM32L4 Series) . . . . . . . . . . . . . . . . . . . . 72

Figure 42. Asymmetric verification and symmetric encryption . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75

Figure 43. AES CTR decryption with OTFDEC peripheral. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76

Figure 44. Symmetric verification and encryption . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77

Figure 45. X509 asymmetric verification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78

Figure 46. Certificate chain . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79

Figure 47. SBSFU dual-slot boot flows . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80

UM2262 Rev 8 7/103

List of figures UM2262

Figure 48. SBSFU single-slot boot flows . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81

Figure 49. Encrypted object creation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85

Figure 50. Secure update procedure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86

Figure 51. KMS key storage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87

Figure 52. Certificate chain overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88

Figure 53. KMS menu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89

Figure 54. Certificate chain overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91

Figure 55. Pairing key and certificate provisioning overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92

Figure 56. Batch files using openssl . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93

Figure 57. Provisioning in STM32 and firmware image . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94

Figure 58. Compile with Loader integration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95

Figure 59. JTAG connection capability on STM32H7B3 Series and STM32H753 Series . . . . . . . . . . 96

Figure 60. STM32H7B3: MPU isolation + secure user memory, with external Flash . . . . . . . . . . . . . 97

Figure 61. Memory mapping for STM32H7B3 devices with external Flash . . . . . . . . . . . . . . . . . . . . . 98

Figure 62. Image state handling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99

8/103 UM2262 Rev 8

UM2262 General information

1 General information

The X-CUBE-SBSFU Expansion Package comes with examples running on the STM32L4

Series, STM32F4 Series, STM32F7 Series, STM32G0 Series, STM32G4 Series, STM32H7

Series, STM32L0 Series, STM32L1 Series, and STM32WB Series. An example combining

STM32 microcontroller and STSAFE-A110 is also provided for the STM32L4 Series.

X-CUBE-SBSFU is provided as a reference code

examples demonstrating the best use of STM32 protections to protect assets against

unauthorized external and internal access. X-CUBE-SBSFU proposes also a system

solution example combining STM32 and STSAFE-A110, which demonstrates Hardware

Secure Element protections for secure authentication services and secure data storage.

X-CUBE-SBSFU is a starting point for OEMs to develop

product security requirement levels.

The X-CUBE-SBSFU Secure Boot and Secure

on STM32 32-bit microcontrollers based on the Arm

1.1 Terms and definitions

Tabl e 1 presents the definition of acronyms that are relevant for a better understanding of

this document.

Acronym Description

AAD Additional authenticated data

AES Advanced encryption standard

CBC AES cipher block chaining

for standalone STM32 system solution

their SBSFU as a function of their

Firmware Update Expansion Package runs

®(a)

Cortex®-M processor.

Table 1. List of acronyms

CKS Customer key storage

CTR AES counter-based cipher mode

DMA Direct memory access

DSA Digital signature algorithm

ECC Elliptic curve cryptography

ECCN Export control classification number

ECDSA Elliptic curve digital signature algorithm

FSM Finite-state machine

GCM AES Galois/counter mode

GUI Graphical user interface

HAL Hardware abstraction layer

a. Arm is a registered trademark of Arm Limited (or its subsidiaries) in the US and/or elsewhere.

UM2262 Rev 8 9/104

102

General information UM2262

Table 1. List of acronyms (continued)

Acronym Description

IDE Integrated development environment

IV Initialization vector

IWDG Independent watchdog

FW Firmware

FWALL Firewall

KMS Key management services

MAC Message authentication code

MCU Microcontroller unit

MPU Memory protection unit

NONCE Number used only once

OTFDEC On-the-fly decryption

PCROP Proprietary code read-out protection

PEM Privacy enhanced mail

RDP Read protection

SB Secure Boot

SE Secure Engine

SFU Secure Firmware Update

SM State machine

UART Universal asynchronous receiver/transmitter

UUID Universally unique identifier

WRP Write protection

Tabl e 2 presents the definition of terms that are relevant for a better understanding of this

document.

Term Description

Firmware image A binary image (executable) is run by the device as a user application.

Firmware header

mbedTLS

Bundle of meta-data describing the firmware image to be installed. It contains firmware information and cryptographic information.

mbed implementation of the TLS and SSL protocols and the respective cryptographic algorithms.

sfb file Binary file packing the firmware header and the firmware image.

Table 2. List of terms

10/104 UM2262 Rev 8

UM2262 General information

1.2 References

STMicroelectronics related documents

Public documents are available online from the STMicroelectronics website at www.st.com.

Contact STMicroelectronics when more information is needed.

1. Application note Integration guide for the X-CUBE-SBSFU STM32Cube Expansion Package (AN5056)

2. Application note Introduction to STM32 microcontrollers security (AN5156)

3. User manual STM32CubeProgrammer software description (UM2237)

4. Data sheet Authentication, state-of-the-art security for peripherals and IoT devices (DS12911)

2 STM32Cube overview

What is STM32Cube?

STM32Cube is an STMicroelectronics original initiative to significantly improve designer's productivity by reducing development effort, time, and cost. STM32Cube covers the whole STM32 portfolio.

STM32Cube includes:

• A set of user-friendly software development tools to cover project development from the conception to the realization, among which:

– STM32CubeMX, a graphical software configuration tool that allows the automatic

generation of C initialization code using graphical wizards

– STM32CubeIDE, an all-in-one development tool with peripheral configuration,

code generation, code compilation, and debug features

– STM32CubeProgrammer (STM32CubeProg), a programming tool available in

graphical and command-line versions

– STM32CubeMonitor-Power (STM32CubeMonPwr), a monitoring tool to measure

and help in the optimization of the power consumption of the MCU

• STM32Cube MCU & MPU Packages, comprehensive embedded-software platforms specific to each microcontroller and microprocessor series (such as STM32CubeL4 for the STM32L4 Series), which include:

– STM32Cube hardware abstraction layer (HAL), ensuring maximized portability

across the STM32 portfolio

– STM32Cube low-layer APIs, ensuring the best performance and footprints with a

high degree of user control over the hardware

– A consistent set of middleware components such as FAT file system, RTOS, USB

Host and Device, TCP/IP, Touch library, and Graphics

– All embedded software utilities with full sets of peripheral and applicative

examples

• STM32Cube Expansion Packages, which contain embedded software components that complement the functionalities of the STM32Cube MCU & MPU Packages with:

– Middleware extensions and applicative layers

– Examples running on some specific STMicroelectronics development boards

How does this software complement STM32Cube?

The proposed software is based on the STM32CubeHAL, the hardware abstraction layer for the STM32 microcontroller. The package extends STM32Cube by providing middleware components:

• Secure Engine for managing all critical data and operations, such as cryptography operations accessing firmware encryption key and others

• Key management services offering cryptographic services via PKCS #11 APIs

• STSAFE-A for managing Hardware Secure Element features

12/104 UM2262 Rev 8

UM2262 STM32Cube overview

The package includes different sample applications to provide a complete SBSFU solution:

• SE_CoreBin application: provides a binary including all the ‘trusted’ code.

• Secure Boot and Secure Firmware Upgrade (SBSFU) application:

– Secure Boot (Root of Trust)

– Local download via UART Virtual COM

– FW installation management

• User application:

– Downloads a new firmware in the dual-slot mode of operation

– Provides examples of testing protection mechanisms

– Provides examples using KMS APIs

The sample applications are delivered in dual-slot and single-slot modes of operation and can be configured in different cryptographic schemes.

Note: The single-slot configuration is demonstrated in examples named 1_Image.

The dual-slot configuration is demonstrated in examples named 2_Images.

This user manual describes the typical use of the package:

• Based on the NUCLEO-L476RG board

• With sample applications operating in dual-slot mode and configured with asymmetric

authentication and symmetric FW encryption

More information about the configuration options and the single-slot mode of operation are provided in the appendices of this document.

Note: The KMS feature is available on the STM32L4 Series with the example provided on the B-

L475E-IOT01A and B-L4S5I-IOT01A boards.

Note: The STSAFE-A110 feature is available on the STM32L4 Series with an example provided

on the B-L4S5I-IOT01A board.

UM2262 Rev 8 13/104

102

Secure Boot and Secure Firmware Update (SBSFU) UM2262

3 Secure Boot and Secure Firmware Update (SBSFU)

3.1 Product security introduction

A device deployed in the field operates in an untrusted environment and it is therefore subject to threats and attacks. To mitigate the risk of attack, the goal is to allow only authentic firmware to run on the device. Allowing the update of firmware images to fix bugs, or introduce new features or countermeasures, is commonplace for connected devices, but it is prone to attacks if not executed securely.

Consequences may be damaging such as firmware cloning, malicious software download, or device corruption. Security solutions have to be designed to protect sensitive data (potentially even the firmware itself) and critical operations.

Typical countermeasures are based on cryptography (with an associated secret key) and memory protections:

• Cryptography ensures integrity (the assurance that data has not been corrupted), authentication (the assurance that a certain entity is who it claims to be) and confidentiality (the assurance that only authorized users can read sensitive data) during firmware transfer.

• Memory protection mechanisms prevent external attacks (for example by accessing the device physically through JTAG) and internal attacks from other embedded processes.

The following chapters describe solutions implementing confidentiality, integrity, and authentication services to address the most common threats for an IoT end-node device.

3.2 Secure Boot

Secure Boot (SB) asserts the integrity and authenticity of the user application image that is executed: cryptographic checks are used to prevent any unauthorized or maliciously modified software from running. The Secure Boot process implements a Root of Trust (refer to Figure authenticated (2) before its execution (3).

The integrity is verified to be sure that the image that is going to be executed has not been corrupted or maliciously modified.

An authenticity check aims to verify that the firmware image is coming from a trusted and known source to prevent unauthorized entities to install and execute code.

1): starting from this trusted component (1), every other component is

14/104 UM2262 Rev 8

UM2262 Secure Boot and Secure Firmware Update (SBSFU)

Figure 1. Secure Boot Root of Trust

3.3 Secure Firmware Update

Secure Firmware Update (SFU) provides a secure implementation of in-field firmware updates, enabling the download of new firmware images to a device in a secure way.

As shown in Figure 2, two entities are typically involved in a firmware update process:

• Server

– OEM manufacturer server/web service

– Stores the new version of device firmware

– Communicates with the device and sends the new image version in an encrypted

form if it is available

• Device

– Deployed in the field

– Embeds a code running firmware update process.

– Communicates with the server and receives a new firmware image.

– Authenticates decrypts and installs the new firmware image then executes it.

Figure 2. Typical in-field device update scenario

UM2262 Rev 8 15/104

102

Secure Boot and Secure Firmware Update (SBSFU) UM2262

Firmware update runs through the following steps:

1. If a firmware update is needed, a new encrypted firmware image is created and stored in the server.

2. The new encrypted firmware image is sent to the device deployed in the field through an untrusted channel.

3. The new image is downloaded, checked, and installed.

The firmware update can be done on the complete firmware image, or only on a portion of the firmware image (only for dual-slot configuration).

The firmware update is vulnerable to the threats presented in Section 3.1: Product security

introduction: cryptography is used to ensure confidentiality, integrity, and authentication.

The confidentiality is implemented to protect the firmware image, which may be a key asset for the manufacturer. The firmware image sent over the untrusted channel is encrypted so that only devices having access to the encryption key can decrypt the firmware package.

The integrity is verified to be sure that the received image is not corrupted.

The authenticity check aims to verify that the firmware image is coming from a trusted and known source, to prevent unauthorized entities to install and execute code.

3.4 Cryptography operations

The X-CUBE-SBSFU STM32Cube Expansion Package is delivered with four cryptographic schemes using both asymmetric and symmetric cryptography.

The default cryptographic scheme demonstrates ECDSA asymmetric cryptography for firmware verification and AES-CBC symmetric cryptography for firmware decryption. Thanks to asymmetric cryptography, the firmware verification can be performed with publickey operations so that no secret information is required in the device.

The alternative cryptographic schemes provided in the X-CUBE-SBSFU Expansion Package are:

• ECDSA asymmetric cryptography for firmware verification with AES-CBC or AES-CTR symmetric cryptography for firmware encryption

• ECDSA asymmetric cryptography for firmware verification without firmware encryption

• X509 certificate-based ECDSA asymmetric cryptography for firmware verification

without firmware encryption

• AES-GCM symmetric cryptography for both firmware verification and encryption.

Tabl e 3 presents the various security features associated with each of the cryptographic

schemes.

16/104 UM2262 Rev 8

UM2262 Secure Boot and Secure Firmware Update (SBSFU)

Features

Asymmetric

with AES encryption

Table 3. Cryptographic scheme comparison

Asymmetric

without encryption

X509 certificate-based

asymmetric without

encryption

Symmetric

(AES-GCM)

(1)

AES-CBC encryption, or AES-CTR

Confidentiality

encryption for STM32 MCUs supporting

No, the user FW is in a clear format.

AES-GCM encryption

(FW binary) OTFDEC processing (FW binary)

Integrity SHA256 (FW header and FW binary)

Authentication

Cryptographic keys in device

1. For the symmetric cryptographic scheme, it is highly recommended to configure a unique symmetric key for each product.

– SHA256 of the FW header is ECDSA signed – SHA256 of the FW binary stored in FW header

Private AES-CBC / AES-CTR key (secret)

Public ECDSA key

Public ECDSA key in X509 certificate chain (stored in STSAFE-A or KMS)

AES-GCM Tag

(FW header and FW

binary)

Private AES-GCM

key (secret)

UM2262 Rev 8 17/104

102

Key management services UM2262

4 Key management services

Key management services (KMS) middleware provides cryptographic services through the standard PKCS #11 APIs (specified by OASIS) allowing to abstract the key value to the caller (using object ID and not directly the key-value). KMS is executed inside a protected/isolated environment to ensure that key value cannot be accessed by an unauthorized code running outside the protected/isolated environment.

KMS also offers the possibility to use cryptographic services with keys that are managed securely outside the STM32 microcontroller, such as by an STSAFE-A110 Secure Element for example (rooting based on token ID).

KMS only supports a subset of PKCS #11 APIs:

• Object management functions: creation / update / deletion

• AES encryption functions

• AES decryption functions

• Digesting functions

• RSA and ECDSA Signing/Verifying functions

• Key management functions: key generation/derivation

KMS manages three types of keys:

• Static Embedded keys:

– Predefined keys are embedded within the code. Such keys can't be modified.

• Updatable keys with Static ID:

– Keys IDs are predefined in the system

– The key value can be updated in an NVM storage via a secure procedure using

static embedded root keys (authenticity check, data integrity check, and data decryption)

– Key cannot be deleted

• Updatable keys with dynamic ID:

– Key IDs are defined when creating the keys

– The key value is created using internal functions. Typically, the DeriveKey()

function creates dynamic objects.

– Key can be deleted

18/104 UM2262 Rev 8

UM2262 Key management services

Figure 3. KMS functions overview

For more details regarding the OASIS PKCS #11 standard, refer to [5].

UM2262 Rev 8 19/104

102

Protection measures and security strategy UM2262

5 Protection measures and security strategy

Cryptography ensures integrity, authentication, and confidentiality. However, the use of cryptography alone is not enough: a set of measures and system-level strategies are needed for protecting critical operations and sensitive data (such as a secret key), and the execution flow, to resist possible attacks.

Secure software coding techniques such as doubling critical tests, doubling critical actions, checking parameters values, and testing a flow control mechanism, are implemented to resist basic fault-injection attacks.

The security strategy is based on the following concepts:

• Ensure single entry point at reset: force code execution to start with Secure Boot code

• Make SBSFU code and SBSFU secrets immutable: no possibility to modify or alter

them once security is fully activated

• Create a protected enclave isolated from SBSFU application and user applications to store secrets such as keys, and to run critical operations such as cryptographic algorithms

• Limit surface execution to SBSFU code during SBSFU application execution

• Remove JTAG access to the device

• Monitor the system: intrusion detection and SBSFU execution time

Figure 4 and Figure 5 give a high-level view of the security mechanisms activated on each

STM32 Series.

Figure 4. SBSFU security IPs vs. STM32 Series (1 of 2)

20/104 UM2262 Rev 8

UM2262 Protection measures and security strategy

Figure 5. SBSFU security IPs vs. STM32 Series (2 of 2)

5.1 STM32L4 Series and STM32L0 Series

Figure 6 illustrates how the system, the code, and the data are protected in the

X-CUBE-SBSFU application example for the STM32L4 Series and STM32L0 Series.

UM2262 Rev 8 21/104

102

Protection measures and security strategy UM2262

Figure 6. STM32L4 and STM32L0 protection overview during SBSFU execution

22/104 UM2262 Rev 8

UM2262 Protection measures and security strategy

Protections against outer attacks

Outer attacks refer to attacks triggered by external tools such as debuggers or probes, trying to access the device. In the SBSFU application example, RDP, tamper, DAP, and IWDG protections are used to protect the product against outer attacks:

• RDP (Read Protection): Read Protection Level 2 is mandatory to achieve the highest level of protection and to implement a Root of Trust:

– External access via the JTAG hardware interface to RAM and Flash is forbidden.

This prevents attacks aiming to change SBSFU code and therefore mining the Root of Trust.

– Option bytes cannot be changed. This means that other protections such as WRP

and PCROP cannot be changed anymore.

Caution - RDP level 1 is not proposed for the following reasons:

1. Secure Boot / Root of Trust (single entry point and immutable code) cannot be ensured, because Option bytes (WRP) can be modified in RDP L1.

2. Device internal flash can be fully reprogrammed (after flash mass erase via RDP L0 regression) with a new FW without any security.

3. Secrets in RAM protected by the firewall can be accessed by attaching the debugger via the JTAG hardware interface on a system reset.

In case JTAG hardware interface access is not possible at customer product, and in case the customer uses a trusted and reliable user application code, then the abovehighlighted risks are not valid.

• Tam p e r : the anti-tamper protection is used to detect physical tampering actions on the device and to take related countermeasures. In the case of tampering detection, the SBSFU application example forces a reboot.

• DAP (Debug Access Port): the DAP protection consists of de-activating the DAP (Debug Access Port). Once de-activated, JTAG pins are no longer connected to the STM32 internal bus. DAP is automatically disabled with RDP Level 2.

• IWDG (Independent Watchdog): IWDG is a free-running down-counter. Once running, it cannot be stopped. It must be refreshed periodically before it causes a reset. This mechanism allows the control of SBSFU execution duration.

Protections against inner attacks

Inner attacks refer to attacks triggered by code running in the STM32. Attacks may be due to either malicious firmware exploiting bugs or security breaches, or unwanted operations. In the SBSFU application example, WRP, firewall, PCROP, and MPU protections preserve the product from inner attacks:

• FWALL (firewall): the firewall is configured to protect the code, volatile and non-volatile data. Protected code is accessible through a single entry point (the call gate mechanism is described in Appendix A). Any attempt to jump and try to execute any of the functions included in the code section without passing through the entry point generates a system reset. In the KMS example, keys and cryptographic services are executed inside the isolated environment under firewall protection.

UM2262 Rev 8 23/104

102

Protection measures and security strategy UM2262

• PCROP

(1)

(proprietary code readout protection): a section of Flash memory is defined as execute-only through PCROP protection. It is not possible to access this section in reading nor writing. Being an execute-only area, a key is protected with PCROP only if it is ‘embedded’ in a piece of code: executing this code moves the key to a specific pointer in RAM. Placed behind the firewall, its execution is not possible from outside.

• WRP (write protection): write protection is used to protect trusted code from external attacks or even internal modifications such as unwanted writings/erase operations on critical code/data.

• MPU (memory protection unit): the MPU is used to make an embedded system more robust by splitting the memory map for Flash and SRAMs into regions having their access rights. In the SBSFU application example, MPU is configured to ensure that no other code is executed from any memories during SBSFU code execution. When leaving the SBSFU application, the MPU configuration is updated to authorize also the execution of the user application code.

1. Read protection is tightly coupled with write protection for the STM32L0 Series: when activated, any readprotected sector is also write-protected. For this reason, read protection cannot be activated.

5.2 STM32F4 Series, STM32F7 Series, and STM32L1 Series

Figure 7 illustrates how the system, the code, and the data are protected in the

X-CUBE-SBSFU application example for the STM32F4 Series, STM32F7 Series, and STM32L1 Series.

Figure 7. STM32F4, STM32F7 and STM32L1 protection overview during SBSFU execution

24/104 UM2262 Rev 8

UM2262 Protection measures and security strategy

Protections against outer attacks

• RDP (Read Protection): Read Protection Level 2 is mandatory to achieve the highest level of protection and to implement a Root of Trust:

– External access via the JTAG hardware interface to RAM and Flash is forbidden.

This prevents attacks aiming to change SBSFU code and therefore mining the Root of Trust.

– Option bytes cannot be changed. This means that other protections such as WRP

and PCROP cannot be changed anymore.

Caution - RDP level 1 is not proposed for the following reasons:

1. Secure Boot / Root of Trust (single entry point and immutable code) cannot be ensured, because Option bytes (WRP) can be modified in RDP L1.

2. Device internal flash can be fully reprogrammed (after flash mass erase via RDP L0 regression) with a new FW without any security.

3. Secrets in RAM protected by the firewall can be accessed by attaching the debugger via the JTAG hardware interface on a system reset.

In case JTAG hardware interface access is not possible at customer product, and in case the customer uses a trusted and reliable user application code, then the abovehighlighted risks are not valid.

Protections against inner attacks

Inner attacks refer to attacks triggered by code running in the STM32. Attacks may be due to either malicious firmware exploiting bugs or security breaches, or unwanted operations. In the SBSFU application example, WRP and MPU protections preserve the product from inner attacks:

• WRP (write protection): write protection is used to protect trusted code from external attacks or even internal modifications such as unwanted writing or erase operations on critical code or data.

• MPU (memory protection unit): the protected environment managing all critical data and operations (Secure Engine) is isolated from the other software components by leveraging the MPU. The Secure Engine code and data can be accessed only through a privileged level of software execution. Therefore, software running at a non-privileged level cannot call the Secure Engine services nor access the critical data. This strict access control to Secure Engine services and resources is implemented by defining specific MPU regions as described in Table 4 .

UM2262 Rev 8 25/104

102

Protection measures and security strategy UM2262

Table 4. MPU regions in the STM32F4 Series, STM32F7 Series, and STM32L1 Series

Region content Privileged permission Unprivileged permission

Secure Engine code & constants

Secure Engine stack & VDATA

Read Only

(execution allowed)

Read Write

(not executable)

No access

Besides, the MPU also ensures that only authorized code is granted execution permission when the Secure Boot and Secure Firmware Update processes are running. This is the reason why the MPU configuration is updated before launching the user application to authorize its execution. Nevertheless, the Secure Engine isolation settings and supervisor call mechanisms still apply when running the user application (not only when running the SBSFU code).

5.3 STM32G0 Series, STM32G4 Series, and STM32H7 Series

Figure 8 illustrates how the system, the code, and the data are protected in the

X-CUBE-SBSFU application example for the STM32G0 Series, STM32G4 Series, and STM32H7 Series.

For the specificities of STM32H7B3 devices, refer to appendix I.2: External Flash on

STM32H7B3 devices.

Figure 8. STM32G0, STM32G4, and STM32H7 protection overview during SBSFU execution

26/104 UM2262 Rev 8

UM2262 Protection measures and security strategy

Protections against outer attacks

RDP (Read Protection):

• Read Protection Level 2 allows achieving the highest level of protection and to implement a Root of Trust.

– External access via the JTAG HW interface to RAM and Flash is forbidden. This

prevents attacks aiming to change SBSFU code and therefore mining the Root of Trust.

– Option bytes cannot be changed. This means that other protections such as WRP

and PCROP cannot be changed anymore.

• Read Protection level 1 allows achieving a lower level of protection than RDP level 2 for the following reasons:

– Code / Data stored in internal Flash can be modified (removing immutability), once

Option bytes (WRP) is reset (not possible in RDP Level 2).

– Device internal flash can be fully reprogrammed in RDP level 1 (after Flash mass

erase via RDP L0 regression) with a new FW without any security.

– Secrets in RAM can be accessed by attaching the debugger via the JTAG HW

interface on a system reset

• Read Protection Level 0 does not support any protection and full product access is allowed.

(1)

Secure Boot / Root of Trust: After reset, that part of the customer code is forced to run first using the BOOT_Lock configuration. It is isolated from the rest of the runtime FW using the Securable memory area protection.

Tamper: The anti-tamper protection is used to detect physical tampering actions on the device and to take related countermeasures. In the case of tampering detection, the SBSFU application example forces a reboot.

DAP (Debug Access Port): The DAP protection consists of de-activating the DAP (Debug Access Port). Once de-activated, JTAG pins are no longer connected to the STM32 internal bus. DAP is automatically disabled with RDP Level 2.

IWDG (Independent Watchdog): IWDG is a free-running down-counter. Once running, it cannot be stopped. It must be refreshed periodically before it causes a reset. This mechanism allows the control of SBSFU execution duration.

1. Not possible on the STM32H7 Series. Refer to Appendix If or more details.

UM2262 Rev 8 27/104

102

Protection measures and security strategy UM2262

Protections against inner attacks: Inner attacks refer to attacks triggered by code

running in the STM32. Attacks may be due to either malicious firmware exploiting bugs or security breaches, or unwanted operations.

In the SBSFU application example, PCROP, WRP, and MPU protections preserve the product from inner attacks:

• PCROP (proprietary code readout protection): a section of Flash is defined as execute- only through PCROP protection. It is not possible to access this section in reading nor writing. Being an execute-only area, a key is protected with PCROP only if it is ‘embedded’ in a piece of code: executing this code moves the key to a specific pointer in RAM. Placed behind the firewall, its execution is not possible from outside.

• WRP (write protection): write protection is used to protect trusted code from external attacks or even internal modifications such as unwanted writings/erase operations on critical code/data.

• MPU (memory protection unit): the protected environment managing all critical data and operations (Secure Engine) is isolated from the other software components by leveraging the Memory Protection Unit (MPU). The Secure Engine code and data can be accessed only through a privileged level of software execution. Therefore, software running at a non-privileged level cannot call the Secure Engine services nor access the critical data. This strict access control to Secure Engine services and resources is implemented by defining specific MPU regions described in Table 5.

Table 5. MPU regions in the STM32G0 Series, STM32G4 Series, and STM32H7 Series

Region content Privileged permission Unprivileged permission

Secure Engine code & constants

Secure Engine stack & VDATA

Read Only

(execution allowed)

Read Write

(not executable)

No access

Besides, the MPU also ensures that only authorized code is granted execution permission when the Secure Boot and Secure Firmware Update processes are running.

Before launching the user application, the MPU protection is disabled but the secure user memory protection is activated.

• Secure user memory: when the secure user memory protection is activated, any access to securable memory area (fetch, read, programming, erase) is rejected, generating a bus error. All the code and secrets located inside the secure user memory (a protected environment) is fully hidden. Secure Engine stack and data are cleared when launching the user application as not under secure user memory protection.

Figure 9 illustrates the closure of secure user memory when starting the user application.

28/104 UM2262 Rev 8

UM2262 Protection measures and security strategy

Figure 9. STM32G0, STM32G4, and STM32H7 protection overview

during user application execution

UM2262 Rev 8 29/104

102

Protection measures and security strategy UM2262

5.4 STM32WB Series

Figure 10 illustrates how the system, the code, and the data are protected in the

X-CUBE-SBSFU application example for the STM32WB Series.

Figure 10. STM32WB protection overview during SBSFU execution

30/104 UM2262 Rev 8

+ 73 hidden pages