What is secure boot?
Secure boot ensures only authenticated software runs on the device and is achieved by verifying digital signatures of the software prior to executing that code. To achieve secure boot, processor/SoC support is required. In our experience, some of the more secure boot friendly processors with readily available documentation are NXP i.MX/QorIQ Layerscape, Xilinx Zynq, Atmel SAMA5, TI Sitara and Qualcomm Snapdragon series. Some TI Sitara processors (AM335x) might involve TI factory programming of signing keys and custom part numbers.
Protecting intellectual property and user data
While secure boot ensures authenticity, it does not protect the device from being counterfeited or prevent hackers from extracting user/application data from the device offline (i.e. reading the non-volatile storage like NAND, eMMC using external hardware mechanisms). User data privacy and protection might be a requirement for compliance such as HIPAA on medical devices. If data confidentiality and/or anti-counterfeit functionality is needed, then software/user data needs to be encrypted. The key used for encrypting the data also needs to be protected.
Identifying components to protect
A typical Linux based system has the below components:
- Kernel, Device Tree
- Root Filesystem + User applications
- Application data
- Optional: Firmware (FPGA, co-processor)
Let’s explore some of the methods to secure each of the above.
Bootloader authentication is processor specific. However the high level mechanism is usually the same, it involves:
- Creating a public/private key pair
- Computing the hash of the bootloader image
- Signing the hash with private key using vendor-specific code signing tools
- Appending the signature/certificate along with public key to the bootloader image
- Flashing the public key (or hash of public key) onto One-Time programmable (OTP) fuse on the processor
The processor ROM code on power-up loads the bootloader along with the signature/certificate appended to it. It then verifies the software by performing the following steps:
- Verify the hash of public key appended to bootloader image matches the one stored in OTP fuse
- Extract the hash of bootloader from the signature using the verified public key
- Compare the extracted hash with the computed hash of the bootloader. If it matches it proceed with the boot process, thus authenticating the bootloader.
High-level overview (generic):
In addition to authenticating the bootloader, the bootloader can be also encrypted before signing.
Chain of trust
Extending the trust scheme all the way to user space involves establishing a chain of trust.
i.e. ROM verifies signed bootloader, bootloader verifies signed kernel and kernel verifies/mounts encrypted/signed root filesystem (RFS).
FIT image authentication
FIT stands for Flattened Image Tree and is a single binary that can contain multiple images along with metadata for storing image information along with signatures, thus making it convenient to authenticate. A typical secure boot use case is to generate a FIT image containing kernel, device tree and initramfs. The FIT image is then signed using a private key, and the signature is embedded inside the FIT image. The public key is then embedded inside U-Boot as part of U-Boot device tree. Since the signed U-Boot is authenticated by the ROM, we can trust the public key inside of U-Boot to verify the FIT image.
Verified boot using FIT image is part of mainline U-Boot and FIT image signing is supported by mainline Yocto. Depending on the version of U-Boot/Yocto, certain patches might need to backported.
Instead of using a FIT image, a combined kernel/devicetree/initramfs image can be created, and SoC vendor specific APIs (when available) can be used to verify the combined image (similar to how ROM authenticated bootloader). However, to achieve this, we need good documentation and well-supported bootloader software from the SoC vendor.
Root filesystem and application data protection
If a root filesystem is read only and small enough to run out of RAM, then embedding the root filesystem inside the FIT image should be sufficient for authenticating it. However, typical root filesystems are large, and we need to leverage on the mechanisms provided by the Linux kernel for authenticating and/or encrypting its contents.
Full disk encryption or authentication
Full disk encryption or authentication involves encrypting and/or verifying the contents of the entire disk at a block level. This is performed by the kernel’s device mapper (dm) modules. This method can be used with block devices only (eg: EMMC).
(read/write) or (read-only)
For full disk encryption or authentication, we need an initramfs (initial RAM filesystem) which is a minimal filesystem responsible for:
- verifying the signature of the RFS before mounting a signed RFS partition, and
- decrypting and mounting an encrypted RFS partition.
Directory/File level encryption or authentication
An alternate approach is to encrypt and authenticate on a file or directory basis. Below are some mechanisms to achieve the same:
- Potential issues with filesystem corruptions and offline tampering
- Complicated setup
Protecting the key used for encryption
On a desktop or cell phone, the key used to encrypt the filesystem is derived from a user password entered interactively. IoT and embedded devices typically do not have this luxury. Hence we need to store and protect the key on the device. Below are some protection mechanisms:
- Encrypt the key using a SoC mechanism (more details below)
- Store the key in a external crypto or security chip (eg: ATECC508A) which provides secure storage
- Use a external Trusted Platform Module (TPM) chip
- Remote attestation
Case Study: Key protection on i.MX without using a TPM
Many external security chips such as TPM are susceptible to I2C bus attacks. Leveraging secure storage capabilities of the main processor is preferred when possible. Using an NXP i.MX processor as an example, let’s explore a method to protect the key without using a TPM. On i.MX, each processor has a unique master key (pre-programmed by NXP) that can only be accessed by the Cryptographic Accelerator and Assurance Module (CAAM) module. A CAAM kernel driver can be written to encrypt filesystem encryption key with the unique processor master key. The encrypted key blob can then be stored in the boot partition. This is done as a part of the manufacturing step. During the boot process a script is run from initramfs to decrypt the key blob using CAAM kernel driver and the plain key is then used to decrypt the root filesystem.
Since secure boot or high assurance boot(HAB) is enabled, we do not have to worry about malicious firmware being able to decrypt the encrypted key blob. Further, the encrypted key blob is unique to each device (because of unique master key) and thus provides anti-counterfeit feature (i.e. if an attacker cloned the contents of the flash to another device, the counterfeit device would not be able to run the software since it can not decrypt the key blob).
Example of different signing/encryption keys
Example partition scheme and its contents
Firmware upgrade security
Firmware update mechanism helps patch any security vulnerabilities and introduce new features in a product. It is critical to implement a firmware update mechanism that is secure to complement the secure boot mechanism. Below are some considerations for making the update process secure:
- Server authentication (for OTA updates only)
- Use of CA certificates and TLS
- Package/image signing and encryption
- Built-in feature in some package managers and/or firmware update clients
- Use gpg/openssl tools to external sign/encrypt if using custom update process
Once signing and encryption schemes have been tested, the next step is to integrate everything back into the build system and manufacturing setups.
- Build system
- Create recipes for FIT image creation
- Create recipes for signing SPL, U-Boot, FIT image
- Create recipes for generating initramfs
- Manufacturing/factory setup
- Flash OTP keys
- Create encrypted key blobs
- Create encrypted partitions before writing RFS image
- Disable JTAG access, serial console access
Security cannot be introduced as an afterthought; it needs to be baked into the product design. It also has potential impact on device boot times, file system performance, firmware upgrade process, so implementing it early in the process is highly recommended.
Timesys has in-depth experience in deploying secure boot on products across multiple platforms including Qualcomm Snapdragon 410, NXP i.MX6, i.MX7, LS1046, Microchip SAMA5D2.
Contact us today for help with enabling secure boot and establishing chain of trust on your product.
Next: Learn how to leverage ARM TrustZone and OP-TEE to deploy applications in a hardware isolated secure environment in this blog post. To develop a forward-looking strategy to keep your IoT device secure throughout its life cycle, check out our free eBook!
Timesys has extensive experience with embedded system development and lifecycle management. Timesys has been instrumental in working with global leader semiconductor manufacturers with smart, quick and quality solutions for highly complex systems with accelerated product innovation and multiple product variants.
i am working i.mx8 nano board,https://www.nxp.com/docs/en/application-note/AN4581.pdf,as per this guide, the FIT image contributing the ATF,TEE,Uboot for authetification, so ,on secure boot ,the bl1 hashes value should be from the ROM trusted, so a FIT image with in the a hardware supported system?if,where it stored,and on loading ,it saying that the FIT image should be verified with keys in the config_of_control, so where that key stored then?
For i.mx8 nano, please refer to this post: https://community.nxp.com/t5/i-MX-Processors-Knowledge-Base/Steps-to-enable-secure-boot-in-i-MX8M-Nano/ta-p/1246417
This blog is intended to provide high level concepts. For specifics regarding a processor/BSP, please refer to the vendor sites or schedule a consultation with us: https://www.timesys.com/solutions/schedule-consultation/
I am currently working on an i.MX6 development board. I want to encrypt the entire file system. During the boot process, u-boot or kernel decrypts the file system. The operation of encryption and decryption is called trusted hardware (CAAM). Is this feasible? Is there a tutorial for me to refer to?
Thanks a lot!
Yes, it is possible to achieve entire file system encryption on i.MX. NXP recently published an app note for the same: https://www.nxp.com/docs/en/application-note/AN12714.pdf
Thank you very much!
I noticed in the documentation that it can only be applied to CAAM. Can DCP achieve the same purpose? Or is it possible to use software for full disk decryption without hardware acceleration?
Software can be used for full disk encryption without hardware acceleration. Cryptsetup (and dmsetup) has options for ciphers and if one is not specified, the default it software (eg: aes-cbc-essiv:sha256 as per https://linux.die.net/man/8/cryptsetup). You will still need a mechanism to store the encryption key safely using a hardware back mechanism. Regarding the DCP, the level of support might depend on the kernel version.
Got it! Thanks a lot!
I working on the project in which i have to implement the secure boot. In implementing the secure i able to signed the zimage and uboot but i have no idea for signing the rootfs.
can you please help me for signing the rootfs.
For signing the rootfs, there are 3 popular open source solutions:
1. If the rootfs is small enough to run from RAM, then include the rootfs as part of the FIT image. Alternatively you can embed the rootfs inside the zImage and use your existing zImage mechanism to sign the combined zImage
2. If the rootfs can not run from RAM, then use dm-verity. References:
3. For read-write rootfs dm-integrity can be used (https://gitlab.com/cryptsetup/cryptsetup/-/wikis/DMIntegrity)
While the solutions are open source, setting up the rootfs signing for a custom platform typically involves engineering effort. Please contact sales (email@example.com) if you would like to engage us help you implement the solution on your platform.