Hackers keep devising unique new ways to circumvent traditional anti-virus/anti-malware software but with a secure boot process, it becomes extremely difficult if not impossible to gain malicious entry into a system. The bootloader is the first code that is executed after the board is powered up. The bootloader performs initialization of low-level hardware like clocks, memory, communication etc and is therefore highly coupled with the hardware. A boot process is considered vulnerable when bootloader attacks use the boot process itself to load malicious code masquerading as a legitimate operating system, prior to the loading of the real OS. The secure boot process is a way to prevent such attacks to the system before the bootloader is started and to ensure that the bootloader and kernel code are from trusted sources.
Due to the complexity of today’s SOCs it is common to have multiple bootloader stages where one bootloader starts another one and the Snapdragon’s™ boot process is no different. Each image in the stage performs a specific function, and each image is verified by the previous image (e.g., Primary Boot Loader (PBL) → Secondary Boot Loader (SBL) → ARM® TrustZone). The root of trust (the most trusted entity that kicks off this process) is the PBL, which is firmware that is pre-installed on the Snapdragon’s ROM by Qualcomm and therefore already trusted. Before the next image in the boot up sequence is executed, that image is first authenticated to ensure that it contains authorized software. For example, control passes to the SBL only after it has been successfully authenticated by the PBL. The APQ™ ASICs contains a CA root key that is associated with Qualcomm. In Secure Boot mode, the on-chip Primary Boot Loader (PBL) uses this key to establish the identity of the off-chip Secondary Boot Loader (SBL) and AMSS code authors via cryptographic signatures and certificates. Since the SBL is now trusted, it can be trusted to authenticate the next image of the boot process and so on until the kernel image. On newer processors like Snapdragon 820, the SBL is replaced by eXtensible Boot Loader or XBL. XBL’s advantage is that the code size is reduced when compared to SBL and has migrated to the UEFI build environment which is a specification that defines a software interface between an operating system and platform firmware. The individual images further establish the security of the device through their functionality. With these pieces of cryptographic components and architecture in place, the authenticity of the boot up software and secure applications is validated.
Secure boot is not guaranteed without blowing a series of eFuses (named QFPROM by Qualcomm) in addition to the images being signed. To sign the images, a trusted vendor uses their private key to generate a signature of the raw code that they want to use, and adds this signature to the device alongside the software binary. The device contains the corresponding public key of the vendor, which can be used to verify that the binary was not modified and that the trusted vendor in question provided it. Images can either be signed using Qualcomm’s proprietary Code Signing Management System (CSMS), or using the vendor’s own code signing system. Signed images include the code signature and the certificate chain. The certificates carry the public keys used to decrypt the certificate and image signatures. An overview of the secure boot architecture is shown below.
Qualcomm’s trust hierarchy scheme extends over multiple certificates where:
- The first level or Attestation certificates attest to the integrity of the code author and are used to validate the code signature
- The second level or Attestation Certificate Authority certificates validate the first level attestation certificates
- The third level or Qualcomm’s Root certificate Authority validates the Attestation Certificate Authority
Thus, a chained approach is used to authenticate an image as described earlier. First, the certificate chain of the image is validated. For example, the XBL authenticates the Applications Boot Loader (APPSBL) image using the APPSBL’s certificate chain. The attestation certificate in the chain is authenticated against the intermediate certificate (attestation CA), which in turn is authenticated against the root CA. The root certificate itself is authenticated against the hash provisioned in an immutable area – QFPROM or Qualcomm’s key table residing in a trusted area. The required certificates can be generated using OpenSSL and the bootloader images are signed with these certificates using a proprietary tool from Qualcomm called Gensecimage.
Inforce, being an AMSS (Advanced Mobile Subscriber Software) licensee, can enable secure boot on any of its platforms running Android for OEMs/ODMs whose use-cases obligate maximum security on their platforms.