Lock LUKS with Nitrokey FIDO U2F - which dracut method?

Does anyone foresee any obstacles in implementing a U2F security key lock on Qubes OS LUKS?

Qubes R4.2 has Fedora 38 Dom0 with GRUB (sudo bootctl). I have successfully changed from GRUB to Systemd boot on F38.
Moving from GRUB to systemd boot - Fedora Discussion

Systemd has cryptenroll.

Therefore, it should be possible to change Qubes Dom0 F38 from GRUB to Systemd boot and then enroll a Nitrokey FIDO in systemd cryptenroll.

This is probably as close to trusted boot / U2F secured power up as a Qubes computer could get without HEADS BIOS. This way, at least as long as you keep your security key, no one can turn on your drive without you.

dom0 use fc37 in 4.2, also you dont need to change grub to systemd-boot in 4.2 for that.


  • dom0 updated to Fedora 37 (#6982)

He didn’t say you are wrong. He said that you do not need to change grub in Qubes 4.2.

In 4.2, dom0 is fedora 37 and have the systemd-cryptenroll package.
(therefore, you don’t need to change grub to unlock LUKS with a security key).

1 Like

So it doesn’t matter whether GRUB or systemd boots since it is dracut that is directing LUKS to use systemd cryptenroll after initialization with either boot method?

Ok. Misunderstanding. Thanks.

do I ever offend you or someone here?

dracut dont know unless you tell crypttab, add modules, and regenerate initramfs.

[Contextual vignette. Of course the crypto wizards that run the Death Star dont ask questions on forums and if you are not space forces you are devoid of all value and easily disposed of by the local trash collectors–obviously–like every street person knows, local trash collectors are all-powerful. And that means if you are not NSA certified then your future is foreclosed and you are not allowed to have anything good in your life ever again.]

But, the crypttab method did not work for me when I followed the Fedora guide. And no one could answer my qestions about it at the time either. Something is missing there. Maybe the module method might work. Does anyone know more about the slot method?

Is there anyone who has got LUKS locked with a security key on Qubes? Or is this uncharted territory? There are probably several HEADS lockers but I am asking about LUKS lock.

you are writing as though all these options run together when they are separate methods. What have you demonstrated to work? Try it yourself maybe.

What do you think about this, for example: #58 (cryptab missing info)
https:// FIDO and Fedora - Yubikey C Bio - #58 by system76g6 - Fedora Discussion

But then the new Qubes release they are (we) waiting for is here. Missing package in dom0 (systemd-cryptenroll)

Its Stated that in these link

it was in Fedora 32 which mean 4.1, there was no systemd-cryptenroll.

and i was explicit in 4.2 it use Fedora 37 which systemd-cryptenroll is there. so no need to change anything or even installing anything, just change how your qubes system boot up (means configure crypttab and dracut)

also dont focus on OP statement, when he say it was Fedora 36 and your Statement about Fedora 38 Dom0, it was wrong, it doesnt make sense talking about Fedora Template to boot dom0, in qubes 4.2: dom0 use Fedora 37 as the base.

here’s i give you an SS if it was exist.

I dont have any fido2 so i can’t try, but if you willing to give Yubikey, ill write a guide for you and others, like i did with detached header.

1 Like

“crypt cru” - crypttab options are particular

The syntax
“Ad hoc name” UUID none luks,fido2-device=auto
does not work …
Know what I need to do in emergency shell?

So I am testing this out on F38 apart from Qubes to see if I can get it working there first. There is variation about the syntax for crypttab on the information available online.

have you add dracut modules, enroll fido luks, edit crypttab, and regenerate initramfs?

what step you have done ?

Did you take a look at post #58 from the Fedora forum link above (guyrutenberg)? Those are the steps I followed.

sudo dracut -f regenerates the initramfs

To proceed, I will have to work from emergency shell.

How do I find the correct drive name? Then I edit crypttab?

FYI. Update on question still working on solution if anyone cares to provide more info —>

Ok then ill give you a hint, since you really want to learn something in here, back then when i was researching about detached header i was same like you, i read tons of article but the difference is i never asked someone, I strongly want you to read dracut, crypttab and initramfs manual at least several times, looking how the system boot, which service is started, after service 1 service 2 and so on, what is initramfs, how the initramfs works, what files contains in the initramfs, what the modules used to decrypt, have you read the modules script at least once (I bet never right?).

before you go deep into the system, have you ever do a simple test about how you manually decrypt the drive inside dom0? as example this is the command for regular luks encryption :
cryptsetup luksOpen /dev/sda1 luks-root then you need to enter the password, have you ever do that but instead of using password you have to use your fido2, I bet never ?

For the start try doing that first, enroll the disk with fido2 then decrypt. if you still confuse try this

sudo systemd-cryptenroll --fido2-device=auto /dev/sdX
sudo /usr/lib/systemd/systemd-cryptsetup attach mytest /dev/sdX - fido2-device=auto

A good point was made on the Nitro forum. There is no way to attach usb to Dom0. I was still working on F38 where that is possible. Do you have a solution developed for that? I bet never : )

