OEMiSB

This article gives an overview of the OEMiSB solution integrated in some STM32 series as for example STM32U0 and STM32C0.

1. Product security overview

A device deployed in the field operates in an untrusted environment and it is therefore subject to threats. To mitigate this risk, the goal is to allow only authentic firmware to run on the device.

Security solutions must be designed to protect the firmware and critical operations.

Typical countermeasures are based on cryptography and on memory protections:

  • Cryptography ensures the integrity of the firmware at start-up.
  • Memory protection mechanisms limiting nongenuine external accesses (for example, by accessing the device physically through JTAG) and nongenuine internal accesses from other embedded non-secure processes.

2. OEMiSB presentation

2.1. Overview

OEMiSB stands for OEM immutable (unchangeable) Secure Boot. OEMiSB offers only one service:

  • The Secure Boot (root of trust service) is an immutable code, which is always executed after a system reset. It checks static protections (Options Bytes), activates runtime protections, and then verifies the integrity of the user application code before every execution.

2.2. Protection measures and security strategy

A set of measures and system-level strategies are needed for protecting critical operations and sensitive data (such as the SHA256 of the application), and the execution flow, in order to improve security robustness. The security strategy is based on:

  • Life cycle: Depending on series, read protection (RDP) level 2 or "CLOSED"/"LOCKED" product state must be configured to ensure that a JTAG debugger cannot access the device.
  • Boot lock: option bytes must be configured to establish a chain of trust, by forcing the system to boot from the user flash memory in 0x08000000.
  • MPU: The MPU is a memory protection mechanism that allows specific access rights to be defined for any memory-mapped resources of the device: flash memory, SRAM, and peripheral registers. The MPU is configured to limit the execution surface to the code section of OEMiSB project during its execution then extended to the application code region after verifying its integrity. This protection is dynamically managed at runtime.
  • HDP: when the HDP secure hide protection is activated, any accesses to the protected flash memory area (fetch, read, programming, erase) are rejected. All the code and secrets located inside the protected flash memory area are fully hidden.
  • WRP: write protection is used to ensure code and data immutability as requested by the state-of-the-art standards in secure boot implementation.

A SHA256 control is implemented to verify the integrity of the user application.