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 by use digital signatures and certificate chain.
Secure Boot process overview
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 (eg: 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 of Linux kernel, device tree and an optional initramfs. The initramfs can contains scripts to verify the authenticity of the root file system (RFS) using dm-verity or mount a 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 sources 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.
An overly simplified process for signing the bootloader is as below:
- Create a root public / private key pair and certificate using openssl
- Create a attestation (intermediate) public / private key pair and certificate using openssl. The attestation certificate can help limit exposure to compromised keys.
- Compute root public key hash
- Setup config.xml used by sectools to use the above generated keys/certs
- Run sectools to sign SBL, generate sec.dat
- The signature and certificates will be automatically appended to SBL
- Burn the sec.dat file to eMMC using fastboot
- SBL will securely flash the contents of sec.dat onto eFuses on next boot (assuming fuses are not already blown and write protected)
The sectools is setup to sign additional Qualcomm proprietary binaries such as rpm.mbn, tz.mbn, hyp.mbn and the open source LK bootloader in a similar fashion.
Signing the Linux kernel
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 is to sign the boot.img is:
- Create a public/private key pair and certificate using openssl
- Create a sha256 digest of boot.img
- Sign the sha256 digest with the private key
- Append the signed digest to boot.img
- Clone the LK bootloader source
- Extract the public key out of the cert using openssl and place it in platform/msm_shared/certificate.c of LK bootloader source
- Build LK bootloader with “SIGNED_KERNEL=1” argument
Extending the chain of trust to user space
There are multiple options to extend the chain of trust to user space as previously discussed in this blog post. We will discuss the 2 commonly used mechanisms here, signed RFS using dm-verity (read-only RFS) and encrypted RFS using dm-crypt (read-write RFS).
Signed root filesystem
Extending the chain of trust to user space (root file system), can be achieved by 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 a initramfs which supports verifying the dm-verity table.
Encrypted root filesystem and user data
Encrypting data ensures confidentiality which is critical for user data protection (eg: for compliance like HIPAA) and intellectual property protection (eg: 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 a external security chip like 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 a 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 SBL executes at a security level that can access the eFuses, the SBL can be modified to read the keys and pass it on to 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.
Other security considerations
In order to minimize the attack surface for secure boot, it is highly recommended to perform the following steps for added security:
- Disable alternate boot mediums (USB, SD card etc)
- Disable JTAG access
- Review the permissions to the security related eFuses and lock further modifications to this fuse bank
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.
Timesys 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. Timesys 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
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.