Qualcomm’s Chain of Trust
WRITTEN ON SEPTEMBER 17, 2018 BY NOLEN JOHNSON (@NPJOHNSON)
The Qualcomm chain-of-trust is a complex, yet straightforward to understand set of processes.
Many of you have likely heard the term “bootloader” but have no clue what it actually is, or does.
In today’s post, the above will be covered as it pertains to Qualcomm chipsets.
Glossary
Bootloader: A general term for a link in the boot-chain that has a specific job that is run each
cold-boot
cold-boot: Fresh boot from powered off state
QFUSE: Microscopic hardware fuse that is integrated into the SoC - Once physically blown,
impossible to reset or replace
SoC: System-on-chip (your phone’s “motherboard” of sorts)
EFUSE: Software based fuse whose data is stored in QFPROM
QFPROM: Qualcomm’s fuse region
TrustZone: Qualcomm ARM chipset’s “Secure World” implementation
QSEECOM: A linux kernel driver that lets us communicate with TrustZone, and issue an SCM
call to TrustZone to do things like blow fuses. It only will allow signed applets and approved
calls to be made
SCM: Secure Channel Manager (note: not related to Linux’s SMC calls)
DTB: Device Tree Blob. Its purpose is to “provide a way to describe non-discoverable
hardware” to Linux, read more here
Android Verified Boot (AVB): A strict set of checks implemented at the aboot/ABL level to
verify the integrity of various parts of the operating system, read more here
DM-Verity: A component of Android Verified Boot that checks partitions to see if they have
beeen mounted read/write before, read more here
system_as_root: A new mount setup logic for android that mounts the system partition as ‘/’
as opposed to ‘/system’. This means that system files now live at ‘/system/system’. This is a
way for Qualcomm to check whether ‘/’ has ever been remounted read/write under Verified
Boot. It also introduces the new standard that the Android ramdisk be stored on the system
partition, as opposed to being stored in the boot image
What is Qualcomm’s Chain of Trust/Boot
Sequence?
Qualcomm device’s chain of trust, bootloader sequence, and Secure World.
Information
A bootloader by definition is a program that loads an operating system, or chain-loads another
bootloader when a device is turned on.
Qualcomm devices all use fuse based logic to dictate permanent feature
configurations/cryptographic key sets. As stated above, the physical version of which is called a
QFUSE, and is stored in a region on the SoC called QFPROM in rows.
If the QFUSE fuse row labeled Qualcomm Secure Boot is blown (which is such on nonChinese/OnePlus devices), PBL (Qualcomm’s Primary Bootloader) is verified and loaded into
memory from BootROM, a non-writable storage on the SoC. PBL is then executed and brings up a
nominal amount of hardware, then verifies the signature of the next bootloader in the chain, loads
it, then executes it. The next bootloader(s) in the chain are SBL*/XBL (Qualcomm’s
Secondary/eXtensible Bootloader). These early bootloaders bring up core hardware like CPU cores,
the MMU, etc. They are also responsible for bringing up core processes concurrent to Android such
as the Secure World for Qualcomm ARM chipsets known as TrustZone. The last purpose of
SBL*/XBL is to verify the signature of, load, and execute aboot/ABL. Aboot is what the large
majority of you refer to as “bootloader mode”, as it is where services such as fastboot or OEM
firmware flashing tools are housed. Aboot brings up most remaining core hardware then in turn
normally verifies the signature of the boot image, reports the verity status to Android Verified boot
through dm-verity, then pending success of the previous two steps loads the kernel/ramdisk/DTB
into memory. On many devices, Aboot/ABL can be configured to skip cyptographic signature
checks and allow booting any kernel/boot image. After aboot has loaded everything into memory,
the kernel (in our case, Linux) then unpacks the ramdisk either from the boot image, or in
system_as_root configurations, the system partition is verified and mounted at ‘/’ and the ramdisk
extracted from there. Shortly after this init is executed, which brings up Android as we know it.
The configuration option to disable cryptographic checks in aboot/ABL is often referred to as
“Bootloader Lock Status”. When a device is referred to as “locked”, that means that aboot is
currently enforcing digital signature integrity checks by aboot/ABL on the boot image of the device
and on newer devices, enforces a “Green” Android Verified Boot status. These “locked” devices don’t
allow the user to flash partitions, and cannot boot custom unsigned kernels. If a locked device is
considered secure, Android Verified Boot will usually report “Green” and allow the device to
continue booting, if it is considered insecure, it will report “Red” status and prevent the device from
booting. On “unlocked” devices, aboot/ABL lets the device flash, and some OEMs allow booting
unsigned boot images from memory (fastboot boot), in which case Verified boot reports either
“Orange” or “Red” depending on whether the images are signed or not, but regardless allows the
device to continue booting.
Maturity of the Chain:
The Qualcomm chain of trust has grown immensely in security in the last decade.
Diagrams to describe the maturity process of the chain of trust follow:
Pre-2013 Era
2013-2016 Era
Modern (2016-2018) Era
As you can see, the boot chain has evolved significantly. In 2015, the possible attack area was
condensed, and the Secondary Bootloader (SBL) chain was merged into one unified SBL. As we
move further down the line we see SBL entirely replaced with Qualcomm’s new proprietary solution,
the eXtensible Bootloader (XBL), which mitigated many of the security issues SBL presented.
Aboot has also matured from LittleKernel (an open source bootloader) with some additions into a
fully independent solution now called the proprietary Android Bootloader (ABL). This new
bootloader allows the use of UEFI, among many other security and quality-of-life enhancements for
developers/OEMs.
The system_as_root configuration has also improved security, as well as the general architecture
significantly. It moves the Android-ramdisk from being stored in the boot image to being stored in
the system partition, which as the name would imply, is mounted as ’/’. This was done in part to
allow it to be verified by dm-verity/Android Verified Boot.
NOTE: The new seamless update system coined “A/B” is separate from system_as_root even
though they are commonly seen hand in hand. OEM’s have the option of implementing one and not
the other.
OEM Additions
Many OEM’s implement additional cryptographic checks into their bootloader sets to attempt to
further security, or present a function (like allowing bootloader unlock to the end user).
Several prevalent examples:
Samsung’s use of the eMMC CID/a corresponding hashed blob of the CID in the aboot image
to dictate developer (unlock) status.
Samsung’s “KNOX” QFUSE that is blown on any intrusion, and can be configured to wipe the
device if triggered.
Motorola’s use of a single QFUSE that must be blown to unlock the device, permanently
voiding the warranty.
Sony’s use of a cryptographic blob and a bit set on their “TA” partition to allow unlock.
OEM’s also often implement their own proprietary mode, that has a variety of uses. Some
examples include:
Samsung’s proprietary Download mode for firmware flashing.
LG’s proprietary LAF (Download) mode for firmware flashing.
Google’s OSS Fastboot mode for firmware flashing.
OEM specific functions/modes often have major advantages over the general solution, like the fact
that Motorola was one of the first OEMs to extend the fastboot protocol to allow the flashing of
sparse-chunked system images. However, these solutions are also very likely to have unforeseen
security vulnerabilities, such as LG’s frequent LAF mode vulnerabilities, or the SamDunk
vulnerability that used Samsung’s CID method to unlock otherwise non-unlockable devices).
It is also important to note that while OEMs can customize aboot/ABL, and for a price, SBL*/XBL,
that PBL is built and distributed on the SoC by Qualcomm themselves. PBL very rarely sees public
exploits, as most fetch a large bounty throught Qualcomm’s Bug Bounty Program, though PBL has
seen a few public vulnerabilities before, such as Aleph Security’s EDL (Qualcomm Download Mode)
vulnerabillties, which you can read about here.