Secure boot on Snapdragon 410

by Akshay Bhat | August 23, 2018 | Embedded Development, Security | 0

comments

Qualcomm Snapdragon processors support secure boot which ensures only

authenticated so!ware 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 so!ware 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 a!er
signing an NDA.

Signing Bootloaders
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:

1. Create a root public / private key pair and certificate using openssl

2. Create a attestation (intermediate) public / private key pair and certificate

using openssl. The attestation certificate can help limit exposure to
compromised keys.

3. Compute root public key hash

4. Setup config.xml used by sectools to use the above generated keys/certs

5. Run sectools to sign SBL, generate sec.dat

1. The signature and certificates will be automatically appended to SBL

6. Burn the sec.dat file to eMMC using fastboot

1. 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:

1. Create a public/private key pair and certificate using openssl

2. Create a sha256 digest of boot.img

3. Sign the sha256 digest with the private key

4. Append the signed digest to boot.img

5. Clone the LK bootloader source

6. Extract the public key out of the cert using openssl and place it in
platform/msm_shared/certificate.c of LK bootloader source

7. 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 so!ware support
for full disk encryption by leveraging Qualcomm secure execution
environment (QSEE) so!ware running on ARM TrustZone to read the keys from
eFuses. As of writing this blog, so!ware 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:

1. Disable alternate boot mediums (USB, SD card etc)

2. Disable JTAG access

3. 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.

Conclusion
Qualcomm Snapdragon processors have excellent hardware support for
implementing security on embedded/IoT devices. While Qualcomm Android
so!ware 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

Akshay Bhat is Technical Director – Security at Timesys. Akshay’s experience with

embedded systems spans a broad range of industries with a focus on board bring-up,
driver development and so!ware security. Akshay received his MS in Electrical
Engineering from NYU Polytechnic University.

About Timesys
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.

This site uses Akismet to reduce spam. Learn how your comment data is
processed.