The basics of secure boot and secure (OTA) updates in MCUs (Japanese blog) In security contexts, the terms "secure boot" and "secure/OTA update" are frequently used. This document explains the basics of these concepts and the Secure Boot Loader (SBL), a means of achieving them, primarily from the perspective of embedded MCU security. The fundamental concepts are similar for MPUs as well.
Instructions and usage methods for individual products will be explained in separate articles.
(Reading time: 15 minutes)
Purpose and Overview of Secure Boot
The purpose of Secure Boot is to "detect and prevent malicious attackers from replacing or tampering with the firmware."
If an attacker is able to rewrite the firmware through some kind of vulnerability, it can lead to a very wide range of risks.
Examples of risks:
Damage to the privacy and property of end product users
Unauthorized reading of product firmware can lead to intellectual property leaks and misuse for counterfeit goods.
Features that would normally require an additional license are made available for free.
Product damage due to unauthorized operation
By applying cryptographic signatures to firmware, the integrity of the application (that it has not been destroyed or tampered with) can be verified through signature verification.
Note: While the absence of damage can be detected by error checks such as CRC, anyone can calculate the CRC, so if the program itself has been tampered with, it cannot be detected. Verification using a signature, which can only be calculated by the product manufacturer who possesses the secret key, is necessary.
A common implementation involves using a separate firmware called a Secure Boot Loader (SBL). The SBL starts before the firmware boots, verifies the firmware's signature, and only boots the firmware if the signature verification is successful (i.e., Secure Boot).
The purpose, challenges, and solutions of secure updates
The purpose of secure updates is to "safely update only legitimate firmware, preventing replacement with malicious firmware, tampering, or unintentional reverting to older versions."
Firmware updates are used not only to add new features to a product, but also to fix bugs and vulnerabilities. Making software updates available for products already on the market benefits both product manufacturers and end-users.
End users can receive new features and performance improvements without having to replace their products. Furthermore, the provision of fixes for bugs and vulnerabilities discovered after shipment makes it easier to respond to newly discovered vulnerabilities, attack methods, and other threats. Especially for products connected to networks (including not only the internet but also internal networks within companies, buildings, and factories), the availability of continuous security updates is a crucial factor in product selection.
Furthermore, if critical bugs or vulnerabilities are discovered, applying fixes without waiting for on-site product replacement or recall can potentially minimize product downtime and business disruption.
Product manufacturers can provide firmware updates to fix critical bugs and vulnerabilities discovered after shipment. This can potentially reduce logistics, labor, and inventory costs associated with recalling, repairing, and replacing affected products.
Furthermore, by responding to market demands and specification changes discovered after shipment (including those originating not only from the manufacturer but also from third-party services), and by improving product functionality and compatibility, it becomes easier to extend the product lifecycle and maintain customer satisfaction and product reliability.
However, when applying firmware updates to market products, the following challenges must be addressed:
#
assignment
Solution
1
IP leakage and counterfeit product manufacturing through reading update image content
The update image is encrypted and decrypted within the product before application.
2
Attackers can write arbitrary firmware to products.
By performing cryptographic signature verification before applying or booting the update image, the integrity of the update image is guaranteed before application or booting.
3
Product startup impossible due to rewrite interruption or failure.
Support for retrying updates or recovering via a dual-slot method (described later) (described later)
4
Rollback attack: Reverting to a previous firmware version prior to the vulnerability fix.
Preventing unauthorized rollbacks through version checks
Note: When an update is performed via a wireless interface, it is specifically called an OTA update.
*OTA: Over The Air
A common implementation method involves preparing separate firmware for this purpose, as rewriting the running firmware is complex. Furthermore, since the solution to problem #2 involves the same process as the aforementioned secure boot, it is common to integrate the secure update function or a part of it into the SBL used for secure boot.
The simplest method is for the SBL itself to receive the new firmware update image and write it directly to the area where the old firmware is located, as shown in the diagram below.
The update image, including the new firmware, will be digitally signed and given a version number, and the firmware will be encrypted. The product will verify the signature to confirm the integrity of the image, confirm that the version is newer than the old firmware, and then decrypt and write the image to address issues #1, 2, and 4.
The system can address issue #3 by remaining in the SBL (Secure Boot Block) state during interruption and entering a state where it waits to receive an update image due to a Secure Boot failure on the next startup.
The biggest drawback of this method is that the execution of the old firmware is completely stopped, including while receiving a firmware update, and that it is not possible to revert to the old firmware if the process is interrupted.
To resolve this, you can use the dual-slot update method described later.
Security considerations
The 1st SBL must not be rewritten.
The diagram in the chapter "Purpose and Overview of Secure Boot" only shows the SBL and firmware, but in reality, after startup or reset, the MCU's built-in, non-rewritable Boot ROM is executed first. This Boot ROM may or may not include the functionality for secure boot. Examples of various NXP products and a simplified boot flow are shown below.
Boot ROM
Secure Boot feature
Yes
none
Examples of NXP products
MCX N Series
MCX A5 Series
MCX A13/14/15 Series
Boot flow
Reset
↓ Launch without signature verification
Boot ROM (operates as the 1st SBL)
↓ Launch after signature verification
Signed firmware (on Flash)
Reset
↓ Launch without signature verification
Boot ROM
↓ Launch without signature verification
1st SBL (on Flash)
↓ Launch after signature verification
Signed firmware (on Flash)
Here, we specifically refer to the first SBL (System Building Block) to start within the system as the 1st SBL.
Secure Boot can be described as "a technology that starts the firmware only after the SBL has confirmed it is trustworthy." However, as mentioned above, the 1st SBL starts without verification by other SBLs.
In other words , the 1st SBL is the Root of Trust (RoT) that must be trusted unconditionally , and it is impossible to detect if the 1st SBL is tampered with through some vulnerability. If the 1st SBL is tampered with and secure boot is bypassed, it becomes possible to boot any firmware, so the 1st SBL must be basically unrewritable except for areas that require rewriting (such as the version control area to prevent rollback attacks).
Note: Strictly speaking, it is possible to allow updates to the 1st SBL only through authenticated routes, but this presents various problems, such as the risk of being unable to start up in the event of an interruption. It is considered easier to design by deploying a 2nd SBL (described later) and allowing updates to that instead.
If the non-rewritable Boot ROM includes Secure Boot functionality: The non-rewritable Boot ROM acts as the 1st SBL to verify the firmware on the flash memory, so the 1st SBL can never be rewritten. The areas that need to be rewritten are implemented using OTP or flash memory that can only be modified from the Boot ROM.
If the non-rewritable Boot ROM does not include Secure Boot functionality: The first SBL (Smart Burner Unit) that authenticates the firmware on the flash memory becomes the 1st SBL. It is necessary to use flash protection to make the 1st SBL unrewritable .
Since the 1st SBL cannot be updated, it requires extremely careful design and verification, and integrating too many features is not recommended.
By utilizing NXP's products with built-in Boot ROMs that have obtained SESIP/PSA security certification and feature secure boot functionality, this design verification effort can be reduced.
In some cases, to build a flexible system with rich functionality using SBL, an additional rewritable 2nd SBL may be placed between the firmware and the SBL, as shown in the diagram below.
Tampering after firmware startup is undetectable.
Secure Boot is used for verification before firmware startup, so it cannot detect tampering after startup.
While there are techniques to verify the firmware while it is running, the simplest implementation is to make the firmware unrewritable. However, considering firmware updates, it's not always possible to make it unrewritable.
To make the firmware unrewritable, dynamic settings such as dynamically configurable memory protection functions are required, allowing rewriting while the firmware is running and rewriting is enabled during an update.
The update image decryption key must be prevented from being read or used.
If a vulnerability in the firmware allows the update image decryption key to be read and used, it could lead to the leakage of the update image contents.
Since the SBL requires the use of the decryption key, it is necessary to be able to read and use the decryption key while the SBL is running. However, before transferring execution from the SBL to the firmware, if the decryption key exists in RAM, it must be discarded, and furthermore, memory protection must be used to prevent the firmware from reading the decryption key.
If the MCU contains hardware such as a cryptographic accelerator with key isolation capabilities, the key cannot be read but can still be used. Therefore, access protection should be used to prevent its use, or the key should be deleted before transferring execution from the SBL to the firmware to prevent it from being imported and thus make it unreadable.
When combined with the aforementioned firmware rewrite-disable setting, the access permissions during SBL execution and firmware execution should basically be as follows, and these permission settings must not be changeable from the firmware side.
Dual-slot update
The implementation method for secure updates that includes a separate area (Slot 1) for temporarily storing new firmware, distinct from the currently operating firmware area (Slot 0), is called the dual-slot method.
The update will be performed using the following steps.
Firmware receives new firmware
A software reset transfers execution to the SBL, which then verifies and decrypts the new firmware.
Switch the active firmware from the old firmware to the new firmware and start the new firmware experimentally.
If the new firmware boots successfully, confirm the update to complete the process.
The system will revert to the old firmware (=Rollback) only if the new firmware fails to boot.
There are various methods for switching the active firmware, but in the diagram below, the firmware placed in Slot 0 is considered the active firmware, and the contents of Slot 0 and Slot 1 are swapped using the Swap method.
This method requires storage capacity to store at least two update images, as well as space for boot management information and metadata, but it offers the following main advantages:
It is possible to receive update images without completely shutting down the firmware.
This configuration allows for the reception of update images to be performed in parallel with other firmware tasks.
However, if the product's flash memory does not support read-while-write (RWW), it will be impossible to read code or interrupt vectors from the same flash memory area while writing, which will significantly impair the execution speed and responsiveness of the code on the flash memory.
If you want to run applications that require real-time performance, you may need to take the following measures as needed.
Place the code in RAM
External flash memory for storing update images
Use a product with built-in flash memory that supports RWW (e.g., NXP MCX N series ).
SBL design can be simplified.
As mentioned earlier, the 1st SBL is not updatable, requiring extremely careful design and verification, and integrating too many features is not recommended.
If the process of receiving update images can be separated from processes such as signature verification, decryption, and key management, placing the receiving function outside the SBL (System Block Label) can reduce the design and verification scope of the SBL. In particular, if the configuration simply stores the received image in an inactive slot without verification, it becomes easier to separate the receiving function from the SBL.
For example, methods for receiving updates wirelessly or via Ethernet require a complex protocol stack, making it more suitable to implement them on the firmware side or in the second SBL rather than integrating them into the first SBL.
Additionally, as a recovery measure in case of problems with the firmware update reception function, a simple reception function using UART or similar may be retained on the 1st SBL side.
Even if reception is interrupted or the new firmware cannot be started, operation can continue using the old firmware.
Since the old firmware is not corrupted during reception, execution of the old firmware can be immediately resumed even if interrupted.
Furthermore, since the old firmware is retained even after the update, it is possible to immediately revert to the old firmware (Rollback) in the event that the new firmware fails to boot. (This Rollback must be managed separately from malicious Rollback attacks by combining it with version checks.)
summary
Secure Boot: Checks whether the currently installed firmware can be booted securely.
Secure Update: Guarantees safe replacement with the latest firmware.
Related Information
NXP Security - Summary Page (Japanese Blog)
i.MX 93 Processor: Explaining the Secure Boot Signature and Authentication Mechanism (Japanese Blog)
i.MX 93 Processor: How to Implement Secure Boot - Practical Guide (Japanese Blog)
Secure Boot with i.MX 95 SPSDK (Japanese Blog) --> PQC-enabled Secure Boot
=========================
We are currently unable to respond to comments left in the " Comment " section of this post . We apologize for the inconvenience, but please refer to " Technical Questions to NXP - How to Contact Us( Japanese Blog) " when making inquiries.(If you are already an NXP distributor or have a relationship with NXP, you may ask your representative directly.)
In security contexts, the terms "secure boot" and "secure/OTA update" are frequently used. This document explains the basics of these concepts and the Secure Boot Loader (SBL), a means of achieving them, primarily from the perspective of embedded MCU security. The fundamental concepts are similar for MPUs as well.
Instructions and usage methods for individual products will be explained in separate articles.
(Reading time: 15 minutes) MCX Security Japanese Blog
View full article
