Security of the boot chain is a vital component of any other security solution, said Matthew Garrett of CoreOS in his presentation at Linux Security Summit. If someone is able to tamper with your boot chain then any other security functionality can be subverted. And, if someone can interfere with your kernel, any amount of self-protection the kernel might have doesn’t really matter.
“The boot loader is in a kind of intermediate position,” Garrett said. It can modify the kernel before it passes control to it, and then there’s no way the kernel can verify itself once it’s running. In the Linux ecosystem, he continued, the primary protection in the desktop and server space is UEFI secure boot, which is a firmware feature whereby the firmware verifies a signature on the bootloader before it executes it. The bootloader in turn verifies a signature on the next step of the boot process, and so on.
Garrett admitted that it’s difficult to protect against hardware attacks in any straightforward way. If someone has a hardware keylogger, for example, secure boot will not help you there. But, he said, “there are other things we can protect against, and measured boot is a component of such protection.”
“Measured boot is based around trusted computing,” Garrett explained. One of the hardware components of trusted computing is the trusted platform module (TPM).
Something Magical
At boot time, Garrett said, we measure things, and we store those measurements in platform configuration registers (PCRs). The idea is to store something that represents the next part of the boot process. So, the firmware measures the boot sector, the boot sector measures the boot loader, and the boot loader measures the kernel. PCRs, however, are not directly writable; you have to ask the TPM to store some data in there and then “something magical happens.”
If you could set PCR values directly, you could potentially change values at any point and defeat the object entirely. To prevent this, the existing value of the PCR is taken along with the new value, and they are concatenated, producing a 40-byte value. Then, the hash of that value is taken and that is the value that is stored. Like magic.
Outside system memory, there’s an associated log, and each measurement event also results in a new log entry describing the value. However, it’s stored in RAM and is easily overwritten — more on this later.
To have measured boot, Garrett continued, you need to be able to measure each component, which means you need firmware that can do this and you need support in the later part of the bootchain. However, no standard Linux bootloader does this out of the box, he said.
So, Garrett decided to write his own support code, which is partly based on trusted GRUB and partly written from scratch. And, now he has a bootloader that supports measuring the kernel, but things are not so simple. Other things can occur to alter the security of the system, Garrett said. The configuration that’s passed to the kernel, for example, is very relevant. The command line is relevant. And, measuring what happens during the GRUB phase is pretty important.
Known Policy
Let’s go back to the logfile mentioned earlier — it’s just stored in RAM so it can be overwritten, but Garrett described improvements that involve matching a known policy against log entries. Where does this policy come from? CoreOS builds it automatically. As of three months ago, Garrett said, every release they build ships with a file describing the known good hashes for every component of the operating system and a policy that describes a valid GRUB configuration. Nonetheless, he said, this approach is not complete. You still need to validate firmware — which is not provided by CoreOS — and he doesn’t know any firmware vendors doing that.
Garrett said you could also ask the TPM to encrypt data and only decrypt it if the PCR values match the imposed policy. He described an example using a one-time password (OTP) generator. You run this, it prints a QR code, and you scan the QR code with your phone. When the system boots, it shows you a 6-digit number, and you make sure that the 6-digit number on your phone is the same as the one on your computer. If the TPM decrypted this number, you know your system has not been tampered with.
An unsolved problem, Garrett said, is that when you upgrade the firmware, the PCR values will change and the disk will refuse to decrypt your OTP key. And then your system won’t boot. A solution is needed that seals the information when you perform system updates, and this problem needs to be solved to make measured boot truly usable, he said.
An audience member asked whether there were plans to upstream Garrett’s trusted GRUB 2 code. The short answer is yes. Garrett said, “After a certain amount of discussion with Richard Stallman, I finally managed to convince him that we could use TPMs for purposes of good rather than being intrinsically evil.”
However, Garrett said, GRUB 2 has new maintainers, with whom he will need to work out some copyright issues. Part of the new code is based on old GRUB, and Garrett can’t assign copyright for code he didn’t write. Ideally, these issues will be addressed, and the code will be upstreamed.
Watch the complete presentation below:
You won’t want to miss the stellar lineup of keynotes, 185+ sessions and plenty of extracurricular events for networking at LinuxCon + ContainerCon Europe in Berlin. Secure your spot before it’s too late! Register now.
