Right way to use the TPM for full disk encryption

Question

I'm currently setting up a BitLocker equivalent using a TPM and LUKS. I've got the basics right and I'm able to measure the boot process and seal the FDE key using the TPM.

Every time the sensitive parts (firmware, bootloader, kernel) are updated the following command is used to seal the encryption key to the new system state :

tpm_sealdata -p 0 -p 1 ... -p 11 -p 13 -i <keyfile> -o <sealed keyfile>

When the system boots the following is used to unseal the key which is then passed on to LUKS to mount the encrypted volume :

tpm_unsealdata -i <sealed keyfile> -o <temporary keyfile stored in RAM>

This works and has the desired behavior - if the boot process has been tampered with (let's say adding init=/bin/sh to the kernel command line to bypass a root password) the TPM refuses to unseal the key and the system is thus safe.

However, I've got a few questions :

First, the TPM requires the SRK password every time a sealing/unsealing operation is performed. I'd like to avoid that and have it behave just like BitLocker which is transparent and doesn't prompt for anything. I've thought about using a default SRK password but apparently it's insecure, yet the answers fail to tell whether an attacker knowing that password can unseal a key if the PCRs don't match the state they were in when the key was sealed.

Another question is which way should I use to seal the keys - my way involves tpm_sealdata/tpm_unsealdata but another project tpm-luks uses tpm-nvread/tpm-nvwrite instead. I'd like to know the differences and whether one way is more secure than the other.

Answer 1

First of all: NO system is 100% safe, but using TPM is better than no TPM at all. TPM Chip is just some kind of encrypted storage, that resides on the motherboard of computers that support Trusted Platform Environment, and have BIOSes prepared to handle it.

PCR are registers with specific functions that are handled through the TPM_Extend operation. They cannot be "set", only extended(new_hash = [old_hash||new_measurement]).

TPM have Static Root of Trust for Measurements (SRTM) and Dynamic Root of Trust for Measurements (DRTM), and the combination of both creates the Secure Environment. This guy explains very well how this is done. It is a chain of trust between fixed and dynamic items.

Back to PCRs, they are platform independent registers, and the most common ones are:

PCR 0 to 3 for the BIOS, ROMS...
PCR 4 - MBR information and stage1
PCR 8 - bootloader information stage2 part1
PCR 9 - bootloader information stage2 part2
PCR 12 - all commandline arguments from menu.lst and those entered in the shell
PCR 13 - all files checked via the checkfile-routine
PCR 14 - all files which are actually loaded (e.g., Linux kernel, initramfs, modules...)
PCR 15 to 23 are not used 

Intel based notebooks commonly use the first 16 registers, but it could be extended to other softwares/uses.

While writing information (sealing) to TPM, you can add a Storage Root Key (SRK) that is somehow a "Management key" and is used to add other keys to this storage. As per manpages, using -z will set TSS_WELL_KNOWN_SECRET (20 zero bytes).

-z, --well-known
    Use TSS_WELL_KNOWN_SECRET (20 zero bytes) as the SRK password. 
    You will not be prompted for the SRK password with this option. 

So, having this SRK set to the default secret (TSS_WELL_KNOWN_SECRET) will not be enough to attack someone since TPM can only be unsealed if the current PCRs match those used to seal the data. Also, some of the PCR handling happen at boot time(BIOS) and it's very hard to manipulate those and thus create "fake" PCRs. BIOS is the only place where PCRs are seen as zeros before the rest of the process takes place.

The only FEASABLE attack is the one who aims to MITM communications between BIOS and PCR to zeroes PCR without restarting the machine to put the system on "trusted" state. This attack is known as TPM Reset Attack.

The Attack

So, given everything we've seen above, it should be very difficult to fake a trusted boot process, as long as the BIOS takes the first few measurements. The critical assumption here is that the PCRs cannot be easily reset without restarting the whole platform that the TPM resides on. If an attacker is capable of monitoring the measurements sent to the PCRs by the BIOS (with, for instance a logic analyzer, see this paper), and capable of zeroing out the PCRs without restarting the machine, then she could take a platform in any configuration and put it into a 'trusted' state. So, the difficult part is getting the TPM to reset without bringing down the whole machine. It is worth mentioning that we've also looked at interposing memory and other such things to change the running system after its been measured, but due to the speed of the busses that memory and hard drives sit on, this is a tricky endeavor. Attacking a slower bus is much easier.

TPMs typically reside on the Low Pin Count (LPC) bus. The LPC bus supports a ground driven reset line. This means that when this particular line on the bus is driven to ground every device on this bus is supposed to reset. Other devices attached to this bus include the BIOS, and legacy keyboard and mouse controllers. The video below demonstrates that driving this line is indeed possible, and fairly easy to do. Please note that in the video, we are accessing the computer in question via a remote ssh session. This is because the keyboard and mouse controller get reset when we drive the reset pin, but the network card does not. More details of this attack (and others!) can be seen in my senior honors thesis: A Security Assessment of Trusted Platform Modules, Dartmouth College Computer Science Technical Report TR2007-597.

Note that this is an oversimplified version of ALL THINGS that involve Trusted Computing. Please take a look at the Architecture Document of TPMv2 to get more information about all operations that happens between bios, hardware and software during the setup of a trusted environment.

tl;dr: Using the default Storage Root Key(20 zero bytes) is not enough to create an insecure system.

Related stuff:

• LUKS, TPM and full disk encryption without password.
• Full disk encryption with LUKS (including /boot) without TPM.

Answer 2

I think that this tutorial can be very useful.

The core idea is the following:

Using Linux TPM2 & TSS2 Software, you can create a secret with tpm2_create binding this secret to the PCR state. Then, when you need to encrypt/decrypt the disk you can retrieve the secret key with the tpm2_unseal command providing this as input for the decryption/encryption purpose.