yubikey-full-disk-encryption VS sbupdate

Would using this be possible? https://github.com/agherzan/yubikey-full-disk-encryption/tree/master/src

> Hibernate is less interesting, and apparently unsupported using secure boot anyway.

That's not the case. I have a similar setup to yours (/ on ext4 with separate swap, on LVM on LUKS, separate /efi) and my box hibernates just fine with secure boot and auto-unlock via TPM.

The difference with your setup is I don't use grub, but have the UEFI load a signed unified kernel image directly. Since this works so well, I never had a reason to mess around with yet another moving piece (grub or other bootloader).

As another commenter said, I haven't attempted to mess around with the MOK. I just replaced all the secure boot keys with my own, and I've also signed MS's Windows key (but not the 3rd party one) for my dual-boot needs.

---

For specifics: This is an up-to-date Arch Linux install, running on an HP EliteBook 840 G8 (11th gen intel). I know Debian may have older components than arch, but this setup has been working for more than a year now.

IIRC, the most significant change was brought by systemd 251 which started supporting auto-unlocking LUKS with the TPM. Before that, on an older computer with the same general setup, hibernation worked well, too. I just needed to input the unlock password (which I was too lazy to do, so I just used my yubikey - see https://github.com/agherzan/yubikey-full-disk-encryption).

Does yubikey-full-disk-encryption provide anything systemd 253 doesn't now?

Do you mean something like this: https://github.com/agherzan/yubikey-full-disk-encryption

Full disk encryption is rarely as portable as simply encrypting the files you need. When I ran a “homemade” NAS, I had everything LUKS encrypted. I used a Yubikey to unlock the encrypted data.

A few days ago I akquiriere a Yubikey and I'm currently trying to set up 2FA with the Yubikey and a password to unlock the LUKS container. Since I am running Arch I came across the yubikey-full-disk-encryption package and tested it in an Arch VM. So far it worked really well. The only issue I am having is that compared to my old setup I need to have /boot unencrypted because it seems GRUB itself cannot deal with the 2FA setup and ykfde if /boot is encrypted. Previously I had most of /boot inside the LUKS volume with only the /efi part unencrypted (this is used when telling grub where the efi-directory is - see the previous guide for the full details please) and the GRUB_ENABLE_CRYPTODISK=y option set in the GRUB config.

I don't know about the hanging, I use yubikey-full-disk-encryption which uses challenge-response (1FA or 2FA) which you can set up how many attempts to use the YubiKey before it falls back to the passphrase.

Related: https://github.com/agherzan/yubikey-full-disk-encryption

https://github.com/cornelinux/yubikey-luks or https://github.com/agherzan/yubikey-full-disk-encryption with yubikey 5 will get you going. It is a bit expensive to get two keys (regular and backup), but these can be also used to secure most of the online accounts.

I use sbupdate [0] to build the unified kernel image and to sign it with my keys. It's run by a hook in the arch's package manager whenever the kernel, the initrd or the firmware images change. I saw the other day that systemd recently got an utility to do this, but I've never looked into that. sbupdate has been working fine for me for several years now.

It doesn't store a new key in the uefi, it signs the new image with the key that uefi already knows about.

See [1] for the whole setup and [2] for the signing part specifically.

[0] https://github.com/andreyv/sbupdate

[1] https://wiki.archlinux.org/title/Unified_Extensible_Firmware...

[2] https://wiki.archlinux.org/title/Unified_Extensible_Firmware...

Here is where different systems will fork. On Arch there is a pacakge sbupdate where it automatically generate unified kernel images using pacman hooks and I use systemd-boot (which must be signed by your keys) to load it.

I really think it's easy enough. You create your keys, put them into /etc/efi-keys, enroll them into your UEFI by whatever method you prefer, install sbupdate-git and you're done... You need to run sbupdate manually once after install, everything else works automatically through hooks.

Ah, sbupdate does that very well; it embeds the kernel image, initramfs and the UEFI boot image into a unified signed image. I presume this signed image should then be further encrypted?

Check out https://wiki.archlinux.org/index.php/Unified_Extensible_Firmware_Interface/Secure_Boot and https://github.com/andreyv/sbupdate

For the last part, check out https://github.com/andreyv/sbupdate . Linked also from arch wiki, so not some completely random solution. Its for creating unified kernel images, including the initramfs, microcode and so on. This package is then signed for secureboot, and can be loaded using EFISTUB for example. This prevents attacks against initramfs or some other things on /boot, if unencrypted. I haven't come around to test it myself, but I think its a neat solution, and with proper secure boot (and password protected firmware), a reasonable protection against evil maid attacks.

I am using secure boot with custom keys, a fully encrypted root btrfs partition with /boot on it, with swap also encrypted with hibernation support. The only non-encrypted partition is the EFI partition with boot images signed with https://github.com/andreyv/sbupdate (look up "direct booting").