3

After some research, my current understanding of Android's boot sequence (at least on a Qualcomm device) is as follows:

PBL --> XBL (replaces SBL) --> Aboot --> Kernel

PBL:

  • Primary Boot Loader (sometimes called bootROM).
  • First piece of code executed after device is powered on (therefore PBL is the Root of Trust)
  • Built and distributed on the SoC by Qualcomm themselves
  • Truly is ROM (Cannot be updated)
  • Contains a public key that is used to verify the integrity of XBL. The corresponding private key is in Qualcomm's possession.
  • Has access to a device-unique 256-bit auth-key that is required to write to the RPMB partition (link)

XBL:

  • Extended Boot Loader
  • XBL supersedes the older SBL (link)
  • Proprietary Qualcomm solution (i.e. provided by, and signed by Qualcomm)
  • In some cases, it can be customized by OEM for a price (link)
  • Lives on the eMMC (in the boot0 hardware partitions?)
  • Contains a public key that is used to verify the integrity of Aboot
  • Can be updated

  • Since it lives on the eMMC, a user with root privileges can modify it and potentially brick the device:

    http://trac.gateworks.com/wiki/MMC

    Note that the BOOT partitions by default are read-only as they are typically used for sensitive boot firmware. To write to them you can disable force_ro in sysfs

Aboot

  • Android Boot Loader
  • Provided by the OEM
  • Depending on the OEM, can be partially open source, or closed source (e.g. Samsung) (link)
  • Must be signed (I'm assuming by the OEM and not by Qualcomm, which means that the public key in XBL must be the OEM's public key?)
  • Lives on the eMMC (in the boot0 or boot1 hardware partition? Or perhaps in the User Data hardware partition)
  • Contains a public key that is used to verify the integrity of the kernel/OS (aka ROM) before loading it. However if Aboot is "unlocked" any ROM can be loaded)
  • Can be updated
  • Since it lives on the eMMC, a user with root privileges can modify it and potentially brick the device.

Questions

In addition to the questions I sprinkled above.

  1. Is it safe to assume that millions of Qualcomm devices all have the exact same public key programmed in PBL?

  2. The public key in PBL cannot be changed. Correct?

  3. If Qualcomm's private key was somehow compromised, verified boot could no longer be trusted on all affected devices permanently?

el_tigro
  • 694
  • 8
  • 14
  • XBL isn't really [the same](https://worthdoingbadly.com/qcomxbl/) across phones and generations and it can also contain itself the SBL. For the remainder, I can only recommend you [these](https://www.cnblogs.com/linux-xin/p/8124509.html) [chinese](http://huaqianlee.github.io/2015/08/15/Android/%E9%AB%98%E9%80%9A%E5%B9%B3%E5%8F%B0Android%E6%BA%90%E7%A0%81bootloader%E5%88%86%E6%9E%90%E4%B9%8Bsbl1-%E4%B8%80/) [posts](https://www.codeleading.com/article/301780475/). And the original [QCOM whitepaper](https://www.qualcomm.com/documents/secure-boot-and-image-authentication-technical-overview-v10). – mirh Mar 23 '20 at 20:49

2 Answers2

2

I can't speak to Qualcomm or Android in particular, but any time that you're doing code signing, the client needs to begin its chain of trust somewhere. And an immutable, non-upgradable, non-revocable public key pinned in firmware is as good a way to do that as any.

A non-upgradable root public key makes sense (proof by induction)

You asked:

  1. The public key in PBL cannot be changed. Correct?

Proof sketch:

  1. Any software component that needs to be field-upgradable needs to be able to verify the integrity and authenticity of its software prior to running it.

  2. Verifying software integrity and authenticity is typically done via digital signatures.

  3. The device must have or be able to obtain the public key that performed the digital signature.

  4. If this public key is itself contained in a field-upgradable block of code or data, then the integrity and authenticity of that must be verified via digital signature.

  5. The device must have or be able to obtain the public key that performed the digital signature.

  6. If this public key is itself contained in a field-upgradable block of code or data, ...

This becomes an infinite stack of turtles (or in this case, public keys), and the only way it can terminate is if there is some root public key which is not field upgradable, ie we have absolute trust in that key and do not need to verify its integrity and authenticity.

QED.

Answering your other two questions (in backwards order)

  1. If Qualcomm's private key was somehow compromised, verified boot could no longer be trusted on all affected devices permanently?

Pick any PKI structure (the public HTTPS PKI, the DNSSEC PKI, the Windows Code-Signing PKI) and there will always be an analogous doomsday scenario about the topmost root key being compromised. That's just how PKI works.

To protect against this, Certificate Authorities invest ludicrous amounts of time and money into HSMs, network security equipment, and human policies to protect the root keys. But at the end of the day, we sortof rely on good old fashioned word of mouth (ArsTechnica, Twitter, Reddit, etc) to tell us if one of these root keys becomes compromised.

  1. Is it safe to assume that millions of Qualcomm devices all have the exact same public key programmed in PBL?

Some companies will keep separate code-signing PKIs for separate product lines so that one product line can be revoked without affecting the others. Realistically though, if they have a massive breach on that scale, then nobody's gonna trust anything anyway, so why bother?

Mike Ounsworth
  • 57,707
  • 21
  • 150
  • 207
2

I know this is old but I just wanted to add to the existing answer that if the OEM has not blown certain fuses you can use a different PBL.

From your first link

If the QFUSE fuse row labeled Qualcomm Secure Boot is blown (which is such on non-Chinese/OnePlus deivces), PBL (Qualcomm’s Primary Bootloader) is verified and loaded into memory from BootROM, a non-writable storgage on the SoC.

So while it is ROM, most of it doesn't have to run if you have the right device.

Deoxal
  • 121
  • 1