this post was submitted on 20 Nov 2024
12 points (100.0% liked)

Arch Linux

121 readers
1 users here now

Discussion community about the Arch Linux distro.

Wiki : https://wiki.archlinux.org/

Site : https://archlinux.org/

Packages : https://archlinux.org/packages/

GitLab : https://gitlab.archlinux.org/archlinux

Downloads : https://archlinux.org/download/

founded 9 months ago
MODERATORS
 

While I'm trying to get Encrypted /boot and a detached LUKS header on USB to work,
I had a couple of questions come to mind:

~~1. Does the backup USB key need to be updated?~~
~~2. If so, then how would someone keep all backups up to date?~~

I probably asked a dumb question but if anyone can help guide me through the steps I'd really appreciate you!๐Ÿค—๐ŸŒป

you are viewing a single comment's thread
view the rest of the comments
[โ€“] timewarp 3 points 3 days ago (1 children)

What do you mean need to be updated? You store the LUKS header in an IMG file on the USB drive. I ran this setup for many years. It is kind of difficult to mess up, but you should keep at least one offline backup. Last thing you want is to lose your ability to decrypt your data.

[โ€“] [email protected] 2 points 3 days ago* (last edited 3 days ago) (1 children)

oh actually thinking about it again, the only thing that's stored on the USB is the keyfile right?

Sorry I'm still a bit confused after trying to follow alongside the arch guide

[โ€“] timewarp 2 points 3 days ago (1 children)

Well technically it is the header but yeah that is what is stored there. There are times you might want to change the encryption and what not so I guess the header could get changed or you could add a key, but regardless you'll know what needs to happen cause it ain't going to happen otherwise. I only had two issues during my time of a detached header.

One was that something changed with mkinitcpio. Can't remember if it was my fault partially too or not, but basically had to add back exfat support to the initramfs since that is what I had formatted the USB drive as to access my key file. The second time was an update with systemd that caused a change with how the systemd-boot module loaded the drive.

The important thing is to get familiar with booting into a recovery image (basically the Arch Installer) and using the header flag with cryptsetup and `cryptsetup open --header' I believe followed by your header file and the encrypted drive/partition. After that is is just a matter of mounting the decrypted device mapper partition. You should only need to do this if you have issues but once I figured out how it saved me a lot of anxiety.

[โ€“] [email protected] 2 points 3 days ago* (last edited 3 days ago) (1 children)

ahhh ok I'm starting to understand now thank you!

Also for the exfat problem you encountered, I've read that the boot or EFI partition should be formatted with FAT32 or the similar FAT types (like FAT12?) as it's supported whereas the other file types are not mentioned, I'll add the link here if I can find it again

https://bbs.archlinux.org/viewtopic.php?id=236633
While this forum post wasn't the exact page I initially saw, the users there also states the same info

[โ€“] timewarp 2 points 3 days ago* (last edited 3 days ago)

Yes that is true, but if you're using a detached LUKS (prob LUKS2) header then the USB drive isn't your boot partition and the file system type won't matter as much for that than the order of kernel modules loaded before boot.

Using a detached LUKS header appealed to me at the time because it has most of the same benefits as an encrypted boot partition like available with GRUB and GRUB at the time still only supported the first version of LUKS. Plus I was pretty confident in my ability to securely back up my LUKS header, so that if I traveled then I could grab a copy of the header remotely if the USB drive was somehow compromised. That way you can travel and not have to worry about your laptop or whatever revealing as much information about your FDE setup vs. if the LUKS header is on the internal drive, it still provides details about the encryption.