Trying to enable TPM2 decryption gives me "Failed to opensealed key (TPM_Load: 0x1df)" error

English Install/Boot/Login
1

I’ve been following the wiki articles SDB:Encrypted root file system#Unattended boot with TPM 2.0 and partially SDB:LUKS2, TPM2 and FIDO2 to try to enable TPM2 automatic decryption on my system. I’ve already managed to convert my LVM encrypted partition from LUKS1 to LUKS2, here is the partition scheme:

NAME                                   MAJ:MIN RM   SIZE RO TYPE  MOUNTPOINTS
nvme0n1                                259:0    0 476.9G  0 disk  
├─nvme0n1p1                            259:1    0   260M  0 part  /boot/efi
└─nvme0n1p2                            259:2    0 476.7G  0 part  
  └─cr_nvme-eui.0025388801b7548c-part2 254:0    0 476.7G  0 crypt 
    ├─system-root                      254:1    0 163.8G  0 lvm   /root
    │                                                             /var
    │                                                             /usr/local
    │                                                             /boot/grub2/x86_64-efi
    │                                                             /srv
    │                                                             /boot/grub2/i386-pc
    │                                                             /opt
    │                                                             /.snapshots
    │                                                             /
    ├─system-swap                      254:2    0  15.3G  0 lvm   [SWAP]
    └─system-home                      254:3    0 297.6G  0 lvm   /home

I have followed basically any step in the sections linked above, but this is what happens when I boot the system:

error: ../../grub-core/tpm2/module.c:796: Failed to load sealed key (TPM2 Load: 0x1df). 
error: ../../grub-core/disk/cryptodisk.c:1191:no key protector provided a usable key for hd0.gpt2 (05e539f6-eff4-4828-bccb-53ba9cef865f). 
Enter passphrase for hd0.gpt2 (05e539f6-eff4-4828-bccb-53ba9cef865f):

What could be the reason?

2

After spending a lots of time on time, dig from fde-tools to pcr-oracle, I found the problem is quite simple😂, the PCR value isn’t the same across creating and decrypting.

The most simple way is to edit the /sys/config/fde-tools file, and change FDE_SEAL_PCR_LIST=0 (to use only PCR 0 for policy authentication), then regenerate the key again to make it work.

BUT applying this method will cause less secure, due to only one PCR is verified (instead of 5), making more easily to “crack” the password… Haven’t figure out what the optimus value is🤕.

1 Like
3

Unfortunately it does not seem to fix the issue to me. I’ve also tried wiping and regenerating the key afterwards with the relevant fdectl commands but the result is the same

5

Strange, try to git clone and build GitHub - okirch/pcr-oracle: Predict TPM PCR values for future boot , then run test-tpm2key.sh, check if it can pass.

And you can also run a command sudo pcr-oracle --key-format tpm2.0 --input /boot/efi/EFI/opensuse/sealed.tpm --output /tmp/unsealed.tpm unseal-secret to unseal the data from userspace and check whether error occurs.

After that, you may try the following to determine which PCR register is “fixed” during the whole system process:

  1. fdectl regenerate-key if you changed fde or firmware before, the PCR register is calculated by events, and each GRUB command is an event that can change the PCR register, so if command changes, the PCR changes.
  2. Then booted into openSUSE, try to compare the result sudo pcr-oracle --from eventlog --before --stop-event grub-file=grub.cfg predict 0-9 and systemd-analyze pcrs, check whether the PCR register 0 are the same.

If both succeed, you might have a different situation than mine🤯.

6

Also I found a little error with pcr-oracle, view the log of fdectl regenerate-key and check if there’s an error shows “unable to umount”, if so, you might need to edit the pcr-oracle’s source, by adding sync(); sleep(1); before the https://github.com/okirch/pcr-oracle/blob/ef36b09ba4af8973ba05da74444f48257cee2d57/src/runtime.c#L111 .

But this error may not be crucial, just for a reference, good luck!

7

Then booted into openSUSE, try to compare the result sudo pcr-oracle --from eventlog --before --stop-event grub-file=grub.cfg predict 0-9 and systemd-analyze pcrs, check whether the PCR register 0 are the same.

PCRs 0,1,2,3,5,6,7 match.
PCRs 8 and 9 are all zeroes on pcr-oracle’s output (but not on systemd-analyze’s output)
PCR4 does not match.

Same thing if I reboot the system.

Strange, try to git clone and build GitHub - okirch/pcr-oracle: Predict TPM PCR values for future boot , then run test-tpm2key.sh, check if it can pass.

I’ve tried to run the test multiple times and it does not give any error.

And you can also run a command sudo pcr-oracle --key-format tpm2.0 --input /boot/efi/EFI/opensuse/sealed.tpm --output /tmp/unsealed.tpm unseal-secret to unseal the data from userspace and check whether error occurs.

I get errors from this command:

WARNING:esys:src/tss2-esys/api/Esys_VerifySignature.c:302:Esys_VerifySignature_Finish() Received TPM Error 
ERROR:esys:src/tss2-esys/api/Esys_VerifySignature.c:103:Esys_VerifySignature() Esys Finish ErrorCode (0x000002db) 
Error: Esys_VerifySignature failed: tpm:parameter(2):the signature is not valid

Also I found a little error with pcr-oracle, view the log of fdectl regenerate-key and check if there’s an error shows “unable to umount”

I have this error, too. Thank you for pointing it out. I thought I was the only one.
Sometimes I circumvented this by simply calling the command twice.

I may patch the code as a last resort, for now I’d prefer not to.

I posted the question on the openSUSE subreddit and managed to get unattended decryption with either FDE_SEAL_PCR_LIST=0 and FDE_SEAL_PCR_LIST=0,2,4,7,9. You may want to check it out and see if we are now in the same situation.

Thank you very much for your help!

8

That is correct. PCR 8 and 9 used to measure kernel and initrd, including command line, and at the time grub2 needs to unlock boot they are not yet touched.

shim measures verified binaries into PCR 4, so as long as grub uses shim protocol to verify anything (including kernel itself) it will change PCR value. Again, at the time grub needs to unlock boot it does not have kernel yet.

1 Like
9

Congrats you have found the solution in reddit :wink: Seems like you have encountered another problem, my tpm2_getcap show no 0x810… values.

And indeed, the wiki of openSUSE shall be updated, especially most of the tools (fdectl, or even grub2) is modified by openSUSE and thus no other distro have the responsibility to maintain it.

1 Like