Help with FIDO2 FDE Setup with Systemdboot+LUKS Encryption (BTRFS, No LVM)

All,

I’d like some help fixing/setting up FDE on Tumbleweed. I’m slowly trying to achieve the goal of using OS’s that are not necessarily super hardened (i.e., not Qubes) but to encrypt everything at baseline. My goal now is to have the following:

  1. Full disk encryption of a BTRFS partition with LUKS using the new systemd-boot available on tumbleweed, encrypted swap optional (I have 32gb of RAM and I’m testing this primarily on a gaming rig. I believe using ZRAM via systemd-zram-service is feasible for now).
  2. I’d like to use FIDO2 as the primary way to unlock the FDE, with password as fallback. The yubikey I have is a bit old (2020), but I have tested it and it doesn’t seem like any of the problems I encountered were due to the yubikey itself.
  3. I’d like to use ReaR to do full backup with OS recovery ISO. My understanding is that ReaR does not officially support openSUSE, but I was encouraged by one of the members of the project to go ahead and try it out, so we’ll see where it goes.

My latest progress is that I have tried two configurations of the initial FDE setup, following the instructions in this article: Quickstart in Full Disk Encryption with TPM and YaST2 - openSUSE News

  1. Encrypted Root+Encrypted swap: this setup did not work. More specifically, I would boot, the yubikey would flash after selecting tumbleweed at the systemd boot options screen, and then I would get kicked out to an emergency shell every time. SOMETIMES, depending on if I was lucky, I would exit back out of the rescue shell, the yubikey would flash again, and then it would proceed to the gnome login screen. However other times it would give me timeout errors, and just hang indefinitely. I believe it may be related to something along the lines of this Support unlocking multiple LUKS devices with FIDO2 · Issue #23889 · systemd/systemd · GitHub. I see journalctl logs that say that I didn’t respond to the prompt quick enough, which isn’t the case (after the initial failures I basically just kept tapping the key throughout the boot process). However I think, as explained in the systemd issue, that the boot process isn’t letting the yubikey prompt again for some reason, and this only happens (inconsistently) after things get halted and restarted due to dropping to the emergency shell. Errors below, and if anyone can reproduce this and confirm the issue that would be awesome.

  2. Then I tried no encrypted swap, and I believe this confirms my suspicions about the bug above. It works perfectly fine to log in with only one encrypted partition! The yubikey flashes, I touch it, and then it proceeds right to gnome after a short wait. HOWEVER, I noticed that once FIDO2 is set up there is no normal configuration where you can get the password fallback to work. I tried both having the yubikey plugged in and ignoring the prompt, which is maybe admittedly an odd scenario (it just fails to rescue shell), but I also tried booting without the yubikey at all, and it just hangs indefinitely with no password prompt. This seems like some sort of misconfiguration to me, but I can’t figure out how to configure /etc/crypttab to make this work. Token-timeout seems to have no effect on this behavior on my system…

Any help would be appreciated!

Thanks,

Chris

Sounds like FIDO2 fallback to password · Issue #19872 · systemd/systemd · GitHub

Well, you already concluded that it is upstream issue, so work with upstream to solve it.

Well, you agreeing that I might have identified the root cause of the two issues is helpful to me. I am not confident when it comes to working with things related to the boot process.

I’ll create a bug report upstream for the multiple partition unlock issue, and I’ll add a response to the open issue about password fallback.

However, I would appreciate it if someone other than myself could reproduce these issues so I know its not an issue with my hardware. No, I have no reason to think that specifically, but again I’m not confident with my understanding of the boot process.

Actually, going to wait and see how the ongoing Plymouth and downstream Systemd open issues interact with this.

https://bugzilla.opensuse.org/show_bug.cgi?id=1233669
https://bugzilla.opensuse.org/show_bug.cgi?id=1233373

Maybe unrelated, but 1233532 – plymouth-start.service: Failed to start Show Plymouth Boot Screen.

-Chris

@arvidjaar it turns out that the password fallback issue is related to 1233669 – Boot screen not showing password prompt and the related conversation you had with other users here New opensuse update won’t let me get pass through decrypting swap partition - #53 by arvidjaar. When I remove splash=silent, quietand add plymouth.enable=0, I see the correct behavior: with the FIDO2 key removed, the system waits for a short timeout then prompts for the disk password. With the FIDO2 key in, the system waits for interaction with the key.

Additionally, from reading the forum post it seems as though this may affect unlocking multiple partitions as well, but I’m going to wait to decide that until I can test with the update that fixes plymouth for the other issues.

Finally, directing me back upstream as the very first solution was not very helpful. I did guess at an upstream issue, but I also asked for help reproducing on Tumbleweed and by posting here it is implied that I was looking to connect with other users regarding this issue on Tumbleweed.

I have confirmed that the Plymouth issues did affect the fallback to password, at least for a configuration using FIDO2 with one encrypted partition. That issue is now resolved with the recent Plymouth rollback in Tumbleweed.

However, for the case of an encrypted swap partition, I am not getting prompted to unlock the swap and the system crashes to emergency mode . More details are provided in my bug report here: 1234010 – Unable to unlock multiple encrypted partitions with FIDO2 Key, Systemdboot+LUKS

This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.