Qualcomm Snapdragon processors support secure boot which ensures only authenticated software runs on the device. By configuring the processor for secure boot, unauthorized or modified code is prevented from being run. The authenticity of the image is verified using digital signatures and a certificate chain.
On Qualcomm processors the first piece of software that runs is called Primary BootLoader (PBL) and it resides in immutable read-only-memory (ROM) of the processor. By configuring the processor for secure boot, PBL can verify the authenticity of the Secondary BootLoader (SBL) before executing it. The PBL verifies the certificate information by comparing the hash of the public key in the certificate with the one programmed in OTP eFuse on the processor and can verify additional certificates in a certificate chain. The PBL then computes the hash of the SBL and verifies the hash with the one obtained from the verified signature. Similarly SBL is responsible for loading and verifying the authenticity of other Qualcomm proprietary images (e.g., power management – rpm.mbn, trust zone – tz.mbn, hypervisor – hyp.mbn) and the next stage bootloader referred to as Little Kernel (LK) bootloader (appsboot.mbn). The LK bootloader is responsible for loading and verifying the authenticity of boot.img, which comprises the Linux kernel, a device tree, and an optional initramfs. The initramfs can contain scripts to verify the authenticity of the root file system (RFS) using dm-verity or mount an encrypted RFS using dm-crypt/LUKS. Thus a chain of trust is established from the boot loader all the way to user space.
Note: The SBL is a proprietary bootloader typically obtained in binary form; however, source code can be obtained from Qualcomm or Arrow Electronics after signing an NDA.
A proprietary tool called sectools is required to sign the SBL. Sectools can be obtained through Arrow Electronics or Qualcomm. The tool computes the signature and appends the signature along with the certificates to the SBL image. The tool additionally generates a sec.dat file containing root public key hash and other security configurations that is flashed onto the processor.
The simplified process for signing the bootloader is:
Sectools is set up to sign additional Qualcomm proprietary binaries such as rpm.mbn, tz.mbn, hyp.mbn and the open source LK bootloader in a similar fashion.
In order to extend the chain of trust to kernel/device tree/initramfs (boot.img) and root filesystem additional steps need to be taken. The boot.img is signed using open-source tools such as OpenSSL and does not require the use of the proprietary Sectools. Qualcomm provides a document detailing steps to generate a signed boot.img and embed the public key inside the little kernel image.
As of writing this blog, the steps are only integrated into the Qualcomm Android builds (LA) and additional steps need to be taken for Qualcomm/Linaro Linux builds (LE). The high-level process for signing the boot.img is:
There are multiple options to extend the chain of trust to user space as previously discussed in this blog post. We will discuss the two commonly used mechanisms here, signed RFS using dm-verity (read-only RFS) and encrypted RFS using dm-crypt (read-write RFS).
Extending the chain of trust to user space (root file system) can be achieved using dm-verity. Unlike the Qualcomm Android builds, the Qualcomm/Linaro Linux builds do not generate a signed read-only rootfs image. Additional support needs to be added to Yocto to generate a signed dm-verity image and an initramfs that supports verifying the dm-verity table.
Encrypting data ensures confidentiality which is critical for user data protection (e.g., for compliance like HIPAA) and intellectual property protection (e.g., anti-cloning). While readily available mechanisms in the Linux kernel such as dm-crypt/LUKS can be used for encrypting the file system, the key used to encrypt the dm-crypt partition needs to be protected. One solution is to store the RFS encryption key on an external security chip such as a TPM. However TPM chips have their own security limitations such as susceptibility to I2C bus attacks. In order to avoid such attacks it is best if the RFS encryption key is stored on the Snapdragon processor.
The Snapdragon processors have an OTP fuse bank region referred to as eFuses (QFPROM) which can be used to store disk encryption keys. The Qualcomm Android build for Dragonboard 410c (APQ8016) comes with software support for full disk encryption by leveraging Qualcomm secure execution environment (QSEE) software running on ARM TrustZone to read the keys from eFuses. As of writing this blog, software support for full disk encryption does not exist for the Qualcomm Linux builds. To further complicate things, Linux does not execute at a security level that can directly access the region of eFuses where the keys are stored leading to key management complexity.
As an alternative, since the SBL executes at a security level that can access the eFuses, it can be modified to read the keys and pass them on to the Linux kernel via internal SRAM. The Linux kernel can then mount the encrypted RFS and erase the keys from internal SRAM. Since only signed SBL can run on the device, we need not worry about unauthorized firmware being able to access the RFS encryption key stored in eFuses.
In order to minimize the attack surface for secure boot, it is highly recommended to perform the following steps for added security:
The above steps can be achieved by blowing appropriate fuse bits using Sectools.
Qualcomm Snapdragon processors have excellent hardware support for implementing security on embedded/IoT devices. While Qualcomm Android software leverages the hardware support, enabling similar hardware security support in Linux is a bit more cumbersome at the moment. Once the missing support is added, secure boot and chain of trust can be established and easily verified on a development board such as Dragonboard 410c.
Lynx is a partner of Arrow Electronics and has access to SBL source code, Sectools and Qualcomm Processor documentation available only under NDA. We can build, customize SBL (including DDR timing/calibration, custom security features etc.) for your custom product use. Lynx has expertise in enabling secure boot and establishing chain of trust on products using Qualcomm Snapdragon processors. Contact us to help accelerate securing your Qualcomm Snapdragon-based product.
References: Secure Boot and Image Authentication – Qualcomm
Lynx has extensive experience with embedded system development and lifecycle management. Lynx has been instrumental in working with global semiconductor leaders to provide smart, quick, high-quality solutions for highly complex systems involving accelerated product innovation and multiple product variants.