Unable to successfully put LUKS key into TPM

[vanceb]

Having a problem mentioned in #566 . I have managed to install Heads and Qubes. I can boot into Qubes using the "Disk Recovery Password". The problem comes when I try to set a default boot option and store the disk recovery key in the TPM.

Using the menu to set the default appears to go well. On reboot, and selecting "Default boot" all goes well until I get asked for the "unlock password". Once entered I get the following:

Error PCR mismatch from TPM_Unseal
PCR-00: <20 hex bytes>
PCR-01: <20 hex bytes>
...
PCR-07 <20 hex bytes>
Unable to unseal disk encryption key

I understand from this that the PCRs have changed since they were "Sealed" into the TPM. I have tried to reset the PCR values by doing:

seal-totp

<gets a qrcode>

unseal-totp

Error PCR mismatch from TPM_Unseal
unable to unseal totp secret

Also when booting I notice that I get notification of PCR changes, specifically PCR 7 and PCR 5. I am not sure if this is related to the "PCR mismatch"???

I think I am missing something, but not sure where to go from here...

[vanceb]

I have tried to reset this a number of times without success. I have tried to use the Heads boot menus and follow the prompts, and the process seems fine, but whenn I come to reboot and use the default boot option it fails:

As I can't copy/paste from the Heads machine this will be a summary:

*** Found verified kexec boot params
gpg: Signature made <date>
gpg:                     Using RSA Key <key sig>
gpg: Good signature from <email address>
*** Found verified kexec boot params
*** Scanning for unsigned boot options
*** Checking verified boot hash file
*** Verified boot hashes
65323284: <hex digits>
/tmp/counter-65323284: OK
*** Checking verified default boot hash file
*** Verified default boot hashes
*** Executing default boot for Qubes, with Xen hypervisor:
New value of PCR[6]: <hex digits>
Enter unlock password (blank to abort)
Error PCR mismatch from TPM_Unseal
PCR-00: <20 hex bytes>
PCR-01: <20 hex bytes>
...
PCR-04: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
...
PCR-07 <20 hex bytes>
Unable to unseal disk encryption key

The thing that worries me in the above is that PCR[6] has changed just before I enter my unlock password. From reading http://osresearch.net/Keys.html PCR[6] is the LUKS header. I can see no reason why this should change at all during boot or any other time, unless I change the passwords? Secondly, why is PCR[4] All zeros?

Any suggestions?

[tlaurion]

PCR[4] is extended when getting to the recovery console to invalidate measurements.

My past experience with disk unlock key not being unsealed correctly was caused by usb devices drivers being loaded though insmod which calls insmod script(not busybox insmod directly), which modifies measurements.

Sealing and unsealing requires to have same measurements, and loading usb modules will interfere with those measurements.

If going straight to boot options and setting a new boot default, it should work as designed.

[tlaurion]

PCR[6] is modified by measuring the LUKS header.

[vanceb]

Why does the LUKS header change just before I enter the unlock password? I think it is this value changing that causes a failure to unseal.

As far as I am aware I am not causing the loading of additional USB modules. I did think it could have been the Yubikey being inserted to sign the updated /boot after selecting a new default, but I don't notice a PCR change when I insert theYubikey. After the failure to unseal the TPM I drop myself into the recovery shell to list the USB modules:

/boot # lsmod
Module         Size       Used by     Not tainted
xhci_pci        16384    -
xhci_hcd       98304    -
ehci_pci        16384    -
ehci_hcd       45056    -

Plugging in the Yubikey and running lsmod again shows no difference.

[vanceb]

FYI I am using the Master branch not the release:
commit 20d79f5

I have tried "going straight to boot options and setting new boot default" a couple of times. Here is a transcript of my last attempt:

1. Clean boot from power down
2. Presented with menu screen showing correct totp value
3. Choose third option Settings-->
4. From settings menu choose first option Other Boot Options
5. From other boot options menu choose Show OS boot menu
   • Drops to terminal view before showing Select your boot option menu with multiple boot options
6. Chooses first boot option Qubes,_with_Xen_hypervisor_[/xen-4.8.5-7.fc25.gz]
7. Choose second option Make Qubes, with Xen hypervisor the default
   • Drops into terminal

Saving a default will modify the disk.  Proceed? (y/n):  y
Do you want to reseal a disk key into the TPM [yN]: y
    Reading all physical volumes.  This may take a while
Encrypted LVM group? (was ''): <leaves blank>
/dev/sda2: UUID="<uuid>"
/dev/sda1: UUID="<uuid>"
Encrypted devices? (was '/dev/sda2/'): /dev/sda2
Running kexec-save-key with params: -s -p /boot /dev/sda2
Enter disk recovery key: <enters recovery key>
New disk unlock password for booting: <enters password>
Repeat unlock code: <repeats password>
++++++ /dev/sda2: Removing old key slot
++++++ /dev/sda2: Adding key
New value of PCR[6]: <hex digits>
Please confirm that your GPG card is inserted [Y/n]: y
...
< gpg card details listed >
...
Please unlock the card
PIN: <enters PIN>
gpg: Signature made....
...
+++ Found verified kexec boot params
+++ Saved defaults to device
+++ Rebooting to start the new default boot option

8. Computer reboots
9. Presented with boot menu with correct totp
10. Select first option Default boot

Drops to shell

