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