Nitropad X230/Qubes - Lost luks passphrase

Hi All,

When booting my Nitropad X230 into Qubes the bootup sequence is failing when
I enter in the disk encryption passphrase to unlock the disk where Qubes is installed.

The passphrase itself is correct however it appears I have managed to clear all
passphrases associated with that drive or the TPM is not unsealing it and pass it on.

The issue occured after I upgraded the Qubes OS and resigned bootfiles and resealed
TPM keys.

So far I have tried to reseal the luks key in the TPM and add a new key to the drive
using the heads recovery screen. All have had no success as at eachpoint the cryptsetup
function cannot find a valid passphrase to unlock the encryption key.

I dont recall setting the disk recovery key and as such have considered that lost.

Has anyone come across this issue before and are there any suggested ways to resolve?

My next step is to perform a factory reset and reinstall qubes however if I can avoid doing that it would be great!

Thanks!
Anthony

Firstly, my sincere condolences… I’m working on a similar project that may require the same (resign, reseal), and I wanted to jump into this conversation to keep up with the responses that (inevitable) will start rolling in from experienced users…

Unfortunately, I don’t have much to contribute to the conversation (as of yet). In the meanwhile, and maybe a dumb question, did you change the passphrase of your LUKS drive using the gnome disk utility? I remember seeing a filed bug that may erase all slots if you use the graphical approach. This bug was from 2019 though (so depending on how long sits been since you’ve upgraded, etc). https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=928893

Anyways, as I say; more experienced users will be jumping in soon I bet… in the meanwhile; would love to hear any epiphanies you may have had since posting.

Warmly,
KO

2 Likes

Hi @Kcortman!
Thank you for the suggestion! It seems though this is fixed already, according to the linked bug report and the current package version in buster.

Details copied from the pages

----------------------------------------------------------------------
Package libblockdev2

  • buster (stable) (libs): Library for manipulating block devices
    2.20-7+deb10u1: amd64 arm64 armel armhf i386 mips mips64el mipsel ppc64el s390x
  • bullseye (testing) (libs): Library for manipulating block devices
    2.23-2: amd64 arm64 armel armhf i386 mips64el mipsel ppc64el s390x
  • sid (unstable) (libs): Library for manipulating block devices
    2.23-2: alpha amd64 arm64 armel armhf hppa i386 m68k mips64el mipsel ppc64 ppc64el riscv64 s390x sh4 sparc64 x32

----------------------------------------------------------------------

Bug details:

Found in version libblockdev/2.20-7
Fixed in versions libblockdev/2.22-1, libblockdev/2.20-7+deb10u1

@nitroalex @jan: Could you point to the relevant documentation regarding the main topic?

Hi Kcortman,

Many thanks for your reply and suggestion. I had not changed the Luks key using the gnome utility so I don’t think that was the cause.

I think you are in the right path though that there is a bug in the system that lead me to this state so to help other users I will share what got me to this state in the first place.

My X230 is running Qubes, it is a new machine so I was in the process of updating it and configuring it for my needs when I hit the problem.

After each iteration of upgrade or change I was able to resign the boot files as per the Nitropad user guide however when I tried to add my new luks key to the TPM and reseal it the procedure would fail.

This operation is described on the nitropad help page for what to do after a system reset. Specifically at the point where you should select a default boot option. The example quoted is for an Ubuntu system however in theory it should be the same for a Qubes system however in practice it is not.

I tried to use the recovery shell in heads to add the key manually and reseal it using me kexec-add-key and kexex-seal-key functions and through that messing about I managed to kill all the keys on the /dev/sda2 partition.

Since the post I have rebuilt the machine and it’s operational again however I am at the same cross road where I can not select a default operating system to boot on and seal my luks key on the TPM.

My research suggests that the issue could be due to a bug in the kexec-save-key function, users of heads have reported similar issues. There is a suggested fix which I am going to try and I will report back if it works.

It would be good to get the user documentation updated and the script patched if it is a bug as others will no doubt hit it.

I will post links to the issues when I am back at my pc.

Thanks!!

Anthony

2 Likes

A link to the issue would be marvelous indeed :slight_smile: Thanks in advance!

Hi Alex,

Sorry for the late reply, here is the background to what I believe caused the keys to be nuked originally.

After a few system updates I followed the procedure here to resign the boot files and also set the new default Qubes version to boot off. Link to procedure is given below.

https://www.nitrokey.com/documentation/nitropad-system-update

The point where I got stuck initially was at step 8. I selected yes to all three questions as instructed however as the procedure results in the luks key being sealed in the TPM I was presented with questions on lvm segment and luks disk which at the time I wasnt clear on what I was being asked to input.

Its possible that at this point I made incorrect selections and nuked the luks password which was game over and i had to reinstall.

During the re-install I did some further digging on the Heads wiki and found the following procedure relating to the fresh install of Heads and Qubes on an X230, see link:

In this document is it states to select no at the second question which is do you want to reseal the luks disk keys in the TPM. I have been doing this ever since my re-install and it is working ok.

I am not sure whether or not this is correct as I have seen others mention it is possible to reseal the luks key at this point on a heads/qubes os build.

I would welcome your thoughts on whether I should keep going as is or whether I should try to find a procedure that works.

Note I came across this thread below on the heads wiki which indicates there could be a bug in the kexec-seal-key function of heads. I was going to play around with it but now that my machine is working again I don’t want to break it again :slight_smile:

1 Like