Chain of Trust in the Secure Boot Process

Tying your laces: How to secure the boot

In our previous post, we described how the early moments of smartphone power-on involve a set of boot loaders sequentially handing off control after making incremental progress. These increasingly complex programs essentially run a relay race to bring a computer or smartphone into a usable state.

But what happens if one of these boot loaders is intentionally modified by a malicious actor or becomes corrupted? It could cause the system to crash or, even worse, run malicious code. We’ll now turn to more recent developments in how a secure boot process achieves both reliability and security.

Fingerprinting the code

In modern mobile operating systems such as iOS and Android, which we have spent thousands of hours analyzing in various contexts, each boot loader is responsible for verifying the integrity of the next boot loader by verifying its digital signature. Each boot loader contains not only executable code, but also a pre-computed digital signature of the next boot loader.

Before running the next boot loader, the current boot loader verifies the pre-computed digital signature by transforming the source code of the next boot loader into a much shorter random-looking string of numbers using a procedure known as a hash function. By comparing the checksum calculated by the hash function with the pre-computed digital signature, the current boot loader can check both the integrity (is this code valid?) and authenticity (is this the code the manufacturer intended?) of the next boot loader. The idea is that if the code of the next boot loader has changed in any way, it would be effectively impossible for the calculated checksum to match the pre-computed digital signature.

In practice, a hash function usually involves some advanced mathematics, but any function that summarizes data with a number could qualify. For example, a simple word count could be considered a checksum of a blog post. In our expert consulting engagements, we regularly use checksums to efficiently identify files with identical contents.

Trusting the fingerprint

A checksum works fine for confirming that no data corruption errors exist, but one might wonder if there is a loophole in the above process as described: if a malicious actor (or a reverse engineer, perhaps employed by us) changes the code of the next boot loader, couldn’t he or she just as easily change the pre-computed digital signature to match? Some assurance is needed that the pre-computed digital signature comes from a trusted source, and this is where another layer of cryptography comes in to play.

The current boot loader interprets the pre-computed digital signature not simply as a checksum, but as an encrypted checksum. The current boot loader decrypts the pre-computed digital signature using an associated random-looking number in the software, a certificate. The information needed to encrypt the pre-computed digital signature (a private key that is associated with the certificate) is known only to the manufacturer, and therefore the encryption cannot be performed by any other party such as a malicious actor who is modifying the source code of the next boot loader. The current boot loader uses the digital signature not only to verify the executable code of the next boot loader, but also the certificates that are contained within (and will be used by) the next boot loader.

Digital signatures like these appear in a wide range of modern software systems, from secure text messaging to cryptocurrencies. We regularly find ourselves documenting, manipulating, and critiquing digital signature schemes in the context of our technology analysis projects.

Anchoring trust

A digital signature would seem to have the same problem that an unencrypted checksum would present: a malicious actor/reverse engineer could overwrite a certificate too, so that the pre-computed digital signature not only matches but also appears to come from a trusted source. How can we confirm that the certificates themselves have not been manipulated?

The solution is that the very first boot loader stage uses a certificate that is written into the device hardware and cannot be modified. Because both the code and certificates of every sequential boot loader stage are subject to these digital signature checks, they cannot be modified without causing one of the digital signature checks to fail, causing the secure boot process to abort.

This general description of a digital signature check is a substantially simplified version of Qualcomm's chain of trust implementation. Cryptographic “chains of trust,” such as secure boot loaders being verified in sequence, lie at the core of many cryptographic systems that we have analyzed and explained in the context of our litigation engagements.

In two weeks, we’ll be back with another post about how operating systems with secure boot have changed how consumer devices are regulated and used. In the spirit of chain-of-trust, this post will conclude with the checksum 782, and if you confirm this number is the word count of the next post, you will have just performed hash validation! If you have burning questions about secure boot and don’t want to wait for (or don’t have the patience to read) the next post, pick up the phone and give us a call; the first call is always free.

Chain of Trust in the Secure Boot Process

Daniel W. Steinbrook

Technology Strategy & Analysis

June 18, 2019