What is Secure Boot in Embedded Systems
Or High Assurance Boot (HAB) and why do you need it and what do you need to be aware of?
In Today’s connected world, online devices reach into every phase of modern life. From household appliances to automated cars, smartwatches to smart-phones in your pocket, the heap of form factors and value of the data contained in these devices has never been greater. As we are quickly moving towards devices that are connected in this digital world, Data security is more important than ever and the concern of many.
The percentage of breaches involving end-user devices has doubled year-on-year and Cybercriminals are shifting focus from PC to mobile users. Contemporary systems read their software from images on a storage memory. A hacker can, therefore, alter or replace those software images to gain full control of the system and/or access sensitive data.
Having all this in mind, embedded and IoT systems in use in diverse industries must consolidate more trustworthy security standards for the protection of sensitive data. Thus, the need to prioritize security in IoT embedded systems has rarely been more urgent. A perfect solution to this problem is the Secure Boot /High Assurance Boot.
Secure Boot is a process that ensures only authenticated software runs on the device and it is achieved by verifying digital signatures of the software before executing that code. To achieve Secure Boot, support from processor/SoC is required. In precise, it assures that the bootloader and OS software is the deliberate manufacturer version and hasn’t been tampered with by any malicious party or process.
If you do not have Secure Boot/HAB enabled in your processor, someone could take your hardware and put another OS or other software program they desire on it. This could be for various malicious purposes such as to make it fail, for data accumulation, or for reverse engineering your product to replicate your design either in hardware or software. A good time to use Secure Boot is any case where you don’t want another party to load a bootloader or a different operating system on to your device.
HAB is an elective feature in the i.MX SoC family, which allows you to make sure only software images signed by you can be executed on the SoC. It incorporates boot ROM level security which cannot be changed after programming the relevant one-time electrically programmable fuses (eFuses). The boot ROM is responsible for loading the initial software image from the boot medium (normally this initial software is a bootloader such as U-Boot). HAB facilitates the boot ROM to authenticate the initial software image by using digital signatures. It also provides a mechanism to establish a chain of trust for the remaining software components (such as the kernel image) and thus to build a secure state of the system. On processors supporting the HAB feature, the encrypted boot may also be used to provide image cloning security and, depending on the usage, image confidentiality.
How does Secure Boot on IoT Devices operate?
The Secure Boot feature using HAB in many NXP processors is based on Public Key Infrastructure. The security provision system consists of two main components:
- The HAB library sub-component of NXP Processor Boot ROMs.
- The Code Signing Tool (CST).
SIGNED BOOT FLOW USING SECURE BOOT/HAB
There are three major versions of the secure components that exist on NXP processors: HAB Version 3 (HAB3), HAB Version 4 (HAB4) and AHAB version. HABv4 in iMX7 supports the boot flow as shown in the above figure.
Private keys, Boot loaders, Root of Trust…What are the 6 steps to follow ?
HAB authentication is based on public-key cryptography using the RSA algorithm.
It consists of the following stages:
- Signing the Images:
The software images are signed offline using private keys. This is done using NXP’s Code Signing Tool which makes the process simple. - Fusing the i.MX7 SoC with the corresponding public keys:
The key structure is called a PKI tree and Super Root Keys (SRK) are elements of it. A table of the public SRKs is hashed and permanently written to the SoC using eFuses. - Reading the e-Fuses:
i.MX Boot ROM reads the eFuses to determine the security configuration of the SoC and the type of the boot device. - Loading the Software:
The i.MX Boot ROM then loads the bootloader image to DDR memory. The software image contains both the bootloader itself and digital signature data and public key certificate data which are collectively called Command Sequence File (CSF) data. - HAB Events/Messages:
Once the bootloader is loaded, execution is then passed to the HAB library which will verify the signatures of the bootloader stage. If the signature verification fails, execution is not allowed to leave the ROM for securely configured SoCs, also called “closed” devices.
You have the option to allow the processor to still keep executing unsigned images while creating helpful HAB messages until you decide to “close” it by writing a dedicated bit using another eFuse. This feature allows you to test the sign-authenticate process and confirm that it was done correctly before completely and permanently “closing” the processor to only execute your signed software images. - Authentication of the software images on the target during boot time:
The signed software image data is authenticated on the i.MX processor using the corresponding public keys.
HAB evaluates the SRK table included in the signature by hashing it and comparing the result to the SRK fuse values. If the SRK verification is successful, this establishes the root of trust, and the remainder of the signature can be processed to authenticate the image.
NOTE : The ROM and HAB cannot be changed, so they can be considered as trusted software components. This allows the use of ROM and HAB to establish a Secure Boot chain.
Once the initial bootloader is authenticated and executed, the chain of trust can be continued by authenticating each of the next loaded images before executing them – e.g. The boot ROM authenticates U-Boot, and U-Boot authenticates the Linux kernel and so on.