1

A simple way of automatically decrypting system drive at boot time:

clevis luks bind -d /dev/yourdrive tpm2 '{"pcr_ids":"4,5"}'

systemctl enable clevis-luks-askpass.path

When I booted another OS on the same machine, tpm2_pcrread listed mostly identical PCR values, except for 4 and 5. I understand that PCR 4 is a hash of the MBR and partitioning data, and PCR 5 is generated by the code in MBR. Besides, it's an EFI system. If an attacker makes a copy of the entire disk, can he generate the PCR 4 value by hashing the stolen MBR and partitioning data?

Update: If you google for enabling automatic unlocking of encrypted system volumes in Linux, you might find the above simple commands, but they aren't very secure. Based on CBHacking's answer, an attacker could read out or calculate the PCR values, which are used as encryption key of the disk encryption key. Some other, much longer guides explain how to upload your key to the TPM and use TPM sealing to protect it.

0

While I don't know the specific details for LUKS, the way TPMs are usually used for disk encryption is that a key (typically used to decrypt or "unwrap" the master encryption key) is stored in the TPM and "sealed" to specific values in specific PCRs. TPMs let you specify a policy for when to unseal a key; in this case, the policy would be "don't unseal the key unless PCRs 0-5 (or even more) are <their current values>".

This means that the attacker can't simply figure out the expected hashes and then use them to decrypt the drive, because those values are useless by themselves. They need to actually be in the PCRs for the unseal policy to be satisfied. You can't write directly to the PCRs, or reset them (except as the system boots), either. You'd have to figure out the right input to take the PCR from whatever value it has to the one it expects. Assuming the hash algorithm used by the PCRs is strong against collisions and preimages, this is infeasible.

Of course, if you can control what gets hashed ("extended") into the PCRs from boot, then you can make them arrive at any value you want. Preventing this is the duty of the CRTM (Core Root of Trust Measurement), which is generated by hardware-enforced code (provided by the chipset vendor) that runs before anything else. This code measures the firmware (BIOS) of the system before executing it, extending all the code to be executed into PCR0 and the firmware configuration data into PCR1. The firmware itself measures the subsequent code-to-be-executed and extends that into suitable PCRs.

Because the CRTM is made using code that's integral to the chipset - possibly even integral to the CPU - an attacker can't replace it with something that lies about the measurement of the firmware. Because the firmware is measured, the attacker can't replace it with something that lies about the measurements of the boot metadata, etc. which means that the boot metadata can't be replaced with something that lies about the measurements of the bootloader, etc. The CRTM is - as its name implies - the root of a chain of trust; as long as the CRTM is what you expect (or the TPM's unseal function requires, per policy), you can be sure that each subsequent set of PCRs were extended legitimately and their values reflect the true hashes of the code that ran. Thus, if they are also the expected values, you can be sure that the boot code was not modified, such as to boot an alternative OS that will unseal the disk encryption key and then let you read the disk without having a valid login password.

As such, not only can an attacker not use the computed PCR4 value to decrypt the disk correctly, they can't even put it into PCR4 - not without having the wrong values in the lower PCRs - because the code that would extend the required sequence of values into PCR4 would itself have been extended into some lower PCR, and that code isn't normally there so the lower PCR would have an unexpected value and the TPM wouldn't unseal the key.


Mind, you do probably want to seal the key using more than just two PCRs. If you don't use PCR0, then modified firmware wouldn't be caught, and if your motherboard allows arbitrary (or buggy) firmware to be installed then the whole chain of trust would be broken. If you use PCR0 but not PCR2, then extensions to the firmware won't be checked, and those might override what data gets extended into PCR4 and PCR5.

For an example of which PCRs to use, consider BitLocker's default PCR policy when using the TPM on computers with native UEFI (search for "validation profile for native UEFI"): it checks PCRs 0 (CRTM, firmware code), 2 (firmware extension code), 4 (boot manager code from the UEFI system partition), and 11 (which Microsoft's boot code uses to store BitLocker access controls). This list is customizable; for example, if you want to prevent unsealing the key if the user changes any UEFI/BIOS settings at all, you might also check PCRs 1 and 3.

2
  • Thanks for the info. While starting up the copy of the system in a Virtual Machine, they can put any values into the PCR registers. How easy is it to find PCR 4 given the copy of all disks? – Gravitysensation Mar 24 at 11:32
  • It's probably easy to figure out what the value of PCR4 would be, given the disks. This doesn't actually help an attacker in any way, though. You can create a virtual TPM for a VM, or use some of the OS-controlled PCRs on a real one and - through the virtualization - remap them to 0-9 or whatever. You still can't set PCR4 (or any other) on an actual TPM. Since your encryption key would be sealed by an actual TPM (not a virtual one) with a policy depending on the actual PCR4 (and others, but none of them virtualized or remapped for a VM), the attacker couldn't unseal the key anyhow. – CBHacking Mar 25 at 8:36

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.