Setting up a LUKS partition to use a USB key

jonnybarnes · 2015-01-28 14:34:27

Im playing with an old netbook I've been given, essentially practicing for when I get a new desktop. Anyway, I want to install Arch on a LUKS encrypted partition and have it unlocked at boot time using a key located on a USB key.

This is what I did first time round and whilst the root partition is indeed encrypted I'm having to type a passphrase every boot:

loadkeys uk
lsblk
gdisk /dev/sda
  outout should eventually look like:
  Command (? for help): p
  Disk /dev/sda: 
  Logical sector size: 512 bytes
  Disk identifier (GUID): 
  Partition table holds up to 128 entries
  First usable sector is 34, last usable sector is 
  Partitions will be aligned on 2048-sector boundaries
  Total free space is 2014 sectors (1007.0 KiB)
 
  Number  Start (sector)    End (sector)  Size       Code  Name
     1            2048            8191   3.0 MiB     EF02  BIOS boot partition
     2            8192         1032191   500.0 MiB   8300  boot
     3         1032192                               8300  root
cryptsetup -v --cipher aes-xts-plain64 --key-size 512 --hash sha512 --iter-time 5000 --use-random luksFormat /dev/sda3
  enter a passphrase twice here
cryptsetup open /dev/sda3 ARCHROOT
mkfs.ext4 /dev/sda2
mkfs.btrfs /dev/mapper/ARCHROOT
mount /dev/mapper/ARCHROOT /mnt
cd /mnt

Would I need to

cryptsetup luksAddKey /path/to/keyfile

after the first cyptsetup step? If so can the live Arch environment mount USB drives at this point in the installation process?

nstgc · 2015-01-28 14:56:03

I'm currently working on something similar. I just got my new laptop in the mail and want to make sure this thing is secure. I'll let you know if I figure anything out.

firecat53 · 2015-01-28 15:39:24

