Imagine that you want to host a Linux machine outside of your own physical control. Imagine that it can get resold later to people who may be quite curious about the data on said machine’s HDDs. What do you do? What DO YOU DO?! There are many options. One of them is to use the LUKS (Linux Unified Key Setup) encryption and just encrypt the whole disk (short of /boot).
One of LUKS’ advantages is that it is built into the CentOS/Kickstart (even 5.x)
Anaconda. Enabled via --encrypted --passphrase=<SOMEPHRASE> set of options in
the kickstart.cfg file as a part of the “part” directive. Looks like this, in
context:
bootloader --location=mbr --driveorder=sda,sdb --append="ide=disable clocksource=hpet processor.max_cstate=1 time"
clearpart --all --initlabel --drives=sda
part /boot --size=200 --asprimary --ondisk=sda
part pv.1 --size=40000 --grow --ondisk=sda --encrypted --passphrase=test01
volgroup vg01 pv.1
logvol / --vgname=vg01 --name=root --size=20000
Note: /boot isn’t encrypted. Do we care? (typically, this is a PITA)
I’ve tested this and the OS just installs. The prompt to enter the key happens at initrd level when the system reboots, before root is pivoted from initrd to the real volume group.
An additional concern is what happens if there is power loss – encrypted file systems (on, in this case, the actual PV which underpins the LVM) do not take kindly to that sort of a thing and recovery may get Ugly™.
Rebooting the machine without interacting with it via a DRAC or some other console emulation will not work.
After the install, we obviously want to change the passphrase, what with ‘test01′ being somewhat weak and all.
Here’s how to do it (assuming that /dev/sda2 is the encrypted PV)
- Boot from a rescue media.
- Run
cryptosetup luksAddKey /dev/sda2. - At the prompt “Enter any LUKS passphrase:“, enter the current passphrase (using the kickstart snippet above, ‘test01′).
- When prompted, enter the new passphrase. Re-enter to verify it.
- Make note of the output – it’ll indicate which LUKS crypto slot was used.
It’ll be the argument to
cryptosetup luksKillSlot /dev/sda2 <SLOT#>. - When prompted “Enter any remaining LUKS passphrase:“, enter the new passphrase.
Voila.
Note: LUKS, like almost everything else, is susceptible to the “cold boot” attack. We may need to look at doing TPM with PINs to mitigate some of that, but it doesn’t help much with the “I have now cooled and removed your RAM. Mu ha ha” case.
One of the ideas considered was to do a Really Clever Thing ™: The DRAC (Dell Remote Access Controller) has the ability to become a “CD” to the system. One could imagine a setup in which, in order to boot, the sysadmin uploads a LUKS key to the storage medium, the system boots, and in instead of the passphrase, uses a file on the virtual CD as an unlock key. Once the machine is up, the storage can be wiped, though wiping FLASH-based storage gets particularly tricky.
It is worth noting that, should it be desirable, it is possible to protect a single LVOL rather the whole PV, which makes things like changing pass phrases and system boot-time troubleshooting a lot easier.
We looked at the other common piece of software – TrueCrypt, and for full-disk encryption, coupled with ease of setup, it does not compete. The anti-forensic features of it, while impressive, aren’t of interest for us in solving this particular problem, LUKS it is.
Strongly suggested is the following additional reading: http://code.google.com/p/cryptsetup/wiki/FrequentlyAskedQuestions
