The purpose of the article is to give an overview of the security features available on the STM32N6 MCUs.
Unlike all other STM32 products, the STM32N6 is manufactured in 16 nm FinFET technology, which does not support embedded flash memory. The only on-chip nonvolatile memory that it has is 1.5 KB of one-time programmable (OTP) fuse memory. The primary need for this OTP memory is to provision permanent information into the chip at manufacturing time (when external flash memory is not yet present). Rather than carrying ST boot code in system flash, the STM32N6 instantiates ROM code to implement the secure boot of an FSBL.
Thus, the security mechanisms on the STM32N6 are very close to STM32 MPU products (refer to [1]).
It is recommended that the boot ROM loads an OEMuRoT as its FSBL. This OEMuRoT in turn is responsible for securely booting the application code.
In this document, the boot path is boot ROM followed by OEMuRoT, and then followed by the application code.
The IP that manages access to the OTP is called the BSEC.
1. Product state
The OTP fuse memory is also used to store the current life cycle state. Refer to the Product state for STM32N6 article for details of the encoding of the life cycle state.
1.1. Customer provisioning
After receiving STM32N6 parts in the CLOSED_UNLOCKED life cycle state, OEMs that require secure authenticated boot of an OEMuRoT firmware must provision a hash of hashes of their public firmware signing keys into OTP words 160 - 167, and transform the life cycle state to CLOSED_LOCKED_PROVD by blowing bits 12 down to 0 of word 18, blowing bit 20 of word 124, and then performing a power cycle. After this, the chip will only boot code that has been signed by the owner of the private parts of those public signing keys. If the OEMuRoT must reside in external flash in encrypted form, the customer must also provision their 128-bit AES encryption key into OTP words 364 - 367. The boot ROM assumes that these keys are at these specific fuse locations.
The flow for provisioning parts and signing and encrypting the OEMuRoT is described in Getting started with STM32N6 security.
The STM32N6 provides a mechanism to ensure that it is only possible to transform the life cycle state to the terminal RMA state (for return to STMicroelectronics to rerun engineering test procedures) if a 128-bit secret password is shifted in on the JTAG while the device is under system reset. This secret password is owned by the OEM. They must blow it into OTP words 256 - 259. Once the chip is in the RMA life cycle state, any secrets stored in OTP words 256 to 375 can never again be extracted from the OTP.
1.2. Debug
On a CLOSED_LOCKED_PROVD production part, debugging is disabled by default. It is the responsibility of the customer's secure privileged firmware to implement a mechanism to decide whether to enable debugging. This mechanism might involve entering a password through JTAG that is checked against a secret provisioned by the customer at manufacturing time, or it might be a more complex scheme, like ADAC. The firmware makes the decision to enable or disable debug by writing to the BSEC_DBGCR and BSEC_AP_UNLOCK registers. Whatever decision it makes persists until the next power cycle (refer to the ES0620 STM32N6xxx: device errata, section 2.2.18). The firmware can disable debug until the next power cycle by writing zeroes to these two registers.
Secure privileged software can enable nonsecure debug on a CLOSED_LOCKED_PROVD part by writing 0x0051B400 to BSEC_DBGCR, and 0x000000B4 to BSEC_AP_UNLOCK. If only nonsecure debug is authorized, then it is only possible to set breakpoints on nonsecure instructions, and watchpoints on nonsecure data, and peek and poke nonsecure regions through the debug access port. In fact, by writing 0x008AB400 to BSEC_DBGCR instead of 0x0051B400, it is possible to ensure that the nonsecure debug is only enabled once the OEMuRoT has completed and incremented the HDPL to 2 (thus ensuring that even nonsecure code in the OEMuRoT cannot be debugged).
Secure privileged software can enable secure debug by writing 0xB451B400 to BSEC_DBGCR, and 0x000000B4 to BSEC_AP_UNLOCK. To ensure that secure debug is only available on a limited set of controlled parts, the customer can arrange for production parts to have the first of the eight signing keys revoked, and only sign firmware that enables secure debug with that first revoked key, so that secure debug can only be performed on a controlled part that has not had the first signing key revoked.
2. Secure boot and firmware update
2.1. Secure boot
If the part is in the CLOSED_LOCKED_PROVD life cycle state, then debug is disabled at reset, and therefore the device will start executing boot ROM code. This is the foundation of the secure boot.
This boot ROM code will try loading a boot image (the OEMuRoT) into SRAM from various boot sources in turn. The public key corresponding to the private key used to sign the OEMuRoT is carried in the image header, along with a table of hashes of 8 public keys. The boot ROM will check that the hash of the table of hashes carried in the image header matches the hash blown into OTP words 160 - 167. If it does, it will then check that the hash of the public key carried in the image header matches one of the hashes in the table of hashes. If it does, it trusts that public key, and uses it to authenticate the image. If the signature verification passes, it will execute that image (after decrypting it using the encryption key provisioned in OTP words 364 - 367, if it is declared to be encrypted).
For further details on the boot ROM, refer to the Boot ROM for STM32N6 article.
2.2. Firmware update
The customer software must itself implement a mechanism to manage software updates. However, the boot ROM always expects there to be two FSBL firmware images placed consecutively in flash. If the first image fails to authenticate, the boot ROM will try to authenticate the second. This permits the implementation of a fail-safe update mechanism. If an overwrite of the first image is interrupted by a power cut, the second image is still intact. At the next reset, although the corrupted first image fails to authenticate, the second image boots correctly.
3. Application isolation
3.1. Temporal isolation
Temporal isolation is a feature that ensures later software cannot access secrets used by earlier software.
The temporal isolation feature (HDP) is represented with a monotonically increasing 2-bit counter register in the BSEC BSEC_HDPLSR, zeroed on the system reset, which does not wrap back from 3 to zero. Only secure privileged software can increment this counter. The boot ROM increments this counter to 1 at the end of its execution.
The SAES (secure AES engine) uses an HDPL input when performing a derivation of the HUK to create the DHUK (derived-HUK). The HDPL value seen by the SAES can be increased to a value higher than the current value, to provision data ready for the next temporal stage. However, the DHUK generated with a particular HDPL value cannot be regenerated during later temporal stages.
Temporal isolation can also be implemented in the BSEC via sticky read locks and sticky programming locks. Refer to chapter 4 of the reference manual.
3.2. TrustZone®
The Cortex®-M55 supports TrustZone® scheme of Arm®. This effectively allows two virtual CPUs (the "secure world" and the "nonsecure world") to timeshare the CPU resources.
Each memory address is defined to exist either in the secure or the nonsecure world. Some CPU resources (such as stack-pointer registers, MPU registers, interrupt vector tables, or timers), are physically banked between worlds. When the CPU executes a secure code (that is, code fetched from secure world addresses), it uses the secure world versions of these resources. When the CPU executes nonsecure code (that is, code fetched from nonsecure world addresses), it uses the nonsecure world versions of these resources. However, for the most part, secure and nonsecure codes use the same CPU hardware.
A nonsecure code is blocked from accessing secure world addresses. It can call only secure code (that is, move into the secure world) via SG (secure gate) instructions, which reside in special secure world NSC (nonsecure callable) regions.
The TrustZone® ensures that the operation of a secure code and its data cannot be corrupted by nonsecure code.
The M55 emerges from reset in secure world, and the boot ROM jumps to the OEMuRoT in secure world.
It is up to the OEMuRoT firmware to configure a partitioning of the addressable resources of the chip between secure world and nonsecure world.
The chapter 3 of the reference manual contains more details on the TrustZone® mechanisms on the STM32N6.
3.3. Privilege controlled isolation
The Cortex®-M55 contains two distinct memory protection units (MPUs), one for each world. The MPU allows the privileged (operating system) software running in that world to reserve certain memory regions to the privileged world, and also define whether those regions are executable or not. Refer to the Cortex®-M55 documentation for details.
3.4. Resource isolation
There are a number of DMA agents (bus initiators) on the chip that can be programmed to make accesses on behalf of the secure world or the nonsecure world. Their accesses do not pass via the CPU's internal filtering mechanisms, and therefore a system of firewalls is instantiated on the chip, called the resource isolation framework (RIF), to ensure nonsecure DMAs cannot read or write to secure memory regions.
The secure world software can configure firewalls in front of each peripheral to ensure that the nonsecure world software cannot use that peripheral (that is, to reserve it to the secure world). For details on the RIF, refer to the chapters 6, 7, and 8 of the reference manual.
4. Secure storage
4.1. Key wrapping
One of the values provisioned into fuses at manufacturing time is a 256-bit hardware unique key (HUK). This key is never available directly to any software, but can be used to cryptographically wrap keys and information for storing in external flash memory on the board. Using this mechanism, customers can store encrypted (wrapped) information in flash memory that can only ever be decrypted (unwrapped) by the same chip that originally encrypted (wrapped) it. Refer to the Secure storage-SAES key wrapping for STM32N6 article for details.
Customers can use any unallocated fuse locations to store permanent OTP information, but the capacity of the OTP fuse memory is very limited. The chapter 5 of the reference manual lists the unallocated fuse locations.
4.2. Battery-backed storage
The N6 contains some registers and RAM (called BKPRAM) that reside in a Battery-backed power domain called VBAT. This domain can be arranged to be Always-on (e.g. powered by a coin-cell battery), and therefore can emulate nonvolatile memory.
It is possible to store permanent secrets in these registers and the BKPRAM.
One of the registers is a 256-bit value called BHK, which becomes inaccessible by software after being written, but, like the HUK, is wired to the SAES, and can be used to derive DHUKs, just like the HUK itself. The OEM can provision a BHK once a coin-cell battery is present to keep the VBAT domain powered.
4.3. Tamper protection
The chip contains a tamper IP that is configured to react to internal events reported by various sensors on the chip (for example, a temperature sensor detecting an out-of-range temperature).
The tamper IP supports an active tamper detection mechanism, whereby it outputs a signal pattern on an output PAD and expects to receive the same signal pattern returning on an input PAD. These output and input pads can be connected on the board or in the package. If the tamper IP detects that it is no longer receiving the signal pattern that it output, it can interpret that as an attempt at physical intrusion. The tamper IP is in the VBAT domain, so this active tamper detection can protect the device even when powered down.
There are eight tamper IO pads. They can configured to be paired up to form 4 independent "active-tamper meshes", or, for example, can be configure as one output connected to seven separate inputs.
The tamper IP can be configured to immediately erase the BHK and the contents of the BKPRAM as soon as an enabled tamper input received notification of an event on the corresponding sensor.
Refer to the chapter 62 of the reference manual for further details.
Pages in category "Security with STM32N6"
The following 5 pages are in this category, out of 5 total.