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!
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.
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.
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.
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
Actually, we are currently not advising user to seal the Luks key, although this should work normally. If you press enter in step 8 of the instructions it is the same like hitting n and thus should not seal the Luks keys. In this case you would have been safe
So you are good to go if you are proceeding the way you are doing it know. Of course, sealing the Luks key has security advantages, but it has also the possibility to make the data inaccessible (as happened to you ). This is why we do not recommend it for the general user and we are guessing that the experienced users will figure out the usage of the feature themselves…
Thanks for your message anyway because it shows that we might change our BIOS build to exclude this question altogether to make it easier for most users.
Thanks for your reply and I see now where I went wrong the first time. I had misread the instructions on step 8 as confirm with Y not confirm with defaults
I tried the procedure again and it worked perfectly.
I have a back up of the OS now so I will play around with getting luks key encryption working. If I do get it to work I will reply to the forum in case other users are trying to achieve a similar result.
Agree, there are risks with the feature both in setup and in ongoing use hence for the general user not advisable.
Thanks for the follow up and the Nitropad has been great!
It surely is possible, but much harder than general screen capture. Indeed it would be necessary to use a camera, good lights etc. as the Heads BIOS can not just extended with a screen capture binary One might be able to use a qemu build of Heads, but I do not know how good this is working for the whole Nitrokey stuff.
So in general, this would be quite time consuming, I am not sure, if this time should not be invested in making the process more easy instead
Thanks in advance!
). This is why we do not recommend it for the general user and we are guessing that the experienced users will figure out the usage of the feature themselves…
One might be able to use a qemu build of Heads, but I do not know how good this is working for the whole Nitrokey stuff.