Saturday, May 1, 2010

Encrypting Partitions on GNU/Linux


Encrypting partitions helps protect against unauthorized access to data in the event the computer hardware is physically lost or stolen. The technique described here relies on the ability of the Linux kernel to:
  1. Create an a map of a real device or a logical volume.
  2. Create an encrypted block device
It is recommended that all partitions with sensitive files be encrypted. Furthermore, to prevent retrieval of information from pages of memory swapped out to disk, it is recommended that the swap partition either be encrypted, or if swapping is to a file, then that file reside on an encrypted partition.1

Although it is possible to encrypt the root (/) partition, I don't see the value in it for most situations, since data to be encrypted would usually reside elsewhere (under /home and /var, for example) and the root file system would normally contain just a Linux distribution.

Nota bene

  1. Encrypting partitions does not help protect a PC during normal operation. This is because an encrypted partition must be mounted and accessible during normal operation. Ergo, an intruder who gains access to a system that is in use will find encrypted partitions mounted and accessible.2 
  2. Encryption keys for partitions tend to be long lived (the duration of the partition). They need to be appropriately safeguarded.
  3. With the technique described here, no keys reside on a PC when it is powered down. So, manual input is required.
  4. Pay attention to directories where temporary files reside. If these are not in encrypted partitions, rebooting with a Linux live CD will provide access to the files and their contents.
  5. Except for a brute force attack on the key, I know of no way to recover data from an encrypted partition.
  6. If you lose a computer, and find it again, you must assume that it has been compromised (e.g., someone may have installed a rootkit and be waiting for you to use it). Either validate all unencrypted partitions, or do a fresh operating system install before mounting any encrypted partitions.
  7. Caveat: I am neither a computer security guru nor a cryptology guru. Use my instructions and follow my advice at your own peril. While devout prayer and crossed fingers may augment my advice, following the advice of someone who knows what he is talking about may be even better.

Nuts and Bolts

Read the entire document. understand what you need to do and write down a plan of action before taking the first step. Of course you will not make a mistake, but everything else in this universe is imperfect.

Encrypting a partition

Before you encrypt a partition, take a backup of its contents.3 The process of encryption destroys the data so you will need to restore the files to the encrypted partition when you are done.
  • All commands here are run as root, either with a root shell or via sudo. This write-up assumes that /dev/sda2 is to be encrypted and mounted as /home. Adapt these instructions to suit your specific needs.
  • The dmsetup and cryptsetup packages are required (this applies to Debian family Linux distributions; there should be equivalent packages for distributions that use other package management systems).
  • For the initial (one-of) creation of an encrypted file system, the device must first be unmounted, e.g., to unmount /dev/sda2 which is currently mounted unencrypted at /home:
umount /dev/sda2 or umount /home
  • Create a mapped encrypted version of the device (-y tells cryptsetup to verify the passphrase):
cryptsetup -c aes -s 256 -y create sda2-aes /dev/sda2
  • I am of course paranoid, but not so paranoid as to perform this optional step: write random data to the physical partition (by writing zeros to the encrypted partition). This ensures that no data from prior to encryption will remain on the disk post encryption:
dd if=/dev/zero count=xxxx of=/dev/mapper/sda2-aes
(You will need to determine the count, in 512 byte blocks, to be passed to dd to write over the partition.)
  • Create a file system in the mapped device (while jfs is my preferred file system, the choice is yours - some Linux distributions require a package such as jfsutils to be installed to use jfs):
mkfs -t jfs /dev/mapper/sda2-aes
Replace jfs with your preferred type of file system. ext3 is the most widely used file system on Linux. xfs and reiserfs are other not-uncommon alternatives. (I personally use jfs, but have PCs running ext3 and reiserfs. All four work with GT.M although ext3 is what is officially supported.)
  • Create a script such as the one below. The output of each command is logged to a file in /tmp whose name is a time stamp (those date +%Y%m%d%H%M%S commands provide the time stamps).
gtmuser@gglaptop:~$ cat /usr/local/bin/mounthome
# Get password and mount /home
umount /home >&/tmp/umounthome_$$_`date +%Y%m%d%H%M%S`.log
cryptsetup remove sda2-aes >&/tmp/cryptsetupremove_$$_`date +%Y%m%d%H%M%S`.log
cryptsetup -c aes -s 256 create sda2-aes /dev/sda2 2>/tmp/cryptsetup_$$_`date +%Y%m%d%H%M%S`.log
fsck -a -t jfs /dev/mapper/sda2-aes | tee /tmp/fsck_$$_`date +%Y%m%d%H%M%S`.log
mount -o relatime /dev/mapper/sda2-aes /home >&/tmp/mount_$$_`date +%Y%m%d%H%M%S`.log
    • The umount command unmounts the partition if it is already mounted, and the cryptsetup remove command removes the mapping of the encrypted partition to the device. If the partition is not mounted or encrypted, these commands are no-ops. Doing it this way permits the script to be run repeatedly.
    • The cryptsetup create command creates /dev/mapper/sda2-aes as a 256-bit AES encrypted map of /dev/sda2, prompting the user for the password.
    • The fsck command performs an automatic check and repair of the partition (in case the system is coming up after a hard crash / power-down). If the system was shut down cleanly, it is a no-op.
    • The mount command mounts /dev/mapper/sda2-aes as /home, making it available to the system.
    • If you have multiple partitions with the same encryption key, use the shell to prompt the user for the key and provide it to cryptsetup.
Don't worry about the partition getting scrambled if someone inadvertently enters the wrong key – if it doesn't look like a properly formatted partition, the mount command will fail to mount it and you can just run the script again.
  • Edit /etc/fstab, which specifies which partitions the system should mount, and delete or comment out the line that tells Linux to mount /dev/sda2 as /home. Henceforth, you will need to explicitly mount it when you boot.  You will need to login as root to mount the partition - depending on your login manager, you may need to switch to an alternate text console (e.g., using Ctrl-Alt-F2) to login as root and run mounthome, or
  • Verify that the encryption is working (go through a few boot up and shut down cycles, verify recovery from a forced power-down and satisfy yourself that entering an incorrect password doesn't damage the file system). Then restore the previously backed up data.

Encrypting a swap partition

The simplest way to encrypt a swap partition is to create a swap file on an encrypted partition.  For example, after creating and mounting an encrypted /home, you can create a swap file with commands executed as root such as (in this example, the swap file is 4GB; the dd step ensures that lazy allocation is not used to allocate space for the swap file):

dd if=/dev/zero of=/home/swap bs=1048576 count=4096
mkswap /home/swap

Then append a line swapon /home/swap to the /usr/local/bin/mounthome script described above.

Parting Thoughts

  1. For convenience, instead of entering a key, you can store it on a USB flash drive (back it up!). Boot with the drive plugged in and have the system read the password from the flash drive. Then remove the flash drive to ensure that someone who steals the PC doesn't also steal the flash drive.
  2. You must ensure that enough functionality is available to a system when it boots so that you are able to run the script(s) to mount. So, if you are encrypting /home, you would need to login as a user whose home directory is not under /home (e.g., user root, or a specially created user) to run the script to mount the encrypted partition. Encrypting a /var partition is probably impractical because of files such as /var/log/messages (so if you have application directories under /var, you may need to mount them in a seprate encrypted partition).
  3. Have fun. As long as you take a backup of the partition you plan to encrypt, as well as /etc/fstab before you start playing, the commands described here are reasonably foolproof and unlikely to destroy your system.
  4. Fools can be very ingenious.

1 Note that encrypting a swap partition or a swap file effectively disables the Hibernate function. The operation of Suspend is not affected.

2 A corollary of this is to require password protected screen savers that come on automatically after a brief period of inactivity. Thus, a thief who appropriates an appropriately protected inactive laptop would not be able to access the files when the laptop is on, and would also not be able to access the files after it is powered down.  If you carry a Bluetooth enabled device on your person, you can also use software such as BlueProximity to automatically lock the screen when you step away.

3 If there is existing sensitive data on the partition, and the backup is to the same computer system - e.g., to /var/tmp - you should encrypt the backup.

No comments:

Post a Comment