TPM Issue - Failed to unseal TPM

Hardware Librem (Other)
1

Hello,

After eagerly congratulating myself for successfully installing the Pureboot bios and configuring TPM on my Librem 13v2 to work with my librem key I noticed that my last OS update had a new kernel…

… I appear to have mistakenly opted to store the LUKS password in TPM and possibly misconfigured something else and can no longer boot properly.

When I select the kernel I wish to boot, I am prompted with:
New value of PCR[6]: long sequence of numbers and letters
Enter unlock password (blank to abort):

No matter what password I input here (I know what password I set and it doesn’t work) I get the message “Error Decryption failure from TPM_Unseal” followed by output of 8 PCR key slots then “Unable to unseal disk encryption key”

If I abort I get
Aborting unseal disk encryption key
!!! Failed to unseal the TPM LUKS disk key
New value of PCR[4]: long sequence of numbers and letters
Do you wish to boot and use the disk recovery key? [Y/n]

If I’ve opted to boot the recovery grub option then hitting Y and entering the LUKS passphrase works fine.
If I’ve not opted to boot this then hit Y then the librem key is checked and found to not have the LUKS passphrase (of course)
If I select n, then I get a recovery shell.

Does anyone have any suggestions on how to reverse the damage? I’m able to access PureOS via the recovery option but would like to return to my short-lived state of everything working.

2

It sounds like you can boot OK with some work, so you aren’t locked out.

Considering this, if I were in your situation, I would just start from scratch (reset everything but the OS/your data).

3

I’ve tried resetting the TPM and reflashing the bios but this config seems to persist. I’m not sure how to reset it.

4

Same issue here and I have not been able to fix it. I can boot (unsecurly) as long as the Librem key is not plugged in. Hopefully someone can help.

5

I have been pointed to community/Heads Matrix room for help with this sort of thing: https://matrix.to/#/!BSPqgzeiCeaSBayTLM:talk.puri.sm

I am no expert on these matters, but I have been doing a lot of flashing, formatting, reinstalling, re-configuring, breaking (intentionally and unintentionally), fixing, etc. with Linux and my Librem. I am trying to learn a lot about these things, and I learn best by doing. This includes seemingly breaking PureBoot and recovering from a similar place to yours. I did what I write below, and it worked for me:

Since you can still boot using your normal LUKS passphrase, it should be safe to flash the normal core boot bios, which would strip out all of the heads bits. Information on that is in this discussion.

Once you have a “normal” boot working (power on, Purism logo, LUKS prompt, booted to system login or desktop), reset your Librem Key, and start the process over again: move your private keys to the Librem Key and your public key to a flash drive, flash PureBoot back onto the machine, and configure heads.

2 Likes
6

First, thank you so much for beta testing Heads. It’s exactly this kind of problem that we are trying to fix before we release it to a wider audience. The upstream Heads build had that LUKS-TPM storage option and I never liked it because I figured at some point someone would enable it and get locked out of their system after they reset their TPM. Current versions of PureBoot have removed that particular prompt.

@dc3p 's guidance should work if you are willing to start from scratch. Another option to consider is erasing all of the kexec* files in /boot. This is where Heads stores its persistent state outside of anything stored in the TPM. I suspect it is appending a bad (or empty) LUKS password to your kernel config when you boot. I think by erasing the files in boot that start with kexec* and then when you boot again, going straight into the “reset your TPM” option, you will hopefully be able to reset things.

Then I would suggest grabbing our latest pre-built PureBoot firmware from here directly https://source.puri.sm/coreboot/releases or using our utility at https://source.puri.sm/coreboot/utility which will attempt to detect exactly which firmware to use. We are continuing to add UI and workflow improvements to our PureBoot firmware specifically to address problems like this.

3 Likes
7

@dc3p @Kyle_Rankin Thanks kindly, a combination of both of your suggested steps has worked and I’m back to where I wanted to be. The key was flashing with standard coreboot which just simplified things a bit, I still had to play about a little with cryptsetup and crypttab to get the non-recovery kernel to boot. I then reflashed the newer pureboot and all is well!

2 Likes