I have this setup using a keyfile (don't set a passphrase) on the USB drive to unlock the luks partition. Here are the setup notes I kept. Hopefully something useful in there for you.

Scott

Last edited by firecat53 (2015-01-28 15:46:33)

nstgc · 2015-01-28 19:12:01

I tried following your notes for my laptop, however when I checked to make sure everything worked properly it failed. I then tried again on my desktop using a test partition with nearly the exact same input and it worked. The chief, non-trivial, difference was the use of an actual file on a mounted FS as opposed to a device. I dd'ed /dev/random to a USB drive and used "/dev/sdc" as the file. Since *nix systems are suppose to treat everything as a file, I figured this would work.

I tried using the USB keyfile on my desktop. I noticed this time, however, that it complained that the keyfile was too large. Apparently a 128MiB keyfile is not supported . Using a smaller, less unreasonable size it worked fine.

[edit] Oh, wait, it was trying for a 32GB USB drive. As in teh whole thing. That was the problem.

[edit2] Okay, something isn't work. Not sure what, or why.

[edit3] It doesn't seem to like

GRUB_CMDLINE_LINUX="cryptdevice=/dev/disk/by-label/SCOTTY:root:allow-discards cryptkey=/dev/disk/by-label/ISO:ext4:/<path/to/keyfile/on/flash drive>"

In particular it seems as if it located the partition by label.

[edit4] To confirm, I got it to work, however there was the small snag with identifying the disk by label. Aside from that Firecat's notes were great.

Last edited by nstgc (2015-01-30 21:30:01)

teateawhy · 2015-02-01 22:18:44

Nobody has mentioned this yet, here is the wiki page that deals with storing the key on a USB key:
https://wiki.archlinux.org/index.php/Dm … _a_keyfile

nstgc · 2015-02-02 02:21:11

teateawhy wrote:

Nobody has mentioned this yet, here is the wiki page that deals with storing the key on a USB key:
https://wiki.archlinux.org/index.php/Dm … _a_keyfile

I saw Firecat's post first, which is, in my opinion, better than what's on the wiki.

teateawhy · 2015-02-03 19:58:16

I think it is a good idea if you edit the wiki and add a link to firecat's post. Or even add some of his content directly, if firecat allows it

firecat53 · 2015-02-03 20:51:30

Of course!! Just please someone smater than me idiot check it first!! I'll try and contribute some to the wiki given a little time....

starfry · 2015-02-07 12:20:49

Hi, just thought I'd chip in as I have just done all this and cleared away a few problems along the way...

I have my laptop 100% encrypted with detached headers and keys stored in an encrypted partition on a USB key. The laptop has two hard drives that together form a LVM volume group containing a root volume plus several others. There is one key/header per physical disk and both are the whole volume group.

The encrypted USB partition contains the headers and keys for the pv containing the lv that is the root filesystem. I enter the passphrase for the encrypted partition and Grub then uses the keys in that partition to decrypt the encrypted root to read the kernel and initramfs. I have them on the filesystem so that I don't have to faff with moving kernels etc onto USB every time I update. The initramfs contains the keys and headers for all of the pv's that form the vg so it they can be unlocked and the lv's activated by systemd during boot. (You have to use systemd in the initramfs for this - Grub can only unlock one device).

I also have a server that has a hybrid config where the root is plain but some filesystems exist that are encrypted. This time, systemd prompts for the passphrase of the encrypted partition on the USB key and reads the necessary headers and keys from there. The kernel and initramfs are on a plaintext device so Grub needs no special configuration.

To get this to work, I extended Grub with support for detached headers. See http://grub.johnlane.ie. I have a PKGBUILD for this and will stick in on AUR if there's interest (I just haven't got around to it yet).

It's also necessary to have the latest systemd (systemd-git from AUR) because 218 (current latest) doesn't support detached headers in /etc/crypttab. See "man crupttab" and check out the new "--header" option.

If you want to be able to pull the USB stick out after booting (once the devices are unlocked and the keys/headers are no longer needed) then you cannot use /etc/crypttab because the systemd generator imposes too strong dependencies that makes it unmount the volumes if the device containing the key file is unlocked. It's reported upstream and there's a TODO for it. Meanwhile, 've used a custom unit to work around the problem. Again, I can post if there's interest.

If I can enlighten any more let me know...

frostschutz · 2015-02-07 12:36:17

starfry wrote:

I have my laptop 100% encrypted with detached headers and keys stored in an encrypted partition on a USB key.

Do you have a backup of those headers, then? Kinda sucks to lose all your data to a faulty USB key.

starfry wrote:

I enter the passphrase for the encrypted partition and Grub then uses the keys in that partition to decrypt the encrypted root to read the kernel and initramfs.
[...]
To get this to work, I extended Grub with support for detached headers.

Wow. Personally I don't let Grub handle the encryption. It's all in Initramfs for me (luks encrypted keyfiles). Security wise it shouldn't matter, if someone can modify my Initramfs, they can also modify my Grub. It may be harder in your case since you already use a modified Grub...

starfry wrote:

If you want to be able to pull the USB stick out after booting (once the devices are unlocked and the keys/headers are no longer needed) then you cannot use /etc/crypttab because the systemd generator imposes too strong dependencies that makes it unmount the volumes if the device containing the key file is unlocked.

Oh. That's strange. I can pull my USB stick as soon as Grub is done loading the kernel and initramfs, i.e. the moment kernel messages start to appear. They keys and all are part of the Initramfs, so the USB stick is no longer necessary.

Basically, it's this method: https://wiki.gentoo.org/wiki/Custom_Ini … ed_Keyfile and the first example here: https://wiki.gentoo.org/wiki/Custom_Initramfs/Examples

Last edited by frostschutz (2015-02-07 12:39:18)

starfry · 2015-02-07 13:30:45

frostschutz wrote:

Do you have a backup of those headers, then? Kinda sucks to lose all your data to a faulty USB key.

hehe, yes several USB keys and other secure storage.

frostschultz wrote:

Security wise it shouldn't matter, if someone can modify my Initramfs, they can also modify my Grub.

The other thing I forgot to mention is that my USB stick is also my boot device. There's no Grub or any other bootloader on the target systems to mess with. If started without the key, they just say "operating system not found". Even if someone got hold of the USB stick, as a last line of defence, all the keys and headers that Grub needs (as well as the Grub boot config) is stored on an encrypted partition on the USB stick that requires a passphrase to unlock.

frostschultz wrote:

I can pull my USB stick as soon as Grub is done loading the kernel and initramfs, i.e. the moment kernel messages start to appear. They keys and all are part of the Initramfs, so the USB stick is no longer necessary.
Basically, it's this method: https://wiki.gentoo.org/wiki/Custom_Ini … ed_Keyfile and the first example here: https://wiki.gentoo.org/wiki/Custom_Initramfs/Examples

That gentoo example doesn't use systemd. I wanted to use the native systemd functionality as much as possible. My my initramfs opens what's necessary for boot (essentially the root filesystem) and the main early-boot does everything else. I wanted to use the standard /etc/fstab and /etc/crypttab and allow systemd to sort everything out but I encountered the dependency problem. I have a very simple workaround for it, however.

I'll just add to that as well that the systemd issue is only on systems where the initramfs is insecure and, therefore, cannot contain keys. Those systems with the initramfs on an encrypted filesystem don't need the usb key to unlock the rest of the encrypted filesystems because the keys are in the encrypted initramfs. They only need the USB key to unlock the root. I cannot secure the initramfs on some systems because of the way they boot (specifically, non-x86 boxes that cannot use Grub or are unable to boot off arbitrary devices).

Last edited by starfry (2015-02-07 14:09:29)

gcala · 2015-02-11 14:23:42

Hi, I'm trying to unlock my encrypted home partion at boot time through a keyfile stored on flash-drive, but without luck. I followed wiki and firecat53's gist.

1) added keyfile (an image stored in root of flash-drive) to luks header; i'm able to open di device using the keyfile in command line so i presume this step is right.
2) labeled both home partition and flash-drive: SCOTTY for sda10 and TX8GB for sdb1
3) added hooks and modules as explained in wiki and firecat53's guide plus mkinitcpio command
4) disabled previously added crypttab line to unlock partition at boot time through passphrase (homecrypt UUID=XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX none luks,timeout=180)
5) added the following options to kernel in grub.cfg:

cryptdevice=/dev/disk/by-label/SCOTTY:homecrypt cryptkey=/dev/disk/by-label/TX8GB:vfat:/bar.jpg

Unfortunately, something goes wrong during boot and after a timer with the message "A start job is running for dev-mapper-homecrypt.device" the boot ends in a maintenance console.

If I restore the crypttab line (step 4) it asks for the passphrase and, after interting it, the system completes successfully the boot process.

Am I missing any step?

Thanks

teateawhy · 2015-02-11 16:54:26

@gcala
For the home partition it is better to use crypttab instead of the cryptdevice= parameter in grub.cfg.
See:
https://wiki.archlinux.org/index.php/Dm … n#crypttab
Using the cryptdevice= parameter means you are unlocking the partition from the initramfs. This is not necessary for the home partition, as the home partition can be unlocked later in the boot process. Unlocking from the initramfs is only necessary when you need access to the partition at the beginning of the boot process, for example the root partition.

gcala · 2015-02-11 17:23:32

teateawhy wrote:

For the home partition it is better to use crypttab instead of the cryptdevice= parameter in grub.cfg.
See: https://wiki.archlinux.org/index.php/Dm … n#crypttab

Thanks teateawhy, but I already consulted that wiki page and, if I'm not wrong, it does not explain which path to use. It has some examples but nothing related to external flash-drive. For instance, it reports the following line:

externaldrive         UUID=2f9a8428-ac69-478a-88a2-4aa458565431        none    luks,timeout=180

saying that "A keyfile can also be set up and referenced instead of none.", Ok, but how? /mnt/media/? /run/media/root/TX8GB? or /dev/disk/by-label/TX8GB:vfat:/bar.jpg?

Last edited by gcala (2015-02-11 17:24:20)

teateawhy · 2015-02-11 19:03:39

