Some people who installed the Fedora 24 Alpha from scratch on bare-metal BIOS-based systems may have found that their system didn't boot. Sorry about that - it's my fault, and it's fixed now. But it happened as a result of some new code in grub that gives us some really exciting functionality. Trusted Platform Modules (or TPMs) are small devices that sit on many system motherboards. They're usually attached over the LPC bus, which means two things: 1) Communicating with them isn't very fast 2) There's no support for device-initiated DMA, which means there's no way they can directly read system state Measured boot is a process whereby each component in the boot chain "measures" the next component. In the TPM 1.x world (which is where most of us still are), that measurement is in the form of a SHA1 hash of the next component. So, on a BIOS system, the firmware measures itself, the firmware measures its configuration, the firmware measures any option ROMs on plugin cards, the firmware measures the MBR of the disk, the MBR measures the grub stage 1, the grub stage 1 measures the grub stage 2, the grub stage 2 measures the kernel and so on. Each of these measurements is written into a register on the TPM called a Platform Configuration Register, or PCR. Attempting to write to a PCR doesn't directly replace the old contents with the new value. Instead, the TPM concatenates the two values and stores the SHA1 of that concatenated value. Unless you've comprehensively broken SHA1, there's no way for you to set a PCR to a specific value unless you perform exactly the same set of writes. Each of these writes is logged. The log includes the hash that was written to the TPM, an event type and a description of the event. TPMs initialise their PCRs in a known state, so by emulating the behaviour of the TPM and replaying the entries in the log, you can verify that the TPM reached the state it's in by performing the actions recorded in the log. TPMs can be configured to encrypt data or keys in such a way that they will only decrypt or use them if the PCRs are set to specific values. With grub measuring the boot process, this means that you can encrypt a secret in such a way that the TPM will only decrypt it when the values match. An example of using this for boot security is TPMTOTP (https://github.com/mjg59/tpmtotp) which provides a direct mechanism for a user to verify that their boot process (including firmware) has not been tampered with. Remote attestation is a mechanism by which a remote machine can request (but not compel) another machine to provide evidence of the PCR state. The TPM provides a signed bundle of information including the PCR values and the event log, and the remote machine verifies that the signature corresponds to the key it expected to see. The remote machine can then examine the log, ensure that it matches the PCR values and analyse each individual log entry to ensure that it matches an expected value. In a data centre, this means that it can then flag whether a machine is running in an expected state or not - if someone has tampered with the boot process, the information will not match the policy. Doing this well involves knowing what the expected values are to begin with. Some of these values come from the firmware, and so we can't do much about them without the assistance of the system vendors. But these values don't tend to change over the course of a system's lifetime (unless you update the firmware), so it's much easier to do something about that. Other components *do* change over time as we update grub or the kernel, and it's immensely helpful to be able to identify these ahead of time. In CoreOS we've started shipping bundles of the expected PCR values with each release. I'd like to start exploring how to do the same in Fedora. Things are much easier in CoreOS since we don't ship individual OS components, and so the values are very much tied to OS releases - in Fedora they'd mostly be associated with individual packages. It'd be easy to bundle the values in with the packages themselves, but that's harder for admins to extract. A central location to publish this kind of metadata would be ideal. With what we now know about malicious actors targeting the system boot chain (even down to the firmware), this kind of TPM-based work is a vital part of helping keep our users secure. The remote attestation features also make it easier for admins to keep their data centres secure. We have an opportunity here to make Fedora the first general-purpose operating system to provide resistance to this kind of attack out of the box, and I think it's worth taking it. There's still some additional work to do, such as making it possible to assign local policy to which things get logged into which PCR. But I think we're in a great position to start developing well-integrated features that take advantage of this kind of hardware-level security. -- Matthew Garrett | mjg59@xxxxxxxxxxxxx -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx http://lists.fedoraproject.org/admin/lists/devel@xxxxxxxxxxxxxxxxxxxxxxx
