6

I spent several days trying to figure out how to securely decrypt a hard drive on remote location using TPM2.0 in Linux. I'm no security expert and this is my first battle with TPM2.0. I learned a lot, but I still have questions. Could someone help me with those:

  • At the current time TrustedGRUB2 does not support TPM2.0, only TPM1.2. I couldn't find other projects with support for TPM2.0. Are there any?
  • Can TPM2.0 stop the boot process?

The problem I'm trying to solve is such that:

  • I have an encrypted / partition with /boot unencrypted
  • The computer will be on someone else premises, so it should not be possible to steal a hard drive and read the data
  • The boot process should be unattended -- the machine should not decrypt the drive and boot itself if something changed -- BIOS configuration, initram file (/boot is unencrypted, so fiddling with initram is possible)

I thought about this solution:

  • LUKS key will be the value of PCR0
  • PCR0 value should change, if someone will change something in BIOS, like reset it (if someone will steal the whole PC, not only the disk), enable USB boot.
  • The PCR0 value used to decrypt the disk should be secure as much as secure is the OS running on it -- only way to read this unchanged PCR0 without changing the BIOS is to gain access to the OS, right?

I think that I achieved a level on which I can ask a legitimate question about this issue, but I cannot myself assess further the implications or holes in this.

schroeder
  • 123,438
  • 55
  • 284
  • 319
Kamil
  • 171
  • 1
  • 5

1 Answers1

2

On a Linux system, you can use clevis to "bind" a LUKS volume to the TPM2, and decrypt the root filesystem automatically in your case. For example:

clevis luks bind -d /dev/sda3 tpm2 '{"pcr_ids":"0"}'

or

clevis luks bind -d /dev/sda3 tpm2 '{"pcr_ids":"0,1"}'

You will need it to already be encrypted and have a passphrase, which the command above will prompt you for. You can leave the passphrase as a backup or remove it afterwards.

I'm not sure about using the PCR0 value itself as the key, since in my limited experience that value is pretty easy to access. I don't believe that is how "sealing" data against a PCR works but I don't know the exact relationship between the PCR value and the sealed value.

I have used clevis to bind a LUKS volume to the TPM2, and automatic decryption on boot-up when it's the root filesystem. I encrypted the device during install, and had success binding it manually and in a kickstart script. The clevis tool added TPM2 support early 2018 and made it out of the RHEL "beta" repo when RHEL 7.6 was released. I only got the automatic decryption to work on the full /dev/sd* volume, not any logical volumes. I found this link very helpful: https://blog.dowhile0.org/2017/10/18/automatic-luks-volumes-unlocking-using-a-tpm2-chip/

I believe PCR0 is supposed to change if the BIOS firmware is modified and PCR1 changes even if certain settings are modified. I don't know the best PCR(s) to pick; my information is from a single system and the PC Client specification defining PCR usage at https://trustedcomputinggroup.org/wp-content/uploads/PC-ClientSpecific_Platform_Profile_for_TPM_2p0_Systems_v51.pdf (Section 2.3.4, Table 1).

Jaime
  • 21
  • 2
  • 1
    See https://security.stackexchange.com/a/44350/165253 for how SRTM (which allows unsealing only if no tampering was detected) works. As for it being easy to access, that's absolutely true and is unavoidable. If you have physical access, you can easily read the values of the LPC bus. The only purpose is to prevent modified _firmware_ and configurations from lying about their hash, not prevent decryption from someone who has complete physical access to your computer. – forest Feb 19 '19 at 02:53
  • **You don't want to use the PCR values directly as a key.** You want to seal some blob with the TPM that you can use as the key. Sealing involves _all_ PCRs and the blob can only be unsealed if every PCR is good. – forest Feb 20 '19 at 05:14
  • 1
    You do not have to seal against _all_ PCRs, and you do not even have to know what "good" is. You can specify individual PCRs if you wish, and you won't be able to unseal when those values are different. – Jaime Feb 20 '19 at 23:40
  • You're right. By "good", I meant "known good to you". The TPM itself has no concept of good. – forest Feb 21 '19 at 01:07