But that convenient small size also means it's easy to lose your USB key, or leave it somewhere. Someone could pick it up and have access to anything you put there. Wouldn't it be nice to encrypt it?
There are lots of howtos on the net, like this and this, but most of them are out of date and need a bit of fiddling to get working. So here's one that works on Ubuntu hardy and a 2.6.28 kernel. I'll assume that the drive is on /dev/sdb.
First, consider making two partitions on the flash drive. The first partition is a normal unencrypted vfat partition, so you can use it to transfer files to other machines, even Windows and Mac. The second partition will be your encrypted file system. Use fdisk, gparted or your favorite partitioning tool to make the partitions, then create a filesystem on the first:
Update: On many distros you'll probably need to load the "cryptoloop" module before proceeding with the following steps. Mount it like this (as root):
Easy, moderate security version
Now create the encrypted partition (you'll need to be root). I'll start with a relatively low security version -- good enough to keep out most casual snoops who happen to pick up your flash drive.
losetup -e aes /dev/loop0 /dev/sdb2 [type a password or pass phrase] mkfs.ext2 /dev/loop0 losetup -d /dev/loop0
I used ext2 as the filesystem type. I want a Linux filesystem, not a Windows one, so I can store dot-filenames like .gnupg/ and so I can make symbolic links. I chose ext2 rather than a journalled filesystem like ext3 because of kernel configuration warnings: to get encrypted mounts working I had to enable loopback and cryptoloop support under drivers/block devices, and the cryptoloop help says:
WARNING: This device is not safe for journaled file systems like ext3 or Reiserfs. Please use the Device Mapper crypto module instead, which can be configured to be on-disk compatible with the cryptoloop device.I hunted around a bit for this "device mapper crypto module" and couldn't figure out where or what it was (I wish kernel help files would give either the path to the option, or the CONFIG_ name in .config!) so I decided I'd better stick with non-journalled filesystems for the time being.
Now the filesystem is ready to use. Mount it with:
mount -o loop,encryption=aes /dev/sdb2 /mnt [type your password/phrase]
Higher security version
There are several ways you can increase security. Of course, you can choose other encryption algorithms than aes -- that choice is up to you.
You can also use a random key, rather than a password you type in. Save the random key to a file on your system (obviously, you'll want to back that up somewhere else). This has both advantages and disadvantages: anyone who has access to your computer has the key and can read your encrypted disk, but on the other hand, someone who finds your flash drive somewhere will be very, very unlikely to be able to use it. Set up a random key like this:
dd if=/dev/random > /etc/loop.key bs=1 count=60 mkfs.ext2 /dev/loop0 losetup -e aes -p 0 /dev/loop0 /dev/sdb2 < /etc/loop.key(of course, you can make it quite a bit longer than 60 bytes).
(Update: skipped mkfs.ext2 step originally.)
Then mount it with:
cat /etc/loop.key | mount -p0 -o loop,encryption=aes /dev/sdb2 /crypt
Finally, most file systems write predictable data, like superblock
backups, at predictable places. This can make it easier for someone to
break your encryption. In theory, you can foil this by specifying
an offset so those locations are no longer so predictable.
-o 123456 (of course, use your own offset, not that
one) to the
losetup line, and
in the options of the
In practice, though, offset doesn't work for me: I get
ioctl: LOOP_SET_STATUS: Invalid argumentwhenever I try to specify an offset. I haven't pursued it; I'm not trying to hide state secrets, so I'm more worried about putting off casual snoops and data thieves.
[ 15:10 Mar 08, 2009 More tech/security | permalink to this entry | comments ]