LUKS using clevis TPM2.0

Question

Hi I'm trying to encrypt a secondary data disk. I want this disk to be decrypted during boot of my machine. I currently have RAID setup, with an LVM volume on top which is already encrypted with LUKS.

I have executed a command like this: sudo clevis luks bind -d /dev/RaidVG/LVMVol tpm2 '{"pcr_ids":"15", "pcr_bank":"sha256"}'

Now as I understand it, I'm binding adding a keyslot to my LUKS header that is bound to my TPM2.0 module on PCR bank 15. Now that seems to work, what I don't understand though is what happens when I execute 'tpm2_pcrread'. It says that my pcr 'value' is still 0:

$ sudo tpm2_pcrread
sha1:
sha256:
  0 : 0xREDACTED
  1 : 0xREDACTED
  2 : 0xREDACTED
  3 : 0xREDACTED
  4 : 0xREDACTED
  5 : 0xREDACTED
  6 : 0xREDACTED
  7 : 0xREDACTED
  8 : 0x0000000000000000000000000000000000000000000000000000000000000000
  9 : 0x0000000000000000000000000000000000000000000000000000000000000000
  10: 0x0000000000000000000000000000000000000000000000000000000000000000
  11: 0x0000000000000000000000000000000000000000000000000000000000000000
  12: 0x0000000000000000000000000000000000000000000000000000000000000000
  13: 0x0000000000000000000000000000000000000000000000000000000000000000
  14: 0x0000000000000000000000000000000000000000000000000000000000000000
  15: 0x0000000000000000000000000000000000000000000000000000000000000000
  16: 0x0000000000000000000000000000000000000000000000000000000000000000
  17: 0xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF
  18: 0xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF
  19: 0xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF
  20: 0xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF
  21: 0xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF
  22: 0xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF
  23: 0x0000000000000000000000000000000000000000000000000000000000000000
sha384:
sha512:

What exactly do these PCR values mean? I cannot find an answer to this online. Shouldn't these values change after I do anything with my PCR bank?

One other perculiar thing is that when I encrypt a simple hello world file following this tutorial (https://www.fit-pc.com/wiki/index.php?title=Linux:_Full_Disk_Encryption), I get the exact same encrypted output "eyJhbGciOiJkaXIiLCJjbGV2aXMiOnsicGluIjoidHBtMiIsInRwbTIiOnsiaGFzaCI6InNoYTI". Now, they don't display the entire output that they get, just the first line. Is this because I have some default keys set up? Or is this some kind of common header? My TPM module is virtualized so that may also be an issue.

I hope someone could explain a bit more about how this actually works and how to securely set my encryption scheme up.

Answer 1

Now as I understand it, I'm binding adding a keyslot to my LUKS header that is bound to my TPM2.0 module on PCR bank 15. Now that seems to work, what I don't understand though is what happens when I execute 'tpm2_pcrread'. It says that my pcr 'value' is still 0:

Binding data to a PCR is not supposed to change the PCR – it uses the TPM to encrypt data in a way that uses the current PCR value. Generally, this means you should choose a PCR whose value has a useful meaning (e.g. Windows BitLocker uses PCR 7 which keeps the current Secure Boot state). Using a PCR that's all-zeros still binds the encrypted data (i.e. the LUKS keyslot) to the TPM itself, but doesn't stop anyone from booting a live CD and just asking the TPM to unseal the data for them.

What exactly do these PCR values mean? I cannot find an answer to this online.

Each PCR corresponds to a hash chain produced by events in the TPM Event Log. Every time an event is logged, a corresponding PCR is updated (or "extended", since the update process is pcr = hash(pcr + new_event), very similar to how Git commits work).

The base events are documented in TCG specifications; tpm2_eventlog can show what's logged during the current boot. For example, PCR 4 will contain the exact hashes of every .efi executable that was launched during the boot process. (Practically all default PCRs are related to the boot process somehow.) Most events are logged by the firmware, but some by the bootloader; the OS could, but usually doesn't.

In other words, checking whether a PCR contains an expected value is just a shortcut for verifying that the Event Log contains the expected events in the expected order.

For example, BitLocker seals a keyslot (or a "protector") using PCR7 or PCR4 to ensure that automatic unlocking is only possible when the actual Windows installation is being booted (i.e. a system that will honor user account security and not a live CD).

Shouldn't these values change after I do anything with my PCR bank?

No; the values do not change simply from being read.

The "seal" operation asks the TPM to encrypt the provided data and to attach the policy "only decrypt if PCR 15 matches this value". It doesn't alter the PCR itself. The sealed data is returned back to the OS (to be stored in a file, or in a LUKS token, etc).

One other perculiar thing is that when I encrypt a simple hello world file following this tutorial (https://www.fit-pc.com/wiki/index.php?title=Linux:_Full_Disk_Encryption), I get the exact same encrypted output "eyJhbGciOiJkaXIiLCJjbGV2aXMiOnsicGluIjoidHBtMiIsInRwbTIiOnsiaGFzaCI6InNoYTI".

That's some Base64-encoded data. Decode it and you'll see that it contains a fixed header:

$ echo eyJhbGciOiJkaXIiLCJjbGV2aXMiOnsicGluIjoidHBtMiIsInRwbTIiOnsiaGFzaCI6InNoYTI | base64 -d
{"alg":"dir","clevis":{"pin":"tpm2","tpm2":{"hash":"sha2