« A Helping Hand | Main | Swap Happy NICs on FC5 »
July 7, 2006
Encrypting Partitions on a Fedora Core Notebook
(Ed. I originally wrote this in August of 2005, but never published it, planning on reworking it to use dm-crypt instead. Unfortunately, with all the traveling and other things keeping me busy here at Guru Labs, I've still not gotten around to it, so, I decided to publish this version as is. I should have the dm-crypt version written as a new Guru Guide, soon.
Working for Guru Labs, I travel many tens of thousands of miles per year. I go through airports and fly all over North America. In all this traveling, I have never had to deal with the loss or theft of a notebook computer. Hopefully, my luck will hold for many years (decades?) to come.
Of course, I'm not going to just say, "Well, I'll never have to worry about that!," and call it "security". I have data on my notebook that I would not want to lose. If my notebook was lost or stolen, I have all that data on other system and could reconstruct it (well, almost all that data).
However, some of it should never be allowed to fall into the "wrong" hands, either. Encryption is a good answer to this problem.
There are several different ways that one could use encryption to protect files on a system. Individual files could be encrypted and decrypted, as needed. This approach, while relatively simple to implement, is rather tedious for the user and error-prone; important files must be re-encrypted after each use in order to ensure they remain protected.
A better approach is to have the filesystem encrypt individual files, transparently. A user would "mark" those files that should be encrypted and the filesystem would provide transparent access. This approach would be ideal for many reasons, including the fact that only the important data is being encrypted, therefore minimizing the load on the system required to deal with encryption. Unfortunately, this approach also requires filesystem support, which is not very common. Also, other tools like standard file open/save dialog boxes would have to be altered to support this capability so users could (un)mark files for encryption.
The approach I have taken is to create a special, encrypted partition and place a filesystem on top of that. The Linux kernel has supported encrypted filesystems through a mechanism called cryptoloop for many years now. However, cryptoloop is deprecated and will be removed at some future point (of course, we've know this for quite some time and cryptoloop is still around, so it may or may not be a while before it is removed). The replacement is called dm-crypt, which is a devmapper module.
Before I get into how to add support for boot-time cryptoloop mounting to Fedora Core, it is important to note that there are some weaknesses in cryptoloop. These weaknesses are not in the encryption algorithms used. As far as I am aware, they have not lead to any exploits which could compromise the encrypted data. However, one should not trust classified data to cryptoloop.
First, you will need to create a cryptoloop encrypted filesystem. This is done using the losetup command (see losetup(8) for full details). Before losetup can be used to create an encrypted filesystem, you will need to load a couple of kernel modules:
# modprobe cryptoloop # modprobe aes
After these modules are loaded, use losetup to create an encrypted partition (note, in this example, I am using an LVM logical volume; you can use any block device you like):
# losetup -e aes /dev/loop0 /dev/vg0/secure Password: Enter a passphrase here
Of course, I do not want you to tell me what passphrase you use. More importantly, it is recommended that your passphrase be at least 20 characters long. Cryptographically strong passwords are always a good idea.
Now you have a loopback device (/dev/loop0, in this example) that is encrypted on disk. The cryptoloop driver presents a standard block device on the loopX device node. This device can be formated and mounted just like any other block device:
# mkreiserfs /dev/loop0
mkreiserfs 3.6.13 (2003 www.namesys.com)
. . . snip . . .
ATTENTION: YOU SHOULD REBOOT AFTER FDISK!
ALL DATA WILL BE LOST ON '/dev/loop0'!
Continue (y/n):y
The encrypted filesystem is ready to use. Simply mount and use the new filesystem (create the mountpoint with the mkdir command first, as needed):
# mkdir /secure # mount /dev/loop0 /secure/
After you have copied/moved some data over to your new encrypted filesystem, unmount it and remove the cryptoloop device, thus "locking" the partition:
# umount /secure/ # losetup -d /dev/loop0
Until you run the losetup command, the partition will be available for mounting without having to enter the passphrase.
To mount existing encrypted partitions, simply run losetup to setup the loop device and mount it:
# losetup -e aes /dev/loop0 /dev/vg0/secure Password: Enter the correct passphrase here # mount /dev/loop0 /secure/
(NOTE: If the mount command fails, it is usually due to a mistyped passphrase; run losetup -d /dev/loop0 to delete the device and try again, in that case.)
It is not necessary to run these commands when shutting down the system, as the normal system shutdown process will take care of umount'ing the partition and the reboot (or system halt) itself will close the cryptoloop device.
"OK. So now I have this encrypted partition and I know these commands to run to manually mount it, but I want this thing to be taken care of when I boot my notebook." Well, I'm glad you mentioned that; here is how I solved that problem:
First, I edited /etc/rc.sysinit and made this addition (in bold, the rest is for context and the line numbers are for the version of this file on FC4 for x86):
483 # Mount all other filesystems (except for NFS and /proc, which is already 484 # mounted). Contrary to standard usage, 485 # filesystems are NOT unmounted in single user mode. 486 action $"Mounting local filesystems: " mount -a -t nonfs,nfs4,smbfs,ncpfs,cifs,gfs -O no_netdev 487 488 # Mount cryptoloop filesystems 489 if [ -r /etc/cryptotab ]; then 490 action $"Mounting encrypted filesystems: " /sbin/cryptomount 491 fi 492 493 if [ -x /sbin/quotaon ]; then 494 action $"Enabling local filesystem quotas: " /sbin/quotaon -aug 495 fi 496 497 # Check to see if a full relabel is needed
Next, I created the /sbin/cryptomount script, which can be downloaded from the Guru Labs Downloads page. I wrote that script, basing it on the one shipped by SUSE with their distributions (which have supported encrypted filesystems out of the box for years).
The last thing to do is to create the /etc/cryptotab file. In this file, each line describes one encrypted filesystem that should be mounted when the cryptomount command is run. The format of this file is (which is identical to that used by SUSE's built in encrypted filesystem support):
# Loop device Physical device Mountpoint fs-type Algorithm fs-options /dev/loop0 /dev/vg0/secure /secure reiserfs aes defaults
That's it. With these changes, the system will prompt for the passphrase for each encrypted filesystem described in your /etc/cryptoloop file during bootup.
Note: It looks like at least SUSE Linux 10.1 (and probably OpenSUSE 10.0) have switched to using dm-crypt in a way that is now slightly incompatible with the technique described here. (Ed. They are actually using cryptoloop still, but don't load the aes kernel module which is why the SUSE 10.1 tools can't just setup access to the cryptoloop encrypted filesystem on my notebook, which was created for Fedora using the technique found here.)
Posted by lamontp at July 7, 2006 11:45 AM
Trackback Pings
TrackBack URL for this entry:
http://blogs.gurulabs.com/cgi-bin/mt-tb.cgi/53
Comments
Posted by: Richard Keech at July 10, 2006 11:11 PM
Isn't cryptoloop mostly deprecated in favor of DM-Crypt anyway?
Posted by: Ben at August 2, 2006 11:42 AM
Yes, cryptoloop is on it's way out. It will probably be a long time before it is removed from the vanilla kernels.
Also, it is still in use in many distributions. Just the other day I was looking at what the latest SUSE releases do when their tools create encrypted filesystems. They are still using cryptoloop, with 256-bit twofish (though that's configurable).
As I said in the editorial notes in the post, I decided to post this version with cryptoloop so that there would be something useful and useable available. I will be posting a dm-crypt rewrite once I get it done.
Posted by: Lamont R. Peterson at August 2, 2006 12:46 PM