Given that laptops are often easily stolen, and just a BIOS lock isn't enough anymore, I've been aiming to migrate my Laptop and other portable equipment I use to an aggressively encrypted setup. While my company issued laptop is extensively encrypted and secured, I've been relatively lax with my personal equipment. I know of a number of cases of fraud, identity theft and attempts at them and with this kind of crime growing it's well worth keeping personal information safe from those with malicious intent.

While there may be install options with many distros to get this done, when migrating an existing system there is very little information on how to do it. To complicate matters, with the event driven boot of Ubuntu it doesn't have the simplicity of a serialized boot like Debian where migration to LUKS+LVM was little more than configuring a new volume in /etc/crypttab, adding it to the Volume Group and then running a pvmove, plus tidying up afterwards.

There seems to be very little documentation on how to get this working without a full reinstall, so here goes my attempt at it fixing that.... it's actually rather straight forward when you know how.

This process is not without risk and you need to make sure you fully understand the process and have backups that you have proven you can fully restore the system. Don't attempt this unless you fully understand what is required.

Also take the time to understand that encryption is not without it's drawbacks and can introduce additional risks.

Starting point

Fortunately I configure everything with LVM from the start, but for those who don't there's some extra work to get everything onto LVM first.

If you haven't already you will need to make /boot/ it's own small mountpoint (I make it 512M which copes with lots of kernel updates before I have to go tidy up old kernels), and of course migrate all the data on your various mountpoints onto logical volumes.

That's not what this article is about and I'm not going to explain the possible processes. If you don't have the skill make a plan and migrate the data safely to LVM then don't even think about the rest of this article is going to be appropriate either.

Potentially the migration can be done after configuring LVM over LUKS but if you choose that approach then you need to work out on your own how to do it appropriately for your setup.

I assume for this article that the situation is:

• Everything except /boot/ is already on LVM
• There is a sufficiently large partition of some sort to migrate the logical volumes to which is what we will be encrypting
• If you need to encrypt the source volume then you will have to do a ping-pong with the data, to temporary storage, then back to the encrypted storage. It's assumed that all logical volumes are on the temporary storage and that the partition / volume we want to encrypt is free and unused for this.

Preparing the encrypted volume

For this example we assume the partition you are using is /dev/sda2 - if not then substitute as necessary.

First up, make sure the partition we are going to use for encrypted data is completely unused and any data cleared. Depending on your level of paranoia, you could fill it with zeros or even random data to minimize the chance of anything being recovered:

# dd if=/dev/urandom of=/dev/sda2 bs=4k

First up we need to create the encrypted volume. This is easily done with the command:

# cryptsetup luksFormat /dev/sda2

Next, edit /etc/crypttab and add the line for the encrypted volume:

# <target name> <source device>         <key file>      <options>
crypt_sda2      /dev/sda2       none    luks

At this point it's a good idea to test the config by doing a reload with the init script:

/etc/init.d/cryptdisks reload
 * Stopping remaining crypto disks...
 * crypt_sda2 (stopped)...                                     [ OK ]
 * Starting remaining crypto disks...
 * crypt_sda2 (starting)..
Unlocking the disk /dev/sda2 (crypt_sda2)
Enter passphrase:
 * crypt_sda2 (started)...                                     [ OK ]

Now we should have the decrypted device available, in this case /dev/mapper/crypt_sda2

Adding to Volume Group

Next we add the encrypted volume into our Volume Group so that it can be used:

# pvcreate /dev/mapper/crypt_sda2
  Physical volume "/dev/mapper/crypt_sda2" successfully created
# vgextend vg00 /dev/mapper/crypt_sda2
  Volume group "vg00" successfully extended

... assuming your volume group is called vg00 - if not subsitute as neccessary.

Now, even though the data hasn't been moved onto the encrypted volume, having an encrypted volume as part of the volume group where the root volume resides is sufficient to get the system to prompt for the password at boot and test the setup before we move any data.

Preparing initramfs

The /boot/ volume/partition can't be encrypted as BIOS has to be able to read it in order to boot. Everything needed to decrypt the rest of the system at boot (except the key) will need to be stored in the initramfs in /boot/ but there's some configuration to make it all work first.

In order for Ubuntu (hence Mint) to boot off an encrypted device we have to update the initramfs with the encrypted setup in place. Ubuntu provides scripts /usr/share/initramfs-tools/scripts/local-top/cryptroot and /usr/share/initramfs-tools/hooks/cryptroot which take care of things so all that is needed is to run an update:

# update-initramfs -u

Testing

Reboot and you should find a password prompt appears at the bottom of the screen. Enter the password and the system should continue to boot. Once logged in you should find the volume we created earlier is there.

If any of this doesn't work then take whatever action necessary to fix it up.

Migrate the data

At this point everything is working and we can do a normal migration off our temporary storage (in this example /dev/sdb1) and onto the other physical volumes (in our case our encrypted volume) with something like:

