HOWTO: Automatically Unlock LUKS Encrypted Drives With A Keyfile

Want to support HowtoForge? Become a subscriber!
 
Submitted by sjau (Contact Author) (Forums) on Mon, 2008-07-07 18:33. :: Security

HOWTO: Automatically Unlock LUKS Encrypted Drives With A Keyfile

Author: Stephan Jau
Revision: v1.0
Last Change: July 3 2008

Introduction

Well, I have written so far two tutorials with LUKS/dm_crypt involved. First one was how to enable encryption on Feisty Fawn (wasn't included back then by default) and the other one was how to reboot/unlock through a remote connection.

This howto was then written because of a question in the second howto. The problem there was how to unlock multiple devices in the intial ramdisk remotely. I suggested instead to use a keyfile for automatic unlocking. The keyfile should be stored in the normally encrypted root partition - so you still have to unlock that one. During boot process it will then be used to unlock all the other devices.

Of course one could also use an encrypted LVM so that all space is encrypted but only one password is required. I have not seen a usage for LVM so far and it seems, that others do not also but prefer to have individual encrypted devices. That way you could easily move an encrypted harddisk to another computer. I'm not sure if that works with LVM encrypted drives also because I have no experience with it.

One might ask how secure is this setup? I'd say pretty safe. During this howto the keyfile will be made read-only to root. So, if someone can access the keyfile you have more serious problems anyway on your computer.

 

Step 1: Create a random keyfile

sudo dd if=/dev/urandom of=/root/keyfile bs=1024 count=4

This will create a file with random content with the size of 4096 bits (better than a 20/30 character password....). You can use any file to act as keyfile but I think a 4kb file with random content is good suited.

 

Step 2: Make the keyfile read-only to root

sudo chmod 0400 /root/keyfile

That will make the keyfile readable only by root. If someone get access to this keyfile, then you have a bigger problem on your computer anyway.

Alternatively chown your desired keyfile to root:root and move it into the /root folder

 

Step 3: Add the keyfile to LUKS

LUKS/dm_crypt enabled devices may hold up to 10 different keyfiles/passwords. So, next to having the already setup password we're going to add this keyfile as additional authorization method.

sudo cryptsetup luksAddKey /dev/sdX /root/keyfile

sdX is of course your LUKS device.

First you'll be prompted to enter an (existing) password to unlock the drive. If everything works well, you should get an output like this:

Enter any LUKS passphrase:
key slot 0 unlocked.
Command successful.

 

Step 4: Create a mapper

LUKS devices need to create a mapper that can then be referenced in the fstab. Open /etc/crypttab

sudo nano /etc/crypttab

and add then a line like this:

sdX_crypt      /dev/sdX  /root/keyfile  luks

or you can use the UUID of the device:

sdX_crypt      /dev/disk/by-uuid/247ad289-dbe5-4419-9965-e3cd30f0b080  /root/keyfile  luks

sdX_crypt is the name of the mapper that is being created. You can use here any name e.g. "music" or "movies" or "sfdsfawe" ....

Save and close the file by issuing ctrl-x, enter, enter. Ctrl-x closes nano but first it asks to save the file [yes = enter] and what the name shall be [same name = enter].

What we have done there actually is telling that /root/keyfile shall be used instead of password entry to unlock the drive.

 

Step 5: Mount the device in fstab

Now, we have an unlocked device (well, not yet but when the system is being booted up) and we just need to mount it now. Open /etc/fstab:

sudo nano /etc/fstab

and add a new entry like:

/dev/mapper/sdX_crypt  /media/sdX     ext3    defaults        0       2

Make sure you have the correct mapper name that you added in step 4. Also make sure that the mount point/folder exists. After having added it, save again the file and close it (ctrl-x, enter, enter).

 

Step 6: Reboot or remount

That's it. Now you can reboot and the additional devices should be auto-unlocked and mounted. You can also test it by remounting all devices:

sudo mount -a


Please do not use the comment function to ask for help! If you need help, please use our forum.
Comments will be published after administrator approval.
Submitted by Anonymous (not registered) on Thu, 2014-06-05 10:54.
I'd not use /dev/urandom for key file generation. Those few bytes should better be squeezed out of /dev/random I think.

 

Submitted by agubernatorov (not registered) on Tue, 2013-10-22 14:58.
I was using russian ecryption instruction http://sysadmin.te.ua/tag/luks
Submitted by Anonymous (not registered) on Thu, 2013-06-06 05:02.

In step 3, I don't get any confirmation, even though the keyfile is successfully added. (Xubuntu 12.04, cryptsetup 1.4.1).

 And, sudo mount -a won't mount it in my case, only reboot helped.

Submitted by Anonymous (not registered) on Tue, 2010-08-10 04:46.

This would be a useful technique for me, if it could be adapted to work within an initrc for booting. Then, if a computer is plugged into my network, I could do a network boot that would supply the keyfile, and the boot could proceed automatically. If the computer was not plugged into my network, I could boot from the local hard drive and supply a manual decryption key. I suppose someone could also do something similar with a USB stick. Even better would be if there was a way to require 2 out of 3. Either it is plugged into my network and I have the USB stick, or I supply the password. Or it is not plugged into my network and I need both the USB stick and the password. Bill

Submitted by prairiedog (not registered) on Fri, 2009-11-13 06:35.

I have a Mythbuntu PVR which does double duty as a backup device because it has extra disk space, but it's a sitting duck in case of a break-in.  If it ever went missing then it would be preferable if the personal data on it became inaccessible.

It should work to encrypt the volume and put the keyfile elsewhere on the network, like on a server in a closet.  Even if both machines went missing, the odds of a thief figuring the system out are pretty low.

Submitted by Anonymous (not registered) on Fri, 2009-08-14 06:05.

I tried pretty hard to get this tutorial to work, but I could never get the mapper to work no matter how I tried.

I eventually wrote a script that lived in /etc/rc.local, and that ran the cryptsetup luksOpen command manually upon boot. That worked pretty well until the system crashed (for another reason), and now the USB drive seems to be shot. I'm guessing the encrypted partition needed to be properly closed, not crashed.

In any case, this config is simply too complicated. Looks like I'll have to live with a lack of encryption on my backup drive...for now.

Submitted by Tof (not registered) on Fri, 2009-02-13 16:09.

This is exactly what I wanted (my USB drives are crypted in case they are stolen but as long they are on the server, I don't care), but I had an issue on Fedora with USB drives.

At boot time /etc/rc.d/rd.sysinit should use fstab and crypttab to issue a luksOpen. The issue is that at that time the usb drive is not yet detected in /dev/disk/by-uuid. The only solution I found here so far, is to add a delay before using cryptsetup. For that I have created a module (/etc/sysconfig/modules/waitForExtraDrives.modules) that wait for extra disk(s) with a timeout of 10s. This module will be run automatically by /etc/rc.d/rd.sysinit before trying to mount crypted drives (TBD: We should find an other solution !):

/etc/sysconfig/modules/waitForExtraDrives.modules:

#!/bin/sh

timeout=10
nbInternalDrives=1

echo -n "Waiting for extra disk(s) to be detected: "
count=0
while [ $(ls /dev/disk/by-uuid/ 2>/dev/null | wc -l) -le ${nbInternalDrives} -a ${count} -lt ${timeout} ]
do
       count=$(( $count + 1 ))
       echo -n "."
       sleep 1
done
if [ $(ls /dev/disk/by-uuid/ 2>/dev/null | wc -l) -gt ${nbInternalDrives} ]
then
       echo " Done"
else
       echo " TimeOut"
fi
Submitted by Philip Jägenstedt (not registered) on Wed, 2008-10-01 16:17.
Unless the root file system is encrypted this is a terrible idea. Everything that encryption protects you against would be negated. Somebody who gains remote access to your computer wouldn't need the keys since the disks would probably already be mounted. If, on the other hand, somebody gets local access (for example by stealing your disks) then the permissions on the file doesn't matter at all, the data is there on the disk and can be read by simply putting it in another computer. Don't store the keyfiles unencrypted unless the medium itself is reasonably safe (e.g. stored in a bank vault)
Submitted by sjau (registered user) on Sun, 2008-11-30 16:42.
From the howto: "The keyfile should be stored in the normally encrypted root partition - so you still have to unlock that one."
Submitted by Anonymous (not registered) on Tue, 2009-01-06 17:22.

from the reply: "Somebody who gains remote access to your computer wouldn't need the keys since the disks would probably already be mounted"

that means they ARE unlocked already when a bad guy comes in.

Submitted by Stephan (not registered) on Wed, 2008-11-05 14:18.
A Bank vault is not a safe place anymore!
Submitted by Mike (not registered) on Sun, 2009-04-05 00:54.
One reason this is still useful is to protect a USB device that might get stolen. This way it would be auto-mounted, and then if it's ever stolen you're covered. It seems logical enough to me!