Shopping for an encrypted filesystem

Secret Candidates

By Peter Gutmann, Christian Ney

Akhilesh Sharma, Fotolia

Crypto filesystems keep your data safe - even if someone steals your computer. The recent popularity of portable PCs has brought increased awareness about the need for protection, but even users with desktop systems have reasons for wanting to ensure that their data stays secret.

Linux offers a number of encrypted filesystem options - each with a different approach to the encryption problem. We took a look at some of the alternatives, with the goal of providing some insights on encryption techniques, code quality, and the relative merits of the various solutions. We examined the following encrypted filesystems:

• Loop-AES

• DM-Crypt

• Truecrypt

• Crypto-FS

• Enc-FS

In addition to looking at technologies and techniques, we will also examined some performance parameters for these encryption options.

Because few of these systems document technical details - the laudable exceptions being Truecrypt and Enc-FS - auditing means wading through tons of source code (generated by reverse engineering). While researching this article, we couldn't help feeling that source code analysis was more like an archaeological excavation than a code audit. Relevant functions were hidden away under multiple layers of code deposits, discarded software, and encryption experiments. But at least they shed some light on how the developers tried out various approaches to the problems of filesystem encryption.

Loop-AES

Loop-AES [1] is the oldest of the crypto filesystems we investigated for this article. It uses the venerable kernel loop module, and it will even run with the 2.0 kernel. The function of Loop-AES is similar to that of Cryptoloop, which has since proved to be insecure. Loop-AES works at the block device level and writes encrypted files to a container file or a partition designed specifically for that purpose.

Although Loop-AES performs some fairly low level system tricks, and the underlying technology is venerable to say the least, it is easy to use in practical applications. Crosscrypt [4] adds the ability to read Loop-AES containers on Windows.

A confusing number of options for building and using the Loop-AES filesystem prevents an effective security analysis. Encryption performance is radically different depending on your selection. The cluttered source code also prevents an audit, making it difficult to find out just what happens at the core of Loop-AES, and if the code really does what it claims to do.

Loop-AES does not use a salt (a series of random bits) to hash the password, which would prevent the case of the same password generating identical keys. Additionally, the Loop-AES algorithm uses a single hashing iteration (such as SHA-256 or SHA-512) to generate the encryption key. This approach leaves Loop-AES open to dictionary attacks - where a cracker uses dictionaries and rulesets to generate a list of possible passwords and calculate the hash in advance. The result is a collection of hashes that can be tried out, avoiding the need to test all possible combinations of numbers (which would be a brute force attack).

The readme for Loop-AES [3] maintains that Loop-AES is capable of using both salting and multiple iterations. The Loop-AES sample configuration files that Google turned up showed no trace of a salt and set the iteration value to 100 (which corresponds to 100,000 iterations). By default, Loop-AES does not use either salting or password hash iterations.

If a user explicitly selects iterations (and this only appears to be possible for AES-256), the software encrypts two 128-bit blocks with the initial key and exchanges the higher value 64 bits of the first 128-bit block with the lower value 64 bits of the second block. This algorithm is repeated for as long as you would like to repeat it in order to return the final 256-bit value.

As the name would suggest, Loop-AES uses the AES algorithm in CBC mode for encryption. The collection of options for handling the Initialization Vector (IV) is confusingly large, and includes options to set the sector number or an MD5 hash of this number as the IV.

Loop-AES has a major programming error in common with many crypto programs: the code entirely fails to check the return values of function calls. If an error occurs on calculating the key, the software just proceeds as normal without even noticing that the key is a bunch of zeros. This leaves the data practically unencrypted.

The code is so poor in part that the program would be more likely to crash with a null pointer dereference than actually with the use of an empty key. But relying on careless programming to protect oneself against more serious errors seems grossly negligent.

/dev/hda6 /home/chris/loopaes xfs defaults,loop=/dev/loop0,encryption=AES256 0 0

01 sudo aptitude install loop-aes-utils loop-aes-source
02 sudo module-assistant update
03 sudo module-assistant prepare
04 sudo module-assistant build loop-aes
05 sudo dpkg -i loop-aes-2.6.15-26-686_3.1b-8+2.6.15-26.45_i386.deb
06
07 losetup -e AES256 /dev/loop0 /dev/hda6
08 mkfs.xfs /dev/loop0
09 mount /dev/loop0 /home/chris/loopaes

DM-Crypt

DM-Crypt [5] officially became part of the device mapper with kernel version 2.6.4, providing a transparent data encryption service. The system can use a separate partition or a container (by way of Losetup) for storage.

In contrast to Loop-AES, DM-Crypt is not restricted to a single algorithm: users can select any algorithm known to the kernel. In contrast to its insecure predecessor, Cryptoloop, the approach used by DM-Crypt, is useful for journaled filesystems such as Ext 3 or XFS. DM-Crypt even mounts Cryptoloop containers, making the transition from Cryptolook painless for users. In addition to the kernel module, the DM-Crypt system requires a number of userspace tools.

The cryptsetup program should have been included with every distribution by now. Unfortunately, Ubuntu, which is very user-friendly apart from this, steps out of line, hiding this critical package in the Universe repository.

Today, cryptsetup is typically seen in combination with Clemens Fruhwirth's LUKS (Linux Unified Key Setup, [6], [7]). Our tests of DM-Crypt included LUKS.

LUKS stores its metadata in the container header, managing multiple passwords, which the admin can revoke individually without needing to re-encrypt the data. This ensures secure access by multiple users. Windows can read DM-Crypt formats in connection with Free OTFE [8].

DM-Crypt's biggest advantage is its seamless integration with the system as a whole. Debian and Ubuntu show how admin-friendly this can be, using a configuration file to automate the whole process at system boot time. Unnoticed by the user, it sets up an encrypted swap in a very elegant way:

swap /dev/hda2 /dev/random swap

This entry in /etc/crypttab applies to the swapspace on /dev/hda2. At system launch time, DM-Crypt grabs a random key from /dev/random and uses the key to encrypt the swap device. But enhanced security comes at a price: suspend to disk no longer works.

DM-Crypt has many characteristics in common with Loop-AES: both are kernel modules, and both confuse the user with too many build and runtime options. The default configuration is restricted to a single RIPEMD-160 hash iteration and does without a salt. The default IV mode is plain, which uses the 32-bit sector number as the IV.

Thankfully, there is a more secure mode known as ESSIV that encrypts the sector number (to prevent an attacker guessing it). However, our web search for configuration examples, and the example on the homepage, lead us to suspect that not many users actually go for ESSIV. Also, the security gains with ESSIV mode are minimal because the ESSIV is kept for all the data in this sector. From a cryptographic point of view, every sector should have a new IV for every change.

The LUKS variant of the DM-Crypt system performs much better, although, for some reason, the DM-Crypt-LUKS configuration keeps the insecure DM-Crypt parameter by default. This said, Cryptsetup-LUKS uses the encrypted sector number as the default IV when creating a device in LUKS format.

The main task for the LUKS extension is key management, however, and there are some notable improvements in this area. LUKS uses the established PBKDF2 standard key generation method to derive a key from the password.

cryptsetup luksFormat -y -c aes-cbc-essiv:sha256 /dev/hda6
cryptsetup luksOpen /dev/hda6 crypto mkfs.ext3 /dev/mapper/crypto

Truecrypt

Truecrypt [11] claims to be both secure and portable. The Truecrypt application uses encrypted containers on both Linux and Windows systems. Encryption algorithms include AES, Blowfish, Cast 5, Serpent, Triple-DES, and Twofish, and combinations of multiple variants are possible.

Three hash algorithms (RIPEMD-160, SHA-1, and Whirlpool) ensure integrity. Truecrypt (Figure 1) can use both files and partitions as containers. The former method is more popular with Truecrypt users.

Figure 1: TrueCrypt provides a graphic user interface for managing file resources.

The developers emphasize the user's ability to plausibly deny the existence of encrypted files. The way Truecrypt tries to do this is by using a prepared container that does not give rise to speculations on encryption. The software fills the container with random garbage data, and appends an inner container at the end of the shell - like Russian dolls (Figure 2).

Figure 2: A Truecrypt container without (top) and with (bottom) a hidden volume.

With the release of Truecrypt version 4.2 (in April 2006), this open source program, which was originally developed for Windows, introduced support for creating encrypted files on Linux. The initial step was only possible on Windows prior to this.

The software can't deny its origins, and the port to Linux is still incomplete. For one thing, it does not have the user interface that Windows users may be familiar with. The documentation for Windows is very good and comprehensive; Linux users have to make do with a fairly terse manpage.

Users are more likely to be put off by the complicated usage, starting with the installation. The project homepage has a number of prebuilt packages for common Linux distributions, but most of them fail if you update your kernel. Even though the changelog claims that there is no need to rebuild within a kernel version, some manual steps are needed on Ubuntu 6.06, for example.

From a cryptographic point of view, Truecrypt is the most sophisticated and professional program of all our test candidates. It comes with useful documentation, and it is based on standards such as the PBKDF2 key generation function, as well as LRW mode (see the box titled "LRW") for sector-based encryption. Truecrypt is the only program with safe defaults, and the software checks function return values, alerting the user in case of error.

The only thing that really bugged us about Truecrypt was the fact that the developers stick to the Rumpelstiltskin security model and disguise the container as a collection of digital garbage. They even take this Rumpelstiltskin approach so far as to have Truecrypt launch a brute force attack against the volume header in an attempt to access the data in the container.

Although the password is known, Truecrypt has to try out all hash and encryption algorithms until it finds usable data. This left us with an unnecessarily ambivalent impression: the program is convincing, and the programmers really know what they are doing. On the other hand, the developers are fairly bullheaded when it comes to controversial security properties.

01 sudo aptitude install build-essential linux-source gawk
02 cd /usr/src
03 sudo tar xvjf linux-source-2.6.15.tar.bz2
04 cd linux-source-2.6.15
05 sudo cp /boot/config-2.6.15-26-686 .config
06 sudo make prepare
07 cd /usr/src
08 tar xvzf truecrypt-4.2a-source-code.tar.gz
09 cd truecrypt-4.2a/Linux
10 sudo ./build.sh
11 sudo ./install.sh

01 Volume type: 1
02 Enter file or device name for new volume: /home/chris/truecrypt/test
03 Filesystem: FAT
04 Enter volume size (bytes - size/sizeK/sizeM/sizeG): 100M
05 Hash algorithm: 1
06 Encryption algorithm: 1
07 Enter password for new volume '/home/chris/truecrypt/test':
08 Re-enter password:
09 Enter keyfile path [none]:
10
11 truecrypt /home/chris/truecrypt/test /mnt

Figure 3: Encryption with a userspace filesystem: Glibc passes read and write operations through to the kernel, or to its VFS (Virtual filesystem) to be more precise. The FUSE module communicates with its userspace counterpart.

Crypto-FS

Crypto-FS [20] is the simplest of the crypto filesystems we investigated. Crypto-FS is a userspace filesystem based on LUFS, but now it also runs on FUSE. (See the box titled "Filesystems in Userspace.") As none of the major distributions has a software package for Crypto-FS at the time of this writing, some manual steps are required. A number of dependencies need to be fulfilled: developer packages for FUSE or LUFS, Libgcrypt [21] version 1.1.44 or newer, and Glib [22] version 2.6 or newer.

Following the standard ./configure && make && make install, you might like to adapt the sample cryptofs.conf configuration file provided with the distribution to your own needs, and store it as .cryptofs in the directory where you will be storing the encrypted files later. The first time you do this, Crypto-FS will prompt you for a password. There are two ways to launch the tool: in typical FUSE fashion using a separate binary titled cryptofs or using the LUFS module with lufsmount:

cryptofs -r /home/chris/.cryptofs /home/chris/cryptofs
lufsmount cryptofs://home/chris/.cryptofs /home/chris/cryptofs

The absolute pathname is vital, as mount will point to a black hole otherwise. To give potential attackers as little information as possible about the encrypted files, Crypto-FS runs a Base-64 cipher against the filenames before storing them. However, the file size is still visible.

Crypto-FS encrypts individual files with a user-selectable cipher, typically AES in CBC mode. The program has its own special approach to generating the initialization vector. After converting the user password to an encryption key, it ciphers a buffer with null bytes to derive n IV values. For every nth file block, Crypto-FS uses the IV with the number n. As the number of file blocks will easily exceed n in practical applications, the filesystems uses each IV multiple times - a capital error in cryptography.

The developers are happy to use a single call to a hash function, typically SHA-1, to transform the password into a key, and they even do it without a salt. This makes the program susceptible to dictionary attacks. To top this, the program does not check function return values. If a function that processes keys or encrypts data happens to fail, Crypto-FS just goes on working with a blank key, or it simply passes the cleartext data.

Enc-FS

Enc-FS [23] is another userspace filesystem based on the modern FUSE (Filesystem in Userspace, [17]), which became a part of the default kernel with the Linux 2.6.14 release. Current Enc-FS versions need at least FUSE 2.5 and Rlog [24]. Enc-FS relies on OpenSSL for encryption purposes.

Basic use is really simple. When you give the encfs ~/.encfs ~/encfs command, the program prompts you to supply the options shown in Listing 4. If one of the directories or both are missing, Enc-FS will create them for you (Lines 1 and 2). When run for the first time, the system creates a .encfs5 file in the source directory with the information required to encrypt the files stored in this directory. When you back up your data, make sure you include this file.

01 Directory "/home/chris/.encfs" does not exist, create (y,n)?
02 Directory "/home/chris/encfs" does not exist, create (y,n)?
03 Creating new encrypted volume.
04 Please choose from one of the following options:
05   enter "x" for expert configuration mode,
06   enter "p" for pre-configured paranoia mode,
07   anything else, or an empty line will select standard mode.

Enc-FS offers the options of operating in a standard mode and a paranoid mode. Standard mode uses the Blowfish algorithm with a key length of 160 bits and encrypts file names. The software processes 512 byte blocks during the encryption procedure, links the initialization vectors, and initializes the file headers separately.

Paranoid mode promises more security by using AES with a block size of 256 bits. In addition to the steps performed by standard mode, paranoid Enc-FS stores every block with a checksum to detect modifications to the data. In addition to this checksum feature, the filename is included in the initialization vector for the content. Renaming a file thus leads to complete re-encryption. This process breaks hardlinks, causing problems for programs such as Mutt or Procmail.

In addition to this, Enc-FS has an expert mode that allows users to select their own settings from a choice of all OpenSSL algorithms. If you prefer to leave filenames in the clear, the program gives you the option to do so.

In contrast to Crypto-FS, Enc-FS has a number of useful functions that make the system easier or safer to use. An Enc-FS mount can be unmounted automatically after a pre-defined period of time. This is a very useful option in combination with PAM integration [25]. And Enc-FS can hold sway with its stable mates with respect to choice of platform: version 1.3 or newer of the software is available for native FreeBSD, and there is a Windows port at [26].

Enc-FS encrypts each file with a block cipher, such as AES in CBC mode. However, due to a programming error, the software uses CFB (Cipher Feedback) rather than CBC (Cipher Block Chaining). Each 512-byte sector contains 504 bytes of data and an 8-byte HMAC (hashed MAC) of the cleartext.

Instead of removing the HMAC, Enc-FS Xors all the bytes. This value is also used as the initialization vector. If a single bit in the sector cleartext changes, the IV and therefore the whole enciphered sector change, too.

Enc-FS protects filenames by first encrypting them and then storing a Base-64 encoded version. Again, the program uses an HMAC derived from the filename as the IV. To prevent files of the same name returning identical ciphertext, Enc-FS uses the absolute pathname to calculate the MAC.

The encryption mode is a do-it-yourself complex. The program starts by Xor-ing each byte with the following byte. If the sector size is the same as the encryption algorithm block size, Enc-FS then encrypts the whole sector in CBC mode. If not, it uses CFB. This looks like a programming error, as the securer CBC would be preferable if the volume of data is an integral multiple of the block size.

The sector is always going to be bigger than an encryption block, and thus CBC is never used. Enc-FS then goes on to reverse the order of the bytes in every 64 byte section. Finally, it goes through another round of Xor and encryption operations. This next round is obviously designed to achieve the same data masking effect as an adjustable wide-block cipher, but it does not achieve the same cryptographic security, although the operations are just as expensive in terms of CPU usage.

Password transformation does without a salt in Enc-FS and is limited to 16 hashing iterations. One or two thousand iterations are considered the minimum to prevent dictionary attacks.

Like many of its competitors, Enc-FS hardly bothers to check function return values. If something goes astray, the data remain unencrypted. Even where the code checks the return values, it makes serious errors. Instead of ensuring that the operation has been performed successfully, the program defaults to assuming that everything has turned out okay, and it just checks for a few of all possible error conditions. If the function fails with an unexpected return value, Enc-FS ignores the error and carries on regardless.

Speed

We asked all the crypto filesystems we tested to show their pace in a benchmark. Our lab machine was an IBM Thinkpad T40p with 1.5 GB RAM and a 7200 rpm Hitachi hard disk. The values were measured on Ubuntu 6.06 LTS using Bonnie++ [27] with 3-GB datasets. XFS was the filesystem in the encrypted container in each case.

The results in Figure 4 clearly show the performance hit that encryption causes. Although it only achieves half the normal throughput, the DM-Crypt filesystem demonstrates fairly constant read and write speeds, its strongest point being block-wise operations. Truecrypt's write performance is poor; it can't even match the Enc-FS userspace tool for speed. But it picks up speed again on read operations, almost matching DM-Crypt for pace.

Figure 4: The Bonnie ++ benchmark shows that encryption affects read and write performance. Loop-AES has the fastest charcter-wise write performance, but DM-Crypt reads faster block-wise. Truecrypt wins on block-wise reading. Enc-FS is amazingly quick for a user-space filesystem.

Loop-AES is the fastest of the candidates for character-wise read and write operations, although it loses out to DM-Crypt on block operations. For a userspace filesystem Enc-FS does fairly well, its strongest point being block-wise read and write operations. However, smaller files see it drop down to a similar speed as Truecrypt, with particularly poor read performance. The Crypto-FS filesystem lags well behind the field, achieving just one third of the throughput for unencrypted data.

01 void CipherV3::randomize( unsigned char *buf, int len ) const
02 {
03     memset( buf, 0, len );
04     if(RAND_bytes( buf, len ) == 0)
05     {
06         char errStr[120];
07         unsigned long errVal = 0;
08         if((errVal = ERR_get_error()) != 0)
09         {
10             rWarning("openssl error: %s", ERR_error_string( errVal, errStr ));
11         }
12     }
13 }

Where's the Beef?

Most crypto filesystems on Linux leave the user with a sour taste. They trip up over cryptographic pitfalls, and the implementations are typically fairly weak (typical errors: failure to check function return values). Of all things, Truecrypt - a program originally developed for Windows, and one that does not integrate well with Linux as of this writing - is the positive exception to the rule. DM-Crypt in the Cryptsetup LUKS variant takes second place. Its performance is good, and it evidences less cryptographic errors than the other contenders, assuming that the user opts for a secure configuration. The default settings are unnecessarily insecure. And it is disappointing that the LRW patch has not made it into the kernel.