# pvmove -v /dev/sdb1
.....

Then once that's done clear remove the temporary storage and tidy up:

# vgreduce vg00 /dev/sdb1
  Removed "/dev/sdb1" from volume group "vg00"
# pvremove /dev/sdb1
  Labels on physical volume "/dev/sdb1" successfully wiped

Final Test

Now the system should be running completely on the LUKS encrypted volume with LVM. It should be possible to reboot the system and come up on the new encrypted volumes.

Clean up

At this point it should be possible to remove the temporary storage (clear it down as needed for the security you require) and enjoy your encrypted system.

Removing ecryptfs

If you have been using ecryptfs then you probably don't want two layers of encryption. To remove the encryption from the home directory I did the following:

Login on a text terminal (not GUI) as the user in question - this mounts the ecryptfs filesystem, but with a plain shell minimizes the files being accessed.

Login on another terminal as root and then make a copy of the decrypted user directory:

# cd /home
# cp -a user/ user.decrypted

Then remove ecryptfs related symlinks from the copy:

# rm user.decrypted/.ecryptfs user.decrypted/.Private

Then logout of the user session - this unmounts the ecryptfs filesystem. Then in the root session shuffle round the directories:

# mv user user.old
# mv user.decrypted user

At this point you should be able to login again as the user and then run "mount" to check that the ecryptfs mount is no longer happening. If all is healthy (check carefully - you could easily loose your data here) then as root you can remove the old encrypted directories:

# rm -r user.old .ecryptfs/user

That will remove the old mountpoint for ecryptfs as well as the encrypted data that is in /home/.ecryptfs

If there are other users then the same can be done for them, otherwise you can remove the ecryptfs related packages (ecryptfs-utils and libecryptfs0) and remove the (empty) /home/.ecryptfs

Enhancements

This is a very basic setup and there are a number of variants that people have described that are worth knowing about, but not covered in detail here.

External /boot/

As the /boot/ partition has to be unencrypted in this case, on option is to have an external device (say USB flash) which can be physically removed to reduce the risk of attack on /boot/

External key

Another common approach is to use an external device (say USB flash) containing the key to unlock the device. This avoids the need to type passwords, and again can be physically removed.

Two-factor

One approach I read about describes using both an external device (say USB flash) to store a gpg encrypted key which means that not the external device and a password are required to unlock it.

One key/passphrase, multiple devices

While this isn't really needed for most laptops unless you have a complex partitioning scheme, I've recently taken to encrypting my SSDs after I had one fail - almost all the data is probably intact in the Flash, but the controller is in a real twist and won't let me access it or erase it before disposal. By encrypting the data I just chuck them when the die without worrying about some fraudster fishing it out of the tip.

The problem of decrypting multiple devices at boot seems to come up all the time on forums, and the solutions proposed are often at best poor, sometimes dangerous. The thing that is missing solid documentation in one location. The tools for doing this already exist on Debian (and Debian-derived systems: Ubuntu, Mint etc.)

The main keyscripts to look out for are:

decrypt_keyctl

This simply uses "keyctl" to cache the passwords entered. That means you enter one, use it multiple times. The "key file" (third column) in cryptab is the identifier used for caching, so for 4 devices, two passwords it may look like this:

# <target name> <source device>         <key file>      <options>
crypt_sda1      /dev/sda1       passgroup1    luks,keyscript=/lib/cryptsetup/scripts/decrypt_keyctl
crypt_sdb1      /dev/sdb1       passgroup1    luks,keyscript=/lib/cryptsetup/scripts/decrypt_keyctl
crypt_sdc1      /dev/sdc1       passgroup2    luks,keyscript=/lib/cryptsetup/scripts/decrypt_keyctl
crypt_sdd1      /dev/sdd1       passgroup2    luks,keyscript=/lib/cryptsetup/scripts/decrypt_keyctl

In this case it will prompt twice for passwords: once for "passgroup1" and once for "passgroup2"

decrypt_derived

This one derives a hash from the key used for an already unlocked device. That means you can unlock one device, then use the hash from that device to unlock the remaining devices. It does mean that you first need to set the derived hash as the key for the devices you want to unlock like this:

# cryptsetup luksOpen /dev/sda1 crypt_sda1
Enter passphrase for /dev/sda1:
# /lib/cryptsetup/scripts/decrypt_derived crypt_sda1 | cryptsetup luksFormat /dev/sdb1
# /lib/cryptsetup/scripts/decrypt_derived crypt_sda1 | cryptsetup luksFormat /dev/sdc1

Then in cryptab you can do something like:

# <target name> <source device>         <key file>      <options>
crypt_sda1      /dev/sda1       none    luks
crypt_sdb1      /dev/sdb1       crypt_sda1    luks,keyscript=/lib/cryptsetup/scripts/decrypt_derived
crypt_sdc1      /dev/sdc1       crypt_sda1    luks,keyscript=/lib/cryptsetup/scripts/decrypt_derived

