STiRoT

Coming soon

1. Product security overview

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. In fact, 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 in a secure way.

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

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

• Cryptography ensures integrity (the assurance that data has not been corrupted), authentication (the assurance that a certain entity is what 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 non-secure processes.

2. STiROT presentation

STiRoT states for ST immutable (unchangeable) Root Of Trust and acts as a first boot stage.

STiROT is embedded in an immutable area of the system and provides 2 services :

• The Secure Boot (root of trust services) is an immutable code, always executed after a system reset (1), that activates STM32 runtime protections and then verifies the authenticity and integrity of the Application (2) code before every execution (3).

• The Secure Firmware Update application is an immutable code that detects that a new firmware image is available, checks its authenticity (1), then checks the integrity (2) of the code before installing it after decryption (3).

Cryptography is used to ensure confidentiality, integrity and authentication.

• 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.
• Integrity is verified to be sure that the received image is not corrupted.
• Authenticity check aims to verify that the firmware image is coming from a trusted and known source, in order to prevent unauthorized entities to install and execute code.

For STiROT, the selected configuration is :

• ECDSA-256 asymmetric cryptography for image authenticity verification,
• AES-CTR-128 symmetric cryptography with key ECIES-P256 encrypted for image confidentiality,
• SHA 256 cryptography for image integrity check.

2.1. 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 STiROT code
• Make STiROT code and secrets immutable: no possibility to modify or alter them once security is fully activated
• Create a protected and isolated enclave to store secrets
• Limit surface execution to STiROT code during his execution
• Remove JTAG access to the device
• Monitor the system: intrusion detection and SBSFU execution time

Depending on STM32 series, different hardware mechanisms can be configured to implement the security strategy such as : HDP, WRP, Tampers, Security option bytes, Life cycle, MPU, TrusteZone, SAU, GTZC.

2.2. Startup sequence

Option bytes should be configured in order to force the boot on STiROT. This configuration is specific to each STM32 series. At reset the following sequence will be executed.

2.3. Uses Cases

There are two possible cases:

• 1 boot stage : Immutable ROT.

STiRoT is configured to manage only 1 image, the application code. At reset, after a successful verification (integrity and authenticity), the STiRoT executes the user application.

• 2 boot stages : Immutable and Updatable ROT.

STiROT is configured to manage 2 images, the uROT code and its associated data (secrets). At reset, after a successful verification (integrity and authenticity), the STiRoT executes the uROT. uROT is in charge of verifyng the application before its execution.

3. Image generation

STiROT manages images at MCUBoot format including:

• an header
• the encrypted firmware binary
• some metadata information (TLV) allowing the control of the image (SHA256, encryption key ...)
• a magic to trigger the installation.

A PC tool STM32TrustedPackageCreator is provided to generate such image based on the binary generated at the end of the compilation process.

For data image the firmware binary is replaced by the data binary file.

4. Provisioning

The product provisioning to activate the boot path STiROT is done in three main steps:

• Step 1, STiROT configuration definition (number of images managed, location of this images, cryptographic keys ...)
• Step 2: Images generation at MCUBoot format.
• Step 3: Option bytes, Obkeys and Images programing