Disk encryption

by Neil Rickert

[See my crypto page for links to updated and newer information]

When installing opensuse 11.4, last March (2011), I decided to go with disk encryption (really, disk partition encryption).  I have since done some experimentation with different ways of handling that.  This post is for those readers who want to try something similar and are interested in a report on how it went.

A quick warning:  as far as I know, linux does not provide a way of “encrypting on the fly”.  If you switch to an encrypted partition, you will finish up with an empty partition.  So do a good backup first, so that you can later restore the content from that backup.

Why encrypt?

Obviously, we encrypt to protect data.  In my case, the amount of sensitive data is minor, and most of it is already in encrypted files.  It consists of website passwords, software activation keys, and similar kinds of data.  I allow firefox to handle website passwords, but keep them encrypted.  For other data and for the few user-unfriendly websites that insist firefox not keep their passwords, I have them in an encrypted file.

I haven’t bothered with an encrypted disk until now, because it didn’t seem worth the effort and my use of encrypted files gave reasonable protection.  However, disk encryption has become easier.  With the sensitive data in encrypted files, there are times when it has to be unencrypted (for editing or for reading).  And there is the risk that some data will be left lying around from that.  So disk partition encryption is a protection against that possibility.

Note that when the operating system is up and running, the data is all visible.  The protection provided by the encryption only applies when the computer is not up and running.  It protects against a stolen laptop, or against somebody finding an older discarded disk (dumpster diving) and recovering data from that.

Encrypting “/home” and “swap”

I quickly decided that encrypting “/home” and swap should be sufficient for most of my needs.  I could arrange that “/tmp” be mounted from swap, so temporary data would also be protected.  I looked at “/var/tmp”, another place where temporary data is sometimes kept, and it looked as if nothing sensitive was being stored there.  But note that you might be using applications that do store data there, so don’t take my word for it.

Once I had decided what to encrypt, it was relatively easy.  I was installing a new version anyway, and had already backed up “/home”.  In the partitioning screens of the installer, all I had to do was check the “encrypt” option for both the “swap” and the “/home” partitions, and to also check the “format” option.  In each case, I was prompted for an encryption key.  The trick with “swap” is to leave the encryption key empty.  The installer then uses a random key, and reformats “swap” at every boot (using a new random encryption key).  For “/home” you will need to provide a key, for otherwise you won’t be able retain data between boots.

Apart from that one step, the install was much like any install.

After completing the install, I logged in as root at a command prompt.  It is probably best to use a “failsafe” boot for this, so that the GUI is not started.  I then took the following steps:

  • Make sure that the uid for the user is the same as previously (and as on the backup).  I did this with “vipw” to edit the passwd file.
  • Remove anything added to “/home” by the install (or rename to a non-conflicting name).
  • Restore “/home” from the backup that I had made.

Next is to mount “/tmp” from swap.

Add a line to “/etc/fstab”:

none    /tmp    tmpfs   defaults        1 2

That line will mount “/tmp” from swap.

If you did this with a failsafe boot, then:

cd /tmp
rm -rf * .??*

to delete anything in the old “/tmp” before the new one is mounted.

After a reboot, everything should be working as desired.

Disadvantages to encryption

At each boot, you will have to enter the key for “/home”.

Recovery from hibernation won’t be possible, because of the random encryption of swap.

Care and feeding of the beast

The system setup that I have described is relatively simple to manage.  If you want to backup the “/home” partition, then login as root at a command prompt, and backup from there.  You could boot to a failsafe session for this, or just use CTRL-ALT-F1 to get a login prompt.  If no ordinary user is logged in, then the “/home” partition won’t be changing so you should be able to backup without problems.  Because you have booted, you will be seeing unencrypted date for “/home”.

To solve boot problems, or other system rescue problems, you can normally do this as before.  You typically don’t need to access the “/home” partition for this, and the root partition is not encrypted so easy to repair.

If you do need to access “/home”, that is still possible.  Your rescue CD probably has the encryption tools available for you.  I normally use the “Parted Magic” cd for this.  Assuming that “/home” is “/dev/sda6”, you could use:

cryptsetup luksOpen /dev/sda6  home
mount /dev/mapper/home /mnt

Encrypting only “swap

For my office desktop computer, I chose to only encrypt “swap”.  The protection is not a complete.  However, I rarely edit an encrypted file on my office system.  Should I need to do that, I would have to make sure that I keep the unencryted copy only in “/tmp”.

The main advantage, is that the system can boot unattended (does not require an encryption key to boot).  The main risk is that if I am viewing encrypted data (the unencrypted copy in “/tmp”, and I use copy/paste, that data gets to the clipboard and if the desktop GUI software maintains clipboard history, there will be an unencrypted copy of that clipboard saved somewhere in the unencrypted “/home” partition.  I disable “klipper” (the clipboard software for KDE) to prevent that.

Encrypting everything

On one test machine, I decided to encrypt everything – well, almost everything.  It needs a separate unencrypted “/boot”.  To prepare, I created one large partition for linux, in addition to the “/boot”.  During install, I selected the partitioning option to use an LVM based system.  I used my large partition as the base disk space for LVM (logical volume management).  Apparently, the LVM support in the opensuse installer is relatively new.  Once having chosen an LVM based setup, I selected the option for the LVM space to be encrypted and I provided the encryption key as prompted.

The setup went pretty smoothly from that point on.  It is my impression that booting takes a bit longer, due to the LVM setup that is needed.  However, swap is encrypted (as part of the logical volume), yet recovery from hibernation should work (not tested).

If you need to do system repairs, that will be a bit more complex.  This is what works for me, booted from the parted magic CD:

cryptsetup luksOpen /dev/sda6 lvmsys
vgscan        ## scan for volume groups
vgchange -a y ## activates the volume groups
ls /dev/mapper  ## see what the names are
mount /dev/mapper/system-root /mnt
mount /dev/mapper/system-home /mnt/home

At this point, everything (except swap) is mounted under “/mnt”.  I can now do repairs, make backups, etc, as needed.

If anything was changed, it is best to properly unmount

umount /mnt/home
umount /mnt
vgchange -a n
cryptsetup luksClose lvmsys

Overall, with LVM, repairs and other maintenance will be harder.  However, everything except “/boot” is encrypted.

Encryption overhead/cost

There is some overhead involved in encryption.  Every disk sector is decrypted as read from the physical disk, and encrypted when written to the physical disk.  In my experience, the overhead seems to be rather small.

Advertisements

9 Responses to “Disk encryption”

  1. This comment provides a link to a howto for rebooting an encrypted system over the network.

    The basic idea is to use a modified “initrd” that starts the network and runs an ssh server to allow supplying the encryption key over ssh.

    Like

Trackbacks

%d bloggers like this: