This is coming from Qualcomm's Secure Boot explanation. https://www.qualcomm.com/content/dam/qcomm-martech/dm-assets/documents/secure-boot-image-authentication_11.30.16.pdf

Within it, it explains that each bootloader loads and verifies the next bootloader within the chain. It also explains the verification of a bootloader with the following image.

enter image description here

What is unclear to me, however, is if the certificates (Root CA cert, Attestation CA cert, Attestation cert) for the next bootloader are contained within the data of the previous bootloader or if certs are contained outside separately?

And if the certificates are contained within the previous bootloader, wouldn't that mean you would only need the Attestation certificate (or Attestation CA cert + Attestation cert) beyond the first bootloader? It doesn't make sense to me that each bootloader image would have a "Root CA" if the previous bootloader would be attesting the next bootloader.

Also, in such a secure boot chain, are all the private keys for each step stored in a single private vault?

1 Answer 1


Qualcomm Snapdragon SOC uses a chain of 2 bootloaders to boot android bootloader (ABL) stored in /boot partition of the flash chip storage. Each bootloader image contains a hash segment that stores a complete chain of X509 certificates of its own. The first bootloader of the SoC which is called Primary bootloader (PBL) is an immutable image burned into the CPU die. The certificate chain is validated back to a root certificate as follows:

  1. It verifies its own signature by the public key of Attestation Certificate which is a leaf certificate issued by intermediate certificate authority (Attestation CA) of Qualcomm.

  2. The signature of the attestation certificate is verified by the public key of Attestation CA Certificate issued by Root CA of Qualcomm. The signature of attestation CA certificate is verified by the public key of the Root CA Certificate.

  3. The hash of the root CA certificate is stored in eFuse which acts as a root of trust.

Are all the private keys for each step stored in a single private vault?

In Public key infrastructure, the corresponding private key of the CA is not stored on device. The private key is only needed by CA to sign the certificate and is kept by CA at its organization. The chain of certificates is then embedded into the image of each bootloader.

Following the same process, the primary bootloader verifies the Extensible Bootloader (XBL) and the extensible bootloader verifies the android bootloader. In total, the attestation CA certificate and the root CA certificate are being verified 6 times (2 times for each bootloader assuming the intermediate certificate authority is same for all 3 bootloaders) during the entire boot process.

This design looks complicated but it has to be this way because the primary bootloader cannot be updated so if the previous bootloader was acting as the root of trust for the next bootloader, the certificate revocation would not have been possible. With the current design, you can periodically rotate leaf certificate with OTA updates and intermediate certificate authority can be also changed without updating the previous bootloader. It also allows OEMs to use their own chain of trust for android bootloader without relying on Qualcomm to attest their leaf certificate.

Whether or not to enforce secure boot is decided by if its eFuse is blown or not. It is blown for production devices in the factory which permanently enables the secure boot. OEM "HMD Nokia" also has a custom fastboot command to blow the eFuse by executing fastboot oem SecureBoot EnableFuse command in the bootloader mode. eFuse array once they are blown cannot be overwritten but it can be replaced by an adversary. If an attacker is able to replace secure boot eFuse with the intact one, he will be able to disable secure boot and can execute arbitrary code in XBL and ABL.

The only weak entity I find in this flow is that how eFuse is being used here in an obscure manner to act as a root of trust. Unlike Trusted Execution Environment (TEE) chip, eFuse does not have a standardized security compliance certification like Evaluation Assurance Level. They are embedded in a way that replacing them requires dismantling of the CPU which will likely break the CPU together with the integrated TEE storage but its layered hardware obscurity is not as good as smart cards have.

Secure Boot and Image Authentication, Technical Overview (v2.0), August 2019 pdf

  • Thank you so much for your response. So when you say "the primary bootloader verifies the Extensible Bootloader and the extended bootloader verifies the android bootloader" it doesn't actually mean that a certificate or a key is embedded in the PBL. It just means that PBL would use the attestation cert and root cert to verify the XBL. Then does XBL use the same root cert and attestation cert as PBL? Commented Aug 14, 2023 at 10:00
  • If XBL uses the same certs as PBL, would that mean the certs are the same but the corresponding private keys are different for the two bootloaders? Commented Aug 14, 2023 at 10:09
  • By the way, it seems like you might work in Automotive cybersecurity. I think we could be great career buddies! Would love to talk with you. chat.stackexchange.com/rooms/info/147879/… Commented Aug 14, 2023 at 10:38

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .