What is Secure Boot / High Assurance Boot (HAB) , 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-style 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/HAB 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.
What are the 6 steps in Secure Boot?
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.
The challenges of Secure Boot
The common obvious difficulty in Secure Boot is in managing your own security. If your secure keys leak, someone can sign that code against the key that’s in the processor. Therefore, in addition to the hardware, you need to keep your process secure enough.
- A second key challenge is that a processor configured to only boot images securely will not boot unless it has an image that’s properly signed. So, any errors that occur while burning your SRK hash into the processor may result in a processor that can no longer run code because the burnt-in hash doesn’t match. Thus from thereon, the processor will be useless.
- Once the processor is secured, there’s no method to load unsecured code to it. It will only allow you to securely load from storage, such as SD or NAND flash, or other modes of loading software into the processor (USB image loading).
- Hence, the steps for preparing your hardware and the processor must be kept secure. Users must ensure that the boot loader is prepared for this as well. This means that the user’s bootloader must call into the Secure Boot library on the processor in order to authenticate the next stage in the boot chain.
While Secure Boot is a worthwhile step in securing your system, implementing it on the i.MX7 doesn’t secure the entire system down – only the boot loader and if extended OS software as well. As a consequence, someone might write some Linux malware that runs on top of the OS, and if it loads successfully, it could compromise the system.
Best practices for Secure Boot on the i.MX7
- Start your process secure and strong:Implement a good overall security practice. Flowing your keys out of the production environment undermines the point.
- Ensure the strong algorithms are being used:Make sure the algorithms are up to date and match for purpose.
- Verify the code:For Secure Boot to indicate anything, the remainder of the user’s code in the bootloader, OS, and other software also has to be properly coded for Secure Boot, and not possess security flaws. In addition, each stage of the boot process must examine the next code before executing it.
As a conclusion, I would say that security cannot be included as a reconsideration. It needs to be hardened into the product design.
A security solution for embedded devices must
- Ensure the device firmware has not been tampered with,
- Secure the data stored by the device,
- Secure communication
- And protect the device from cyber-attacks.
This can only be achieved by including security in the early stages of design starting with Secure Boot.
The following sources were referenced to produce this document: