#!*A5%amp;j9 – How to Encrypt Your File System

Encrypting Block Devices

The second approach mentioned in this article is encrypting block devices. This includes encrypting entire disks or disk partitions. This approach has some appeal because you don’t have to worry about making sure the file system you are using is in fact encrypted. Since the block device is encrypted you can just use your /home directory as easily as you do today. Or you can go another step and combine an encrypted block device with an encrypted file system to get even more defense (but at the expense of performance).

Truecrypt

Truecrypt is a freely available disk encryption package that is multi-platform. It is available for Windows Vista, Windows XP, Mac OS X, and Linux (using FUSE). Currently, it has several encryption algorithms: AES-256, Serpent, and Twofish. It has two main modes of functioning: (1) It can create a virtual encrypted disk within a file system and mount it as a real disk (along the same lines as ecryptfs and EncFS); and/or (2) It can encrypt an entire partition or storage device. However, currently, it can only encrypt Windows operating systems and not Linux. As of the writing of this article it only has packages for OpenSuSE and Ubuntu but you can download the source and build it yourself on almost any Linux system.

The packages is a little controversial because while it is released under a license (TrueCrypt Collective License), that license has not been approved by the Open Source Initiative. In addition, while wikipedia is not always the most complete or up to date source of information, it does have a small section that talks about some security concerns with Truecrypt. One in particular is a tool to help locate Truecrypt files.

There are several tutorials or blogs that talk about using Truecrypt. Two of them are:

• A fairly long and detailed Howto that describes how to use Truecrypt on a Linux system.


• A Gentoo Wiki that talks about how to install it on a Gentoo system
  

One feature that Truecrypt has that not many encryption systems have is parallelization. It will use as many cores as the system has to parallelize the encryption/decryption process so it goes much faster (one of the Achilles heels of encryption/decryption – performance).

The Gentoo wiki has a nice summary of the kernel features that are needed to install and run Truecrypt:

• In the Device Drivers section:
  
  
  
  • Under “Multiple devices driver support (RAID and LVM)”:
    
    
    
    • “Device mapper support” should be enabled
      
    • “Crypt target support” should be enabled
      
    
    
  • Under “Block Devices” section:
    
    
    
    • “Loopback device support” must be enabled
      
    
    
  
  
• In the “File systems” section:
  
  
  
  • “FUSE (Filesystem in Userspace” must be enabled
    
  
  
• In the “Cryptographic API” section:
  
  
  
  • “RIPEMD-160 digest algorithm” must be enabled
    
  • “SHA384 and SHA512 digest algorithms” must be enabled
    
  • “Whirlpool digest algorithms” must be enabled
    
  • “LRW support” must be enabled
    
  • “XTS support” must be enabled
    
  • “AES cipher algorithms” must be enabled
    
  • “Serpent cipher algorithms” must be enabled
    
  • “Twofish cipher algorithms” must be enabled
    
  
  

According to the articles, you also need device-mapper support as well as “dmsetup” that you can find on Redhat’s site.

When you create a virtual volume with Truecrypt you will have to give it a fixed size because a file system is made on top of this virtual volume. The strength of this approach is that the entire volume is encrypted so you don’t have to worry about having an encrypted file system mounted to encrypt your data (makes things a little easier). But, on the downside, this virtual volume has a size limit that is usually much less than the physical volume.

However, one of the strengths of Truecrypt is that the virtual volumes (sometimes called “containers”) can be moved from one OS to another. So for example, you could create one on Windows XP and then copy it to Linux and be able to mount it and access the data. However, you can do a file at a time – you must do this for the entire volume.

dm-crypt

Dm-crypt (device-mapper crypt) went into the 2.6 kernel in about version 2.6.4. It uses the device mapper (dm) capability of Linux that has the ability to create virtual layers of block devices in a generic manner. These devices can then be used to do different things on top of real block devices such as mirroring, striping, concatenation, snapshotting, etc. You are probably already familiar with device-mapper because it is used by LVM and EVMS. Dm-crypt is a dm-mapper target that can be used to encrypt block devices using the CryptoAPI in Linux. This allows you to use any of the cipher algorithms in the kernel.

Using dm-crypt is very easy but you need to make sure that the kernel has device-mapper enabled (all of them should have this feature). You also need the “Crypto Target” support option enabled along with the cryptoapi options and the cipher algorithms you want to use. In addition, download the device-mapper package and build it and install it. Finally, grab the user-space tool, cryptsetup, from the dm-crypt website. This allows you to create dm partitions using dm-crypt.

There is a very good wiki for dm-crypt that contains a great deal of information. The best place to start is with the wiki entry for creating encrypted devices. The principle is fairly simple – dm-crypt translates data between a physical disk partition (e.g. /dev/sda1) and a logical partition (e.g. /dev/mapper/sda1) performing the encryption or decryption on the fly. You can mount and use the logical partition as a normal partition including putting a file system on it. For example,

# /usr/bin/cryptsetup --verbose --verify-passphrase create sdb1 /dev/sdb1

The “–verbose” option is a good idea so you can see everything that is happening and the “–verify-passphrase” forces you to verify the passphrase. This command will create the linkage between /dev/sdb1 and /dev/mapper/sdb1. It should prompt you for a passphrase which you will have to remember (otherwise the system will not mount the device and you can’t access the data). Now you can create your file system on top of the device but make sure you use /dev/mapper/sdb1 since that is the encrypted device. Finally, just mount the file system as you would any other.

Mounting and umounting the file system is fairly easy but it involves an extra step since cryptography is involved. For example, to mount the file system you need to do the follow two command:

# cryptsetup create sdb1 /dev/sdb1
# mount /dev/mapper/sdb1 /home

Notice that the first command creates the linkage from /dev/sdb1 to /dev/mapper/sdb1 (sdb1 is just used as an example). If you want to umount the file system then do the following:

# umount /home4
# cryptsetup remove sdc1

The last command “unlinks” /dev/mapper/sdb1 and /dev/sdb1. Rather than do this manually every time, you can modify /etc/rc.local.

There are several howto’s and blogs on the web that describe how to use dm-crypt with various Linux distributions. One of the best is an article from linuxdlsazine. The dm-crypt wiki has a number of contributed howto’s from how to use it with the root drive of a system, to using it in conjunction with LVM2 and software raid (md), to encrypting an existing device (yes it can be done).

Summary

There is a definite need for data encryption considering how “mobile” our data is and how much personal and private data is on our systems. It is important to pay attention to the security of this data (unless you want to star in your own your own Identity theft commercial.

This article is just a quick introduction to a few file system encryptions. The first two, ecryptfs and EncFS, fall into the category of creating an encrypted directory within a file system. This approach has many pluses including the ability to take individual files from the encrypted directory and sending them in encrypted form to people who require the data. These approaches are very easy to implement but use a little more space than encrypted devices because of the need to store a little extra metadata.

The second two, Truecrypt and dm-crypt, encrypt physical devices or partitions. In the case of dm-crypt the device mapper capability of Linux is utilized to create a linkage between the physical device, such as /dev/sdb1, and a device-mapper device, such as /dev/mapper/sdb1, using dm-crypt. Once the linage is created, then a file system can be created on the dm device (/dev/mapper/sdb1) as normal.

There is likely to be a great deal of debate about which approach is better, which one has more security holes, etc. This article is just a quick introduction to what is possible and a few pluses and minuses to the approach. However, it is fairly safe to say that if you want the maximum security possible you use a partition encryption scheme such as dm-crypt coupled with a directory encryption such as ecryptfs to encrypt user’s accounts (including root). This will definitely impact performance, but it should give a pretty reasonable level of security (just be sure to use different but very strong encryption schemes along with different pass phrases). Lesser levels of security can use either approach or combinations in whatever fashion you wish. Regardless of what you pick, think very carefully about using encryption somewhere on your system to protect your private data.

Last Week’s Homework

In last week’s article there was a little homework assignment about how to allow a user to go beyond a particular “chunk” in the combination of “chunks” using UnionFS.

I did receive two responses (thanks Greg and typhoidmary!). They both commented about using LVM to just extend the particular chunk the user had filled. This is a great answer and one that is very useful. Basically the approach is that you have to take down the union mount, umount the file systems, use LVM to grow the device (vg), extend the file system, remount all the chunks, and remount the union mount. While there are a few steps in this process, it is straightforward and it is a process that many admins are familiar with (perhaps making it the “best” solution).

There are other options though but they get a little more involved.

• You could move the user to a “chunk” that has more space available


• You could take some of the user’s larger directory trees, copy them to other partitions while sym-linking them back to the user’s home directory (make sure the permissions are correct). This takes a little work and accounting (you should make notes about where the directory trees are located).


• You could use the approach of finding the user’s oldest data, creating an archive using SquashFS to compress it and use UnionFS to combine it with the user’s home directory to make it appear as though it can be changed.

There are probably more options that I missed. I do accept late homework so if anyone has any ideas please pass them along to jlayton _at_ linuxdls.com.