Does Clevis bind integrate with TPM Ownership

[waparker117]

stack: UEFI, Secure Boot, TPM 2.0, LUKS

Hi, I have set up a LUKS volume to automatically be decrypted using the following command: clevis luks bind -d /dev/sda4 tpm2 '{"pcr_ids":"0,1,2,3,4,5,6,7"}'

This method provides security working in conjunction with secure boot in that it ensures an attacker cannot disable secure boot/alter the system and still unlock the luks volume. What I'm wondering is whether there is a way to integrate the concept of TPM ownership with clevis to add a further layer of security. My understanding is that, as of now, someone with access to the tpm and an encrypted drive would be able to decrypt the contents of the drive, however if there were a tpm owner then an attacker would be locked out even with the tpm in their possession.

Thank you.

[waparker117]

I dug through the clevis source a bit, and found the line that seems to be preventing TPM Ownership compatibility:

line 157 in clevis-encrypt-tpm2: 4|5) tpm2_createprimary -Q -C "$auth" -g "$hash" -G "$key" -c "$TMP"/primary.context || fail=$?;;

tpm2_createprimary is called (twice in clevis-encrypt-tpm2 and clevis-decrypt-tpm2) with the option -C 'o', which signifies that owner authorization should be used. However, the option -P needs to be used to pass in the actual owner password.

From tpm2_createprimary man page:

-P, --hierarchy-auth=AUTH: The authorization value for the hierarchy specified with -C.

Being able to actually pass in ownership authorization may be a good improvement.

[savchenko]

Not quite following. Assuming the machine is physically in your possession:

1. TPM_ForceClear() via UEFI interface
2. Provision Clevis

someone with access to the tpm and an encrypted drive would be able to decrypt the contents of the drive

Some of the options:

1. Pre-boot ATA password
2. Pre-boot UEFI password
3. sedutil (or one of its forks, e.g. https://github.com/ChubbyAnt/sedutil)
4. Encrypt only one of the partitions to attest that device wasn't tampered with. For example, you can setup Clevis on swap and keep manual password for your root partition. If swap is decrypted automatically upon boot, you can have a degree of certainty that machine is clean.

[F-i-f]

So Clevis will not work if the TPM2 has an owner password set? At least that's what I'm seeing using clevis-18-14.fc37.x86_64 (Fedora 37). With tpm2 owner password set:

clevis luks bind /dev/vda3 sss [complex-policy]
Enter existing LUKS password: 
The advertisement contains the following signing keys:

[REMOVED]

Do you wish to trust these keys? [ynYN] y
WARNING:esys:src/tss2-esys/api/Esys_CreatePrimary.c:400:Esys_CreatePrimary_Finish() Received TPM Error 
ERROR:esys:src/tss2-esys/api/Esys_CreatePrimary.c:135:Esys_CreatePrimary() Esys Finish ErrorCode (0x000009a2) 
Error: authorization failure without DA implications (associated with session number 1)

Caused by:
    0: authorization failure without DA implications (associated with session number 1)
    1: Response code value: 0x9a2
Invalid input!
Usage: jose jwe fmt -i JWE [-I CT] [-o JWE] [-O CT] [-c]

Converts a JWE between serialization formats

  -i JSON --input=JSON     Parse JWE from JSON
  -i FILE --input=FILE     Read JWE from FILE
  -i -    --input=-        Read JWE from standard input

  -I FILE --detached=FILE  Read decoded ciphertext from FILE
  -I -    --detached=-     Read decoded ciphertext from standard input

  -o JSON --output=JSON    Parse JWE from JSON
  -o FILE --output=FILE    Read JWE from FILE
  -o -    --output=-       Read JWE from standard input
                           Default: "-"

  -O JSON --detach=JSON    Parse JWE from JSON
  -O FILE --detach=FILE    Read JWE from FILE
  -O -    --detach=-       Read JWE from standard input

  -c      --compact        Output JWE using compact serialization

Failed to import token from file.
Error saving metadata to LUKS2 header in device /dev/vda3
Unable to update metadata; operation cancelled
Error adding new binding to /dev/vda3

After clearing the owner key with:

tpm2_changeauth -c owner -p file:/dev/shm/key2

clevis is successful:

clevis luks bind -d /dev/vda3 sss [complex-policy]
Enter existing LUKS password: 
The advertisement contains the following signing keys:

[REMOVED]

Do you wish to trust these keys? [ynYN] y