6

I've been trying to find information about how systemd-cryptenroll performs full-drive encryption with LUKS. I understand that the LUKS header allows multiple keyslots, and that using the TPM as a decryption method is actually using the TPM to unlock one of the keyslots that can then be used to retrieve the LUKS volume key, which is actually used for encryption/decryption. However, what I am unclear on is whether the PCR values themselves are used for the TPM keyslot (since each PCR value can be 512 bits and multiple values can be hashed together) or if there is a secret sealed into the TPM device itself that is provided when the correct PCR values are present.

In a simplified example, if encryption were bound to PCRs 1+7 and the values were:

PCR1: 12345 PCR7: 67890

would the keyslot be unsealed using some combination of those values (ex. adding them to get 80235) or by retrieving the key from the TPM device when those values are present in the registers?

Thanks!

Improve this question

3 Answers 3

Reset to default
7

The TPM is not modified when you enroll a LUKS slot.

What’s stored in the slot is a copy of the LUKS root key for that drive, and policy of when the unencrypted root key may be given out by the TPM. This is encrypted with the TPM’s root key, which itself is “impossible” to extract from the TPM and is unique to that TPM.

So the only thing that can decrypt the drive’s root key in that LUKS slot is that specific TPM and it will only hand it out if the PCRs match the values in the policy.

The policy can’t be tampered with, because that too would require the TPMs root key.

To directly answer your question: While the policy (including PCR values) is encrypted along with the drives’s key to prevent tampering, the policy is often not considered secret. It is an instruction to the TPM of when to give out the key, and not part of the key itself. So it would be useless without the TPMs own root key.

Improve this answer
0
6

Yes, it will, for that keyslot. So setting up TPM-based unlocking as the only active LUKS keyslot would probably be a mistake in most situations. Having a backup method like a long and unpredictable passphrase in another keyslot allows restoring access if the TPM chip or the motherboard it's attached to fails or you need to move the disk to a new system for any other reason.

Check the permissions of the /sys/class/tpm/tpm*/pcr-* files. Notice that they are world-readable. This is because PCRs are designed to be used for verification of the system state: they are not supposed to be secrets themselves.

So, using PCR values directly for unlocking LUKS keyslots would be a fundamental crypto implementation error.

With TPM-based unlocking, using your example, the cryptsetup finds a list of PCRs and a blob of encrypted data in the TPM keyslot. It hands the blob back to TPM and says: "this was sealed using PCRs 1 and 7, unseal it for me please." The TPM does it using the combination of the PCR values and the secret key which will never leave the TPM (but will be re-randomized if you reinitialize the TPM).

If the PCRs are correct the result will be a valid LUKS keyslot key, ready for unlocking the volume key. If the PCRs have different values, this operation will just produce useless pseudo-random data, and the attempt to unlock the volume key using it will fail.

Improve this answer
3
  • The PCRs are not used in combination with the secret key. (The policy language is not limited to just the PCRs, either; it could e.g. check a password, and even has 'or' conditionals.) Instead, the TPM first decrypts the data+policy internally using only its secret key – holding the decrypted result in its own RAM, which is assumed as tamper-proof as its persistent secret-key storage – and if the PCRs have incorrect values (or more generally, the policy evaluation fails) then it refuses to return the result. Commented Sep 14 at 15:15
  • @grawity Could you explain a bit more? I still haven't fully understood what a "policy" is. I actually asked a question about that on a separate stack exchange since I thought it was more general than being *nix-specific Commented Sep 15 at 2:47
  • 1
    @Hari: A policy is literally a set of conditions – in this case the conditions would be such as "PolicyPCR(pcrs=[1,7] values=[12345,67890])" requiring given PCRs to match given values, that can be included with the sealed data. Commented Sep 15 at 4:26
4

would the keyslot be unsealed using some combination of those values (ex. adding them to get 80235) or by retrieving the key from the TPM device when those values are present in the registers?

Mostly the latter. These values themselves do not participate in actual encryption; instead they are combined into a policy hash that is sealed together with the provided data ("data" being the LUKS key).

The sealing result is not1 usually stored within the TPM but merely encrypted using the TPM's internal key and then returned to the OS. If you are using systemd-cryptenroll, then the sealed blob gets stored in the LUKS2 header as a "token" (you can inspect those using cryptsetup).

During unlock, cryptsetup will load the blob back into the TPM's RAM, where it is decrypted and the TPM verifies the policy (which may involve comparing PCRs, verifying passwords/PINs, or a few other conditions). If the policy succeeds then the TPM returns the unsealed data (i.e. the LUKS keyslot) to the OS; if the policy fails then the TPM discards the decryption result and returns an error code.

1 (The TPM has some general-purpose storage and some earlier LUKS-TPM solutions did have an option to store the LUKS blob within the TPM's NVRAM, but that is tedious. For example, the NVRAM has no file names, only numeric indices, and it is hard to know which NV indices are "in use" by anything – whereas the sealing approach stores the sealed blob right next to the LUKS header where it is useful, and does not consume any TPM resources at all.)

Improve this answer
1
  • 2
    Also NVRAM has a limited rewrite count likely to be much lower than the rating of your SSD so writing to the TPM NVRAM is generally to be avoided if possible. Commented Sep 14 at 18:16

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.