Intel Boot Guard
So some innocent post on the coreboot mailing list managed to make some waves.
The problem Intel tries to solve…
Intel Boot Guard is the latest effort in a long series by Intel and others to allow computers to provide some reliable information about the state a computer is in. They’re working on it since at least 2003, with projects and trade groups named Palladium, TCPA, and now TCG, and some of them faced scrutiny in the past already because the freedom of computing was deemed under attack (realistic fears, but with some unnecessary hyperbole).
The scheme Intel and others in those trade groups developed ultimately requires a separate processor in system that keeps track of the system state and is able to keep secrets from the CPU until it proves that the system is in a safe state. That processor is called TPM (short for Trusted Platform Module).
From the beginning the TPM was designed as a passive component: Some other part of the system needs to update the TPM’s view of the platform, the TPM is not able to lock down any component in the system except access to its own memory.
The TPM consists of some way to keep track of the system state, some non-volatile memory (for the “secrets”), a way to bind secrets to system states, and it also provides some cryptographic operations - among them: creating RSA keypairs, and working with them.
One major design issue is where the trust is rooted in: The first verification of signatures happens by code on the CPU, so if you are able to intercept that and replace it with your own, it’s trivial to emulate a “properly” booted system (by just sending the right values to the TPM). Moving that issue ever earlier in the boot process, the last frontier is eventually the bootblock, the part of the firmware that contains the first instructions executed by the CPU: Since it comes first, it verifies the part that comes after it, which again verifies its successor, and so on. Analogous to a proof by induction, the entire system state remains well-known as long as the first component tests the next component, and every other component does likewise. But if you can’t trust the bootblock to send a truthful state into the TPM, you have already lost.
Enter Boot Guard: It allows the hardware vendor to lock down the boot block with a key they write into the CPU so the machine only starts if the code matches that key.
… and its very own problems
The main grief with this approach is that this key can’t be rewritten once it is in. So when the hardware vendor (say Lenovo) sets this key, they are the only ones who can provide firmware to the machine, even if the owner of the machine wants something else.
In combination with the complexity of UEFI, which commonly includes a network stack (and thus the capability to communicate with the world) and the ability to load and execute code (eg. through the net), some people are uncomfortable with that prospect.
Others just want the ability to replace all code on a system, including firmware, as a matter of principle - and since they own their machines, I find it really hard to argue that these people shouldn’t be able to.
There’s more to it: Verified Boot vs. Measured Boot
But this isn’t the whole story to Intel’s Boot Guard. The option of installing a key is what Intel refers to as “Verified Boot”. It’s described in some short words on their product brief for these CPUs.
That document also talks about another mode, “Measured Boot”. In this mode, Boot Guard creates a hash over the bootblock and sends it off to the TPM. The value is stored in one of TPM’s plenty registers, and in particular in a register that isn’t writable by code running on the CPU (there’s some circuitry to make sure of that). This is supposed to prevent replay attacks in which it would be possible to fake a certain Boot Guard state if an attacker manages to disable Boot Guard altogether.
User friendly security, powered by Boot Guard
Since the TPM is able to bind data it stores to those registers, it’s possible to verify the system state against a key stored in the TPM that is bound against a known good state:
In the factory, have the TPM create a keypair, and bind it against the bootblock that is installed. Export the public part of the key (the TPM won’t relinquish the private one, so this operation is safe).
When trying to assert if the system is still in a good state, encrypt a random value (nonce) with the public key, and send it to the system to test. If it can decrypt the value and send it back, the state is known (otherwise the TPM wouldn’t use the right key), and everything is fine.
Windows could use this for Domain logins, to assert that the system wasn’t tampered with. For personal users the Windows Account / Store / Update could check if anything suspicious is going on: you already have to register the machine with Microsoft when using Windows, so why not use it for something user-friendly?
Or bind the encryption key for the disk against that state, so the data is only readable in that computer with that firmware. (Since TPM crypto is so slow, this is somewhat more involved, but conceptually that’s what can be done with it)
A user installing their own firmware (including bootblock), will lose access to data on such an encrypted disk, and to a Domain that does this verification. From a security perspective, both are desirable.
But they can use Boot Guard with their own firmware, and encrypt the disk with their own secret stored within the TPM. Contrast that with “Verified Mode” where overwriting the firmware just transforms their computer into a nice, expensive, dead brick.
So what went wrong?
The issue isn’t that Intel added Boot Guard to their platform. It’s that Intel provides the Verified Boot mode. Had they not done that, the effort would be universally lauded as a technology that improves the security of their users (and without ripping holes in their security fabric like Intel TXT did).
But as is, as Matthew Garrett states, “vendors are forced to choose between security and freedom”. And that’s an exercise most vendors routinely fail to do properly.
So Intel, please - protect the vendors from themselves, and your users from the vendors that connect you with your users, and do the right thing: Drop Verified Boot in future chipsets, and discourage vendors from using it now.