This will unlock subsequent devices from the hash derived from crypt_sda1.

This is not without it's risks:

• An attacker with root access could run decrypt_derive to get a usable key... though keep in mind with root access they would already have access to all decrypted data
• If any harm comes to the header on the device you are driving from, a valid hash may not be produced and thus access to subsequent devices is lost. This can be avoided by adding an additional "backup key" to these devices which can be used manually in an emergency

passdev

This allows keys to be stored on removable storage (eg. USB Flash) which is used as a physical "key" to unlock volumes at boot.

The first thing to work out is a reliable way of identifying the device. It's bset to use one of the paths under /dev/disk/by-* so it's always in the same location. Also, choose a simple reliable filesystem. Personally ext2 or ext3 would be my preferences, but beware of FAT filesystems as there may be additional modules needed (eg. codepages) which are not present at boot. I prefer to go on filesystem label, that way I can have multiple "backup" devices with the same label and all will work.

Create a file containing the "key" you want to use on this filesystem. There are many ways of generating suitable non-deterministic keys. For this example let's say the key is in machine1/alldisks.key and the filesystem label is "lukskeys" then then mount the device and prepare the encrypted devices:

# cryptsetup luksFormat /dev/sda1 /path/to/lukskeys/machine1/alldisks.key
# cryptsetup luksFormat /dev/sdb1 /path/to/lukskeys/machine1/alldisks.key

... or if you want to just add keys to existing devices:

# cryptsetup luksAddKey /dev/sda1 /path/to/lukskeys/machine1/alldisks.key
# cryptsetup luksAddKey /dev/sdb1 /path/to/lukskeys/machine1/alldisks.key

Then your crypttab may look something like:

# <target name> <source device>         <key file>      <options>
crypt_sda1      /dev/sda1       /dev/disk/by-label/lukskeys:/machine1/alldisks.key    luks,keyscript=/lib/cryptsetup/scripts/passdev
crypt_sdb1      /dev/sdb1       /dev/disk/by-label/lukskeys:/machine1/alldisks.key    luks,keyscript=/lib/cryptsetup/scripts/passdev

This will wait for a device matching the label "lukskeys", mount it read-only and key the devices from the file on there "machine1/alldisks.key"

Again, this is not without it's risks:

• Loss or damage to device storing the keys may render the data inaccessible. This is easily solved with backup copies of keys, or adding some "backup keys" to encrypted devices that can be used in an emergency
• If there is unauthorized access to device holding the keys then it's easy to copy the key files and use them at a later date

Understanding the Risks

The aim of all this is to make life harder for the many people who want access to your data for malicious intent while ensuring legitimate people have access. There is invariable compromises to be made.

Some of the things to consider:

Data loss

With an unencrypted filesystem, if there is some damage/corruption often at least partial recovery of data is still possible. With encryption the risk is far higher and if the data needed to decrypt the filesystem is corrupted then the entire filesystem may be inaccessible.

With encryption, minor corruption can have a major effect.

Backup strategies

The above calls for good backup strategies, however, beware of image based backups of the encrypted volume since the same failures may apply.

Consider carefully the scenarios you may need to recover from and what you will need to have in place to do that.

Also, always run drills of recovery and ensure that you can actually recover. It's surprising how often seemingly trivial things may result in difficulty or even completely prevent restoring the system.

Performance

While it doesn't affect latency significantly (that's normally dominated by disk seek time and rotational latency), there is a CPU overhead with encryption. If you shift large amounts of data, there could be significant performance degradation depending on your particular system and where the bottlenecks are.

Passphrase vulnerability

This setup is not completely secure, nor is any other, though for my purposes it achieves the goal of rendering any data on my laptop unreadable should it be stolen.

The strength of the encryption deepens a whole lot on the quality of the passphrase. If a weak passphrase is used then the volume could be unlocked with a brute-force attack.

Keylogging

When it comes to protecting data, it's trivial to install some form of keylogging device between the keyboard and system. This isn't an opportunistic attack, but when someone is determined enough and plans, there are means to achieve this.

initramfs attacks

This encryption approach depends on the integrity of initramfs, which is not encrypted and hence could be tampered with. This is the same for many other software based encryption tools which depend on the integrity of boot-time software.

Hardware attacks

Where hardware approaches (eg. the infamous "TPM") are deployed to ensure the integrity, hardware attacks are also possible. These have been going on for a long time on an amateur level with games consoles, so anyone determined enough is still going to have options.

Lots more...

Protecting data is an arms race - all the time better ways of protecting data and defeating those mechanisms are being developed.

Personally, my aim is simply to avoid all the "regular" information related fraud. When things get more serious there are very real limits:

from: XKCD