I’ve gotten around to migrating my backup partition to a Truecrypt encrypted partition. This partition, /dev/sda2, was an ext3 partition I’ve been using for backups. I have an external backup drive (also encrypted) that I keep off-site and so didn’t worry about destroying the backup data on the partition.

Knowing a little something about computer forensics, I wanted to ensure that data I had written prior to encrypting the partition would be unrecoverable. If I had wanted to erase the entire drive I would have used Darik’s Boot and Nuke or some other linux-based drive eraser conforming at least to the DoD specification for file wiping. It’s important to remember, though, that wiping only files likely leaves data remnants in the empty drive space, file slack space, and sectors marked as bad. So, clearly it’s important to erase the entire partition or drive, not only files.

I wanted to only erase a partition so I used a more configurable utility to overwrite the space within the partition. First I rm -rf’d the files and directories on the partition. Then I overwrote the available space in the partition with random data using dd and /dev/urandom. sudo dd if=/dev/urandom of=/mnt/back/bigfile I probably should have just overwritten the partition at the device level, but I didn’t think of it until later. Next I used wipe to remove the bigfile. Only then did it occur to me that I could call wipe against the block device itself. sudo wipe -Q 1 -R /dev/urandom /dev/sda2

Hoping that the drive was sufficiently overwritten with random data I created a Truecrypt container on the partition. I chose to use the ext3 file system so chose the ‘no filesystem’ option in Truecrypt. After creating the container, I mounted the container. sudo truecrypt /dev/sda2 Then, I created the filesystem. sudo mkfs.ext3 -cjv /dev/mapper/truecrypt0

Now I have an encrypted backup partition on a separate internal hard drive completely independent of the LVM/dm-crypt encrypted system. I have a script that calls rsync against my /home, /etc, and /usr/local directories, which is everything I need to rebuild a system.

To those who would suggest that only people with something to hide should be concerned with privacy, I urge you to read ‘I’ve Got Nothing to Hide’ and Other Misunderstandings of Privacy.

I’ve been experimenting with drive encryption in Ubuntu 7.10 and am quite pleased. I used the AMD64 Alternate Install disk to encrypt everything but an ext3 boot partition. Ubuntu uses LVM to build logical partitions inside a dm-crypt partition. Installation was a snap, though it takes much longer than an unencrypted install mostly due to the drive wiping process. I assume it uses /dev/urandom to generate random data to overwrite drive space, but could be wrong. I’d probably use a trusted wiping utility if I didn’t need to preserve other partitions on the drive.

The installer offers several encryption algorithms, such as AES with, and several key sizes, up to 256 bit, but doesn’t offer cascading encryption algorithms, which I imagine would impact read/write speed. I don’t have any previous experience with LVM or dm-crypt, but have used cryptoloop under Suse 9.x with ReiserFS and lost a fair amount of data to it no thanks to personal support from Hans. I formatted all of the LVM volumes with ext3 and decided it prudent to have a backup plan independent of dm-crypt and LVM. I have a partition encrypted with Truecrypt on another internal drive to which I backup in addition to a Truecrypt-encrypted firewire drive I keep off-site and refresh periodically. I have confidence that if either LVM or dm-crypt fails and I lose access to the encrypted system, I can recover my data from the backup partition on the other internal hard drive or, if some greater calamity occurs, I will be able to access my off-site firewire backup.

Other than the dm-crypt password prompt when booting and the mildly confusing entries in /etc/fstab, I don’t notice any difference from the uncrypted installation I used previously. I’ve included a drive map below to show the partition layout. Installation into available space while maintaining both my Windows XP and Thinkpad recovery partition was straightforward. The Windows partition is unprotected, but I can’t remember the last time I used it and certainly wouldn’t trust it with anything important anyway.

One question I had and was unable to find and answer to was this: Does suspend to ram work with encrypted drives? I suspected it wouldn’t since the swap space is encrypted, but was pleasantly surprised to find I was wrong. I can suspend and recover successfully. I realize now that the dm-crypt partition stays mounted through the suspend which means that while I can have quicker recovery times, the data isn’t protected. Hibernate requires a dm-crypt password on recovery. In my mind, though, the benefit of drive encryption is two-fold. First, you’re protecting the data, both the data you intentionally have and the remains of data left in empty drive space and file slack space after deletion, from boot-time attacks. Everyone knows that physical access to a machine is the kiss of death. Second, you’re protecting against third-party forensics. Both of these scenarios require the machine to be shut down. When the machine is shut down, the dm-crypt session is lost and your data is again protected. So, unless there is a flaw in the session authentication mechanisms (pam, xscreensaver, GDM, etc), and there might well be, it seems safe.

Anyway, I’m very satisfied with the installation process and the encrypted system.

The drive map shows that the dm-crypt partition is unrecognized. Also, each LVM volume is recognized as a separate drive.