Full disk encryption with USB unlock on Arch Linux

󰃭 2025-11-10

Disclaimer: I didn’t invent anything new here, this is just a case of scattered information that’s annoying to put together. All sources are linked throughout the article.

Another disclaimer: I’m not a security expert and I don’t claim to be. This is just a solution that I’m using, if following anything that I write causes any problems including but not limited to data loss or theft, I don’t take any responsibility. You’re on your own.

I find myself in this very particular situation: I have a server running Arch in which I want to have full disk encryption, but being a server I want to be able to reboot it without having to insert the password manually.

A solution to this problem is using TPM to store a decryption key. This works but it’s not ideal if someone unauthorized takes possession of the server, since they will have access to the unencrypted disk by just turning the computer on.

Another solution is to store a decryption key on a regular USB stick, and in case you hear weird noises in the night or suspect someone might be out to take your server from you, you just remove the USB stick and either hide it or destroy it.

But let’s get some things out of the way first.

Are you running Arch on a server?!?!

Yes, get over it.

Is this secure?

As for any time you ask this question, the answer is it depends on your threat model. In general, no this isn’t very secure, but it’s good enough for what I need and better than any alternatives I found. If you think you know a better way to achieve a similar result, please do let me know.


What you’ll need

  • Arch install with full disk encryption
  • USB drive
  • Shell access

Steps

  1. Boot up your system using password unlock (hopefully for the last time)
  2. Insert a USB drive that you’re willing to sacrifice
  3. Format it as a single FAT32 partition on top of a MBR partition table
  4. Mount it to a location of your choosing, I’ll use /mnt
  5. Setup a key file as follows (Source)
    • Create a new random key in the USB drive, named anything you want, I’ll call it key.lek: dd if=/dev/urandom of=/mnt/key.lek bs=4096 count=1
    • Identify your encrypted volume: blkid --match-token TYPE=crypto_LUKS -o device
      • You should end up with a device path, for example /dev/sdx2. I will use this in the following command so make sure to replace it on your end
    • Add this new random key as a valid key to decrypt your disk: cryptsetup luksAddKey /dev/sdx2 /mnt/key.lek
      • You will be asked for one of the passphrases already set up for your encrypted volume, provide it to continue
  6. Modify your /etc/mkinitcpio.conf to include the vfat module, so that the USB drive will be readable by the initramfs (Source)
    • For clarity, the MODULES row in your mkinitcpio.conf file will look something like this: MODULES=(vfat)
    • In case you already have other modules, don’t remove them of course, just add this one
  7. Regenerate your initramfs with mkinitcpio -P
  8. Modify your kernel command line arguments to instruct it on how to decrypt using the USB drive (Source)
    • Take note of the UUID of the USB drive partition in which you stored the key with lsblk -f. Since it’s a FAT32 it should be quite short compared to other partition UUIDs.
    • Add this at the beginning of your kernel options: cryptkey=UUID=YOUR-USB-DISK-PARTITION-UUID-HERE:vfat:/key.lek

That should be it, reboot and your disk should decrypt automatically. Enjoy!


Enter your instance's address


More posts like this

RDNA3 Fan Control in Linux - Why are my GPU fans not spinning under load?

󰃭 2024-01-20 | #amdgpu #gpu #linux #radeon

I’ve recently upgraded my GPU from a 5700XT to a 7800XT, and of course using a new GPU close to launch on Linux would reveal some paper cuts.

Turns out my GPU fans weren’t spinning, even under load. It helps that it’s winter and I have some very effective case fans, but it didn’t really make sense that at 88°C junction temperature the fans wouldn’t spin.

Continue reading 