as I said in the earlier i dont have fido2, how can i develop it? but the process is same as the detached header, also you are funny, instead of providing the report of what i told you,

you just asking for a debate, and it was clearly again to see you are take his statement about dom0 has no usb what makes initial enrolling of the keys quit a challange.
then, I will answer with ‘quoting’ statement

good luck, sure i’ve think i may offend you somewhere :rofl:

It is difficult to understand you because your English is broken. The gist of what you seemed to be saying earlier was read up on everything related to the question. That’s not very helpful, since why are there forums if the answer is to read everything that might be relevant. The point of forums is asking a community of people with experience and knowledge who can cut straight to the solution or get close to it anyway.

I think you dodged the point that Dom0 cannot get usb input. I think ion might be on the right track here:

The Fedora guides referenced above do not mention anything about correctly aligning the parameters to match. If that is what is missing, it is a crucial step because editing crypttab misalligned will cause the system to drop to emergency shell.

The thing is you wont try my suggestion not even do a search what im talking about, take a look at the earlier of our conversation here

whats your response, what other response, and what your response to this other response?

From here i can understand that other can read my english and you dont.

This is wrong statement as default dom0 accept usb, the sys-usb is making the one that cant accept, as example in the grub this parameter usbcore.authorized_default.

and 2nd, you need udev thing, do research.

Right track about crypttab?

Here my statement about 2 years ago

also this one about usb thing

at that time the usbcore grub parameter is not present, so you need to change the value to 1 at this time.

Have a clean qubes 4.2, tick dont configure anything in initial setup, and run this

You are a ‘Very smartest guy I have seen’ if still make a reply or any statement without providing this output.

Yes I agree systemd boot is not required for systemd cryptenroll to function because it starts [at initramfs] after GRUB boot and regardless of boot method.

No.What do you mean by “at default?” All pci are permitted access to Dom0? If you insert a usb, can you interact with it via Dom0 terminal? This is not my statement anyway. It was made by another person on the Nitro forum I have linked to above. It makes sense to me, considering the security model of the OS that PCI access is controlled. I will have to experiment. I’m still focusing my efforts implementing on F38 before moving on and I have limited time.

There is a lot of complexity here. I am going to spend a few hours reasearching and trying things out soon. I thought someone else might have something to add to the discussion. I began this project with the Fedora guide which makes it sound simple when is not.

You’ve written some interesting guides. The only problem is the language barrier at times. For instance, your last few sentences can be read opposite ways. Are you asking for me to provide the output of those commands. They look like they set a configuration, not like they provide diagnosic information.

Not sure what you are asking here.

Get back to this soon.

“udev thing”

Maybe he means symbolic links. Can anyone elaborate?