20

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.

  • 1
    @RickyDemer platform configuration registers. They contain hashes of components related to the boot process (the firmware hashes the MBR and puts the result in a PCR, in turn the bootloader hashes the kernel and puts the result in the next PCR, etc) and "sealing" data means the TPM encrypts data and remembers the state of each PCR and will only unseal (decrypt) that data if the PCRs are in the exact state as when that data was sealed. You may want to check out en.wikipedia.org/wiki/Trusted_Platform_Module. – André Borie May 27 '16 at 11:47
  • But the same way using default srk password is unsafe, also BitLocker is without a password. - blogs.mcafee.com/business/security-connected/… - Even BitLocker best practices advice you to use TPM + pin or TPM + usb dongle + PIN - technet.microsoft.com/en-us/library/dd875532%28WS.10%29.aspx - So, what is the point of having something that is "as transparent as BitLocker" but with the same failures of using default SRK password on Trusted Plataform Modules? – user28177 Jun 1 '16 at 17:27
  • @nwildner yes I know Bitlocker is not secure in that mode, however I'm willing to accept the risk of hardware-based attacks for this particular case. What I'm asking though is whether knowledge of the SRK allows an attacker to unseal data even though the PCRs no longer match. – André Borie Jun 3 '16 at 12:14
  • 1
    Will not be possible since, if PCRs no longer match the ones used to seal, even knowing the default SRK password an forged acces shall be impossible. 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 - cs.dartmouth.edu/~pkilab/sparks - AFAIK, this is the only attack that could put your compromissed system on a trusted state, and all systems should be vulnerable(not only Linux using the default SRK pass) – user28177 Jun 3 '16 at 14:17
  • 1
    Posted as an answer, and added some background for things you already discussed with others on the comments ;) Glad it helped you – user28177 Jun 3 '16 at 17:20
11
+100

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:

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.