This page is only applicable to CentOS/RHEL 5.4 and later. Equivalent instructions are available for CentOS/RHEL 5.0 to 5.3 and 6.5+.
As of CentOS 5.4, the default installation now allows one to use encrypted disks. If you have encrypted devices, you will be prompted at boot time for your LUKS passphrase.
This is perfect for laptop users, but crypto is sometimes desired in other situations as well where you might not necessarily want to be typing in a passphrase. This page documents a method by which you can place a second LUKS key on a USB stick to boot your machine. Note that if an antagonist gets both your USB stick and disk, your data is compromised.
This mechanism is designed to fail safe: If you don't have
the USB stick, or if the patched
mkinitrd gets overwritten
(and not noticed), or if you have to boot from CD/DVD, then you will
be prompted for the original LUKS key, which is a whole lot better than
saying "oops ... too bad".
(In this way, the current mechanism is more robust than the
This procedure assumes that you have already performed a fresh install of CentOS 5.4+ where:
vg1. We will further assume for this example that
/dev/sda2. (If you were using mirroring it might be, for example,
The procedure is outlined as follows:
You will be modifying your boot procedure. While this should be benign, you should be paranoid, especially since your data is already encrypted. Take some time to be paranoid.
Unless you have a virgin system containing no useful information, back up your system before you start.
If you have automated system updates enabled, disable them during this procedure.
Next, you should configure a copy of your existing (working) initrd. This will allow you, during the testing phase, a boot mechanism should something go wrong. (You can delete the copy later.)
If you're using the Grub bootloader, then edit your
/etc/grub.conf file. Duplicate one of the entries,
changing the entry title and the name of the initrd image. Make
sure create a copy of the initrd image to match the modified name.
Reboot your system with your backup bootloader configuration to make sure it works.
You should now set up your USB device that will hold the LUKS key.
Attach the USB device to your machine. Your
/var/log/messages should show the device
attach, and you should be able to determine the device name.
You should see something like the following:
SCSI device sdc: 3940479 512-byte hdwr sectors (2018 MB) sdc: Write Protect is off sdc: Mode Sense: 45 00 00 08 sdc: assuming drive cache: write throughIn this case, the device is
/dev/sdcand the FAT partition that will contain our crypto key is
sd device names can get dynamically renamed
under some circumstances, you need to be able to identify the USB
device in some other fashion. Because of the limited environment
that is available at boot time, practically this means that you will
need to give your USB device a label.
You can see if your USB device already has a label via the
blkid command. Continuing with our example:
# blkid /dev/sdc1 /dev/sdc1: SEC_TYPE="msdos" UUID="AB12-34CD" TYPE="vfat"If there is no
LABELoutput from the above command (or if you would prefer a different label), you can use the
mlabelcommand to set it:
mlabel -i /dev/sdc1 ::luks_keyThe choice of label is arbitrary; you need only later configure
mkinitrdto use the same label. Note that the above usage of
mlabel, while valid, is not documented in the
You should now see the new label (which will be upper-cased):
# blkid /dev/sdc1 /dev/sdc1: SEC_TYPE="msdos" UUID="AB12-34CD" TYPE="vfat" LABEL="LUKS_KEY"
Temporarily mount the USB device somewhere appropriate:
mount /dev/sdc1 /mntor
mkdir -p /flash/key mount /dev/sdc1 /flash/keyIf you'd like to have an entry in your
/etc/fstabfile, you should use the device label, ID or UID to identify it, because of the
sddynamic rename problem. I'd also suggest setting a restrictive umask and not automounting it:
/dev/disk/by-label/LUKS_KEY /flash/key vfat noatime,umask=0377,noauto 0 0
Now create a file that will contain the LUKS key. Again the file name
is arbitrary (as long as it later matches the
configuration). The content of the file is also arbitrary, but it should
follow the usual conventions for good, strong, passphrases. Since you
will likely never type in this passphrase, you can use a randomly
dd if=/dev/random bs=1 count=32 | od -An -t x4 -w32 | perl -pe 's,\n,,;' > /flash/key/luks.keyThe reason for the perl command above is to ensure that the key is all on one line, in the unlikely event that you have to ever type it in. See the discussion of the
cryptsetup(8)man page for details.
Add the new key to your encrypted device:
cryptsetup luksAddKey /dev/sda2 /flash/key/luks.keyWhere
/dev/sda2is the encrypted device holding
vg1. You will be asked for your existing passphrase, twice. You should now see two keys in the LUKS header:
cryptsetup luksDump /dev/sda2
when unlocking LUKS devices, assumes that doing
so will always be interactive. In order to have the key to be taken
from a device such as a USB fob, it is necessary to patch
Download the mkinitrd.patch file, and apply it:
cd /sbin patch -b -p0 < mkinitrd.patchThis will leave the original as
Next, we want to know if a system update or anything else undoes the patch.
To monitor this, download
0755, and place it in
(Note that there is a different version of this file for CentOS 5.3 and
earlier in other directories of that FTP site — make sure you're getting
the correct version as specified above.)
Unless you configure the newly patched
mkinitrd, it will
behave the same way as the stock one (this is a fail-safe behavior).
First, create the config file with appropriate permissions:
touch /etc/sysconfig/mkinitrd/usb-crypto-key chmod 0755 /etc/sysconfig/mkinitrd/usb-crypto-keyThen edit it so that it contains the following variables. The values must match those you selected when you labelled your USB device and created the key file:
CRYPTO_KEY_DEVICE="LABEL=LUKS_KEY" CRYPTO_KEY_FILESYSTEM="vfat" CRYPTO_KEY_MOUNT_POINT="/flash/key" CRYPTO_KEY_FILE="$CRYPTO_KEY_MOUNT_POINT/luks.key" MODULES="$MODULES usb-storage vfat"The mount point does not necessarily need to match; mkinitrd will create it if necessary. If you have the USB device listed in your
/etc/fstabfile, keeping the same mount point may cause less confusion, though.
If you prefer, you can instead download a sample usb-crypto-key file and edit it appropriately for your machine.
Before you do this step, you've already configured a backup bootloader entry, right?
After performing all the steps above, you're now ready to create your new initial ram disk. Assuming you're building it for the currently running kernel, issue the following command:
mkinitrd -f /boot/initrd-`uname -r`.img `uname -r`There should not be any errors or other output.
Test by rebooting your machine a couple of times:
If you have problems, then boot using your backup bootloader entry and go splunking. If you have problems with the backup bootloader, you can boot the DVD/CD in rescue mode.
After you're finished testing, don't forget to reenable your automated updates, if you had previously disabled them.
Last Updated: 22 May 2014