** Found verified kexec boot params
gpg: Signature made <date>
gpg:                     Using RSA Key <key sig>
gpg: Good signature from <email address>
*** Found verified kexec boot params
*** Scanning for unsigned boot options
*** Checking verified boot hash file
*** Verified boot hashes
65323284: <hex digits>
/tmp/counter-65323284: OK
*** Checking verified default boot hash file
*** Verified default boot hashes
*** Executing default boot for Qubes, with Xen hypervisor:
New value of PCR[6]: <hex digits>
Enter unlock password (blank to abort)
Error PCR mismatch from TPM_Unseal
PCR-00: <20 hex bytes>
PCR-01: <20 hex bytes>
...
PCR-04: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
...
PCR-07 <20 hex bytes>
Unable to unseal disk encryption key

Any more ideas?

[vanceb]

Hmmm, may not be PCR[6] after all. Looking back at the value of PCR[6] just after the LUKS headers were changed when setting the default, matched the value just before the request for unlock password when trying to default boot. But if it hasn't changed from what the TPM expects why is it notified that it has changed?

Should the TPM be resealed with the new PCRs (specifically PCR[6]) after the default boot option has been set? I answered for the TPM to reseal the disk key, but does this also update the PCRs stored at the same time? I can see no log line stating that this has happened as part of changing the default boot option?

[vanceb]

Just thinking through this a bit more...

At stage 2 of above, I am presented with a valid TOTP value. This must mean that the PCRs are OK at this point as the TPM must unseal the TOTP secret.

During stage 7 (Making Qubes the default) it says that PCR[6] has changed. I am guessing that this means that PCR[6] was previously at a default value and has just been populated with a value related to the LUKS headers which have just been read. The value of PCR[6] at this point is the same as the value shown when it fails to unseal the TPM at stage 10.

If my thinking is correct then at stage 2 the value of PCR[6] is at a default value, maybe 0, and the TPM unlocks OK with this value. When I try to boot the default at stage 10 above, the LUKS headers are read and PCR[6] is populated with the value based on the LUKS headers (which is different from the default value which worked at stage 2), and as the PCRs are now different it fails to unseal the disk key.

If I am correct then we somehow need to read the LUKS headers so we populate PCR[6] with the correct value before sealing the disk key into the TPM???

Is this an issue with code in the master branch, or am I barking up the wrong tree?

[tlaurion]

I'll see code differences with my QubesOS certified branch. Haven't tested master for a little while now and they have diverted.

[Tonux599]

Had a lot of problems with this issue as well. After messing around a bit the only thing that worked for me was specifying CONFIG_BOOTSCRIPT=/bin/generic-init in the board config and following the instructions on the wiki.

Is it possible something in the gui init could be causing this issue?

[vanceb]

As a work-around I can set the default boot if I choose not to put the LUKS key into the TPM. I am then prompted for the LUKS key durring OS boot instead of the TPM disk key in Heads boot. I suspect I am then missing a check of the LUKS headers by the TPM before boot. So I would be vulnerable to LUKS header modification.

I may try CONFIG_BOOTSCRIPT=/bin/generic_init when I get a chance.

[tlaurion]

I'll look into this next week. @kylerankin: has some changes changed the behavior, not taking into consideration the disk unlock boot path?

…

On August 24, 2019 1:40:39 AM UTC, Tonux599 ***@***.***> wrote: Had a lot of problems with this issue as well. After messing around a bit the only thing that worked for me was specifying CONFIG_BOOTSCRIPT=/bin/generic-init and following the instructions on the wiki. Is it possible something in the gui init could be causing this issue? -- You are receiving this because you commented. Reply to this email directly or view it on GitHub: #603 (comment)

-- Sent from /e/ Mail

[kylerankin]

@tlaurion Given I don't use that feature I'm not really sure, however it's certainly possible that PCR measurements get updated and changed after the initial boot verification and retrieving a LUKS secret later on when the user tells Heads to boot.

I can only imagine that the UI will introduce more changes in the future instead of less, as we all continue to add ease-of-use features that launch scripts behind the scenes, so perhaps the LUKS secret should be cached somewhere safely in /tmp beforehand?

[tlaurion]

@vanceb can you retry resealing TPM and HOTP through menus instead of the console?

Going in console modifies PCR 4 which won't match normal boot.

Are you using gui-init in board config?

[vanceb]

I upgraded to the latest Master Build 5d91d6a

Resealing TOTP works fine through the GUI menu. The problem I was having was getting the LUKS key into the TPM. I have reverted back to using Ubuntu rather than Qubes, and I don't think it will allow me to pass the disk encryption key through from the TPM (I am sure I read it somewhere). But I have tried to set a new default and include the disk key by using the menu. This fails before asking me for the disk key, without really providing an error message and puts me back at the boot menu. If I don't try to include the disk key it asks me for the GPG key and sets the default as it should.

I am not sure whether this is because I am now using Ubuntu?

[EDmitry]

I am having the same issue (I think). Here is what I do:

1. Load recovery shell, run kexec-unseal-key. It fails due to my previous unsuccessful attempts to seal the key, but it does show me the current PCR registers.
2. Seal new keys using kexec-save-key. The PCR6 correctly changes before sealing the key.
3. Run kexec-unseal-key again. It will obviously fail, because PCR4 isn't all zeros, but it does show me the value of all the PCR registers so far, all other registers should be what I'd expect at boot.
4. Reboot and try to load the default option. Asks me for the key passphrase, PCR6 changes to the correct previous value, but fails with "PCR mismatch" again.

As far as I can see, the state of PCR registers is exactly the same that it was at a sealing stage, just with PCR4 being all zeros, which is correct. Something else is probably going on, I don't think the value of registers is wrong. Is there any way to debug this further or get more information?

PS. When sealing I end kexec-save-key at a point when it asks to insert a GPG key. I assume it doesn't matter, because the sealing has already happened before that and /boot/kexec-devices.txt doesn't actually change if I am continuously working with the same LUKS partition.