@gcoala
Ah yes you are right the keyfile must be accessed by its path, which is only possible after the usb stick has been mounted. So using crypttab does not work unless you mount the usb stick from initramfs. I think it is better to continue with your inital setup as firecat has described it and forget what i said before.
"A start job is running for dev-mapper-homecrypt.device"
This message looks like systemd has generated it. Do you still have the "systemd" hook in /etc/mkinitcpio.conf ? I think you have to remove it for this to work.

firecat53 · 2015-02-11 20:23:52

@gcala - the path to the keyfile is referenced to the root of the USB drive partition. For example, my keyfile is at /scotty/<keyfile.jpg>, where scotty/ is a directory in the root directory of the flash drive filesystem and the partition label is ISO. So my grub line looks like:

"cryptdevice=/dev/disk/by-uuid/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx:root:allow-discards cryptkey=/dev/disk/by-label/ISO:ext4:/scotty/<filename>.png"

I'm not sure about the other error message. You should definitely make sure you can access your encrypted partition using just the keyfile from a live CD/USB session.

Just in case it helps, my MODULES and HOOKS lines in /etc/mkinitcpio.conf are:

 MODULES="i915 ext4 nls_cp437"
HOOKS="base udev autodetect consolefont modconf block encrypt filesystems keyboard fsck"

Scott

gcala · 2015-02-12 10:36:32

Success!! The trick is to use UUID to identify the encrypted device instead of label. Thank you all.

gcala · 2015-02-12 11:03:26

frostschutz wrote:

I can pull my USB stick as soon as Grub is done loading the kernel and initramfs, i.e. the moment kernel messages start to appear. They keys and all are part of the Initramfs, so the USB stick is no longer necessary.

So you just pull the flash drive without 'umount' command? Is it safe?

frostschutz · 2015-02-12 13:15:09

In my case it's safe because it never got mounted in the first place.

Grub is on the stick and Grub loads kernel + initramfs. But the kernel never mounts the stick itself, it mounts the root partitions instead which are all on internal SSD / HDD. So once grub is done and kernel starts booting, the stick no longer matters. I put the encrypted keys in the initramfs itself.

The stick is /boot but it's set to noauto in fstab. OTOH this means when I update kernel I have to mount /boot manually first.

Last edited by frostschutz (2015-02-12 13:16:19)

Arch Linux

#1 2015-01-28 14:34:27

Setting up a LUKS partition to use a USB key

#2 2015-01-28 14:56:03

Re: Setting up a LUKS partition to use a USB key

#3 2015-01-28 15:39:24

Re: Setting up a LUKS partition to use a USB key

#4 2015-01-28 19:12:01

Re: Setting up a LUKS partition to use a USB key

#5 2015-02-01 22:18:44

Re: Setting up a LUKS partition to use a USB key

#6 2015-02-02 02:21:11

Re: Setting up a LUKS partition to use a USB key

#7 2015-02-03 19:58:16

Re: Setting up a LUKS partition to use a USB key

#8 2015-02-03 20:51:30

Re: Setting up a LUKS partition to use a USB key

#9 2015-02-07 12:20:49

Re: Setting up a LUKS partition to use a USB key

#10 2015-02-07 12:36:17

Re: Setting up a LUKS partition to use a USB key

#11 2015-02-07 13:30:45

Re: Setting up a LUKS partition to use a USB key

#12 2015-02-11 14:23:42

Re: Setting up a LUKS partition to use a USB key

#13 2015-02-11 16:54:26

Re: Setting up a LUKS partition to use a USB key

#14 2015-02-11 17:23:32

Re: Setting up a LUKS partition to use a USB key

#15 2015-02-11 19:03:39

Re: Setting up a LUKS partition to use a USB key

#16 2015-02-11 20:23:52

Re: Setting up a LUKS partition to use a USB key

#17 2015-02-12 10:36:32

Re: Setting up a LUKS partition to use a USB key

#18 2015-02-12 11:03:26

Re: Setting up a LUKS partition to use a USB key

#19 2015-02-12 13:15:09

Re: Setting up a LUKS partition to use a USB key

Board footer