Software isolation

The software isolation refers to a runtime mechanism protecting different processes from each other (interprocess protection). These processes can be executed sequentially or concurrently (for example tasks of operating system). The software isolation in the SRAM ensures that respective stack and working data of each process cannot be accessed by the other processes. This interprocess protection can be extended to the code in the flash memory and nonvolatile data as well.

Goals of the software isolation:

• Prevent a process to spy the execution of another sensitive process.
• Protect a process execution against a stack corruption due to memory leaks or overflow (incorrect memory management implementation).

The debug ports provide access to the internal resources (core, memories, and registers) and must be disabled in the final device. It is the most basic external attack that is easily avoided by deactivating JTAG (or SWD) ports by a secure and immutable firmware (refer to Secure boot (SB)), or preferably by permanently disabling the functionality (JTAG fuse in RDP2, life cycle protection).

Other serial interfaces can also be used. If the bootloader is available, the device content can be accessed through I2C, SPI, USART, or USB‑DFU. If the interface is open during the runtime, the application transfer protocol must limit its access capabilities (such as operation mode or address access range).

The boot protection secures the very first software instructions in a system. If an attacker succeeds in modifying the device boot address, he/she can execute his/her own code, to bypass initial dynamic protections configuration or to access unsecured bootloader applications that give access to the device memory.

A microcontroller usually allows the boot configuration in order to choose between starting at user application, at bootloader application, or at the SRAM located firmware. The boot protection relies on a single entry point to a trusted code that can be the user application, or a secure service area if available (RSS).

The monitoring of the device power supply and environment can be set to avoid malfunction and to take corresponding countermeasures. Some mechanisms, like tamper detection, are dedicated to security. Other mechanisms are primarily used for safety reason but can serve security as well. For example, the detection of a power down or external clock disconnection can be unintentional (safety) but can also reveal an attack (security).

Tamper detection is used to detect system/board level intrusions. The opening of a consumer product enclosure can be detected on an MCU pin and trigger appropriate actions. Internal tamper sensors can detect irregular voltage, temperature, or other parameters.

Clock security system is used to protect against external oscillator failures. If a failure is detected on the external clock, the microcontroller switches to the internal clock to safely execute. The interrupt signal allows the firmware to react to the clock failure event.

Power supply and voltage level can be monitored to detect an abnormally low voltage level. Below a certain voltage value, the normal behavior cannot be ensured and it may be the sign of a fault injection attack.

Device temperature can be measured with an internal sensor. The information is fed back to the device through an internal ADC channel. A monitoring application can take appropriate actions according to the temperature range. Increased temperature may be part of a fault injection attack scheme.

To create a secure system, the hardware features must be used in a secure firmware architecture implementation. An industry-standard solution is the PSA, proposed by Arm for the IoT ecosystem. The STMicroelectronics proprietary solution is secure boot (SB) and secure firmware update (SFU). It is possible to use secure firmware installation (SFI) to securely provision blank devices in manufacturing.

These applications have a close link with cryptography. All cryptographic schemes are based on the three concepts of secret key, public key, and hashing. The basics of cryptography are explained in Cryptography–Main concepts. Cryptography–Main concepts.

In a mass production scenario, there may be concerns to get secure binaries to the parts without exposing them to an untrusted environment.

In the SFI scenario, the binaries are encrypted using STM32 Trusted Package Creator software tool and sent to HSM within the production facility, to install the code in the microcontrollers.

The principle of root and chain of trust is common to many secure systems. It is obviously scalable ad libitum, inherently efficient and also flexible.

A chain of trust is built as a set of applicative components in which the security of each component is guaranteed by another component. The root of trust is the anchor at the beginning of the chain on which the overall security depends.

The secure boot implementation must be the single entry point to the device, start after reset with immutable code in secure mode. It then authenticates a subsequent functionality and executes the next part of the firmware that enables the additional functionality required to securely attest the following chain link. For example, it configures volatile memory protection, so that a secure storage service can use it.

For more details about STiRoT immutable Root of Trust, see AN6007 AN5156_General-Info.html#concept_vts_yqx_fcb__ph_14.

Secure boot and secure firmware update are complementary security concepts. The associated model implementation can be found in the X-CUBE-SBSFU package.

The SB application is executed at reset before the user application. It provides first stages of security, and is then responsible for ensuring the global chain of trust of the system.

SB main functionalities:

• Check the STM32 security configuration and set up runtime protections.
• Assert the integrity and authenticity of the user application images that are executed (see the figure below).

The SFU provides a secure implementation of in-field firmware updates, enabling the download of new firmware images to a device.

Architecture

An SFU transfer involves two entities: the firmware owner (OEM) and the device to be updated (see the figure below). As the communication channel is generally considered as nonsecure since it is subject to eavesdropping, the overall security responsibility is shared between the sender (firmware owner server) and the receiver (the device).

The ST proprietary SBSFU is very configurable. The most important configuration option is the choice to use a single or dual image handling of application code. Each has a separate example. Single image leaves more space for application code. Two or more images add some advanced features to the image handling.

For more details, see the document AN5156_General-Info.html#concept_vts_yqx_fcb__entry_nsy_brz_qvb or the document Integration guide for the X‑CUBE‑SBSFU STM32Cube Expansion Package (AN5056).