Encrypted File Systems

Here's a good way to protect your files. Mr. Giles explains how to encrypt your entire file system rather than individual files.

by Bear Giles

In one episode of ``Miami Vice'' Crockett and Tubbs have managed to gain access to a drug runner's computer, only to be stymied by its insistence on a password before presenting incriminating evidence. Not to worry--after only three unsuccessful guesses, the helpful computer offered to reveal the secret password to our heroes. It's easy to laugh at this plot development, but many otherwise intelligent people continue to do equally dumb things.

Consider the law office where legal papers are always kept in locked cabinets behind locked doors. Every computer on the LAN also has access to the ``password-protected'' word processing documents, but the encryption can be broken in seconds with readily available software. The name of this program, and the files it can crack, are in the sci.crypt FAQ. These files could be retrieved by a hostile agent ``working'' for a cleaning contractor.

Or consider the company with sales offices spread nationwide. Highly sensitive pricing and contact information is distributed on CD-ROM discs, which are discarded as soon as each new disc arrives. Alternately, a salesman may have his laptop stolen while on the road. (See Practical UNIX and Internet Security, Garfinkel and Spafford, O'Reilly and Associates, 1996.)

Or consider the individual computer owner who leaves his system in a shop for free installation of an upgrade. One of the employees quietly copies a few files, and by the time the victim learns of the extent of the identity theft it's too late--he's already recommended the same shop to several of his friends for the unusually good service.

Solution: File Encryption

For every complex problem there is an answer that is clear, simple and wrong. --H. L. Mencken

The simple solution to these problems is file encryption. But this solution is flawed for several reasons:

Encryption within programs is generally weak to the point of uselessness due to U.S. export regulations.
Encryption outside programs requires explicit actions to decrypt and to re-encrypt. This problem may be manageable if a file needs to be accessed only by a single user, but it's a much more difficult problem if several people need to share access.
Explicit encryption requires sharing the password, and the more people who have the password, the more likely it becomes that someone will jot it down in an obvious location.
Explicit encryption may enable a disgruntled employee to encrypt the files with a different password.
Decrypting a file increases the risk that unencrypted versions will remain on the disk or on backup media.

Even with its flaws, file encryption may still be better than the alternatives. Fortunately there is a better solution.

Solution: File System Encryption

Our solution is to encrypt the entire file system. User programs see a regular file system--perhaps even a file system that natively supports encryption. An attacker who can only see the physical disk sees garble.

This approach is not perfect. Most notably, some implementations could leave decrypted data visible in the disk cache. That is a minor problem with the cache in core (if an attacker has compromised root, you have more serious problems), but a major problem if these pages get written to swap.

On the other hand, the kernel ensures that disk sectors are decrypted during reads and re-encrypted during writes. The impact on users is minimal. In one practical scenario, a ``responsible individual'' will mount the encrypted file system in the morning. (This requires the encryption key.) In the evening, the last person to leave could unmount the file system, or it could be automatically unmounted by a cron job.

Encryption Algorithms

Better the devil we know... --Anonymous

We've agreed on the desirability of encrypting file system. But which encryption algorithm should we use? The wrong choice will leave us with a false sense of security.

Writing our own encryption routines is one possibility. The downside is encryption algorithms are notoriously difficult to properly design and implement. The problem is that the designer does not know what others will find difficult. He only knows what he finds difficult. Mathematics is littered with the bodies of ``difficult'' problems which became trivial after one person had a flash of insight.

As a practical matter, we should limit our search to well-known encryption algorithms. This has the additional benefit of allowing us to share encrypted file systems with others with a minimum amount of hassle.

XOR

The first encryption algorithm learned by most programmers is the lowly xor algorithm. To encrypt the data, we XOR it with the key (modulo the length of the key, if we use multi-byte encryption). To decrypt the data, we XOR it with the key again.

Benefits: fast and exportable
Drawback: trivial to break
Synopsis: stops casual snooper

DES

DES has a controversial past. It was a government-endorsed algorithm for non-classified use, but some people believe that the government deliberately introduced weaknesses. On the other hand, decades of research have revealed only relatively modest weaknesses. It is economically feasible for a large company to build a DES-cracking machine.

Benefits: strong, well-tested, 56-bit keys (The variant known as TRIPLE-DES uses 112-bit keys.)
Drawback: not exportable
Synopsis: a reasonable choice

IDEA

DES was designed for hardware implementations--and is difficult to implement efficiently in software. IDEA was designed around the low-level operations common on small processors. It is not a U.S. federal standard and wasn't weakened by the dreaded TLAs (three letter acronyms, such as DEC and FBI). On the other hand, while the TLAs have undoubtedly analyzed it, they aren't talking.

Benefits: strong, tested, 64-bit keys (used internally by PGP)
Drawback: not exportable
Synopsis: a reasonable choice

RSA

RSA encryption is a relatively ineffective algorithm. Many people feel that the primary weakness with PGP lies in the 1024-bit RSA encryption of the IDEA key, not the IDEA encryption of the actual data.

Benefits: solution to public key encryption problem, 128-bit keys
Drawbacks: requires at least 1024 bits for security comparable to IDEA, very slow
Synopsis: not appropriate

Obtaining the Source: Cypherpunks

Fools rush in where angels fear to tread. --Alexander Pope

Undoubtedly, some people now feel the urge to run out and write an encrypting file system. The rest of us turn to the Cypherpunks. They have published a set of patches to the 2.0.11 kernel which implement DES and IDEA encryption in ``loopback'' devices. The primary source for these patches is at: ftp://ftp.csua.berkeley.edu/pub/cypherpunks/filesystems/linux.

There are four patches:

loopfix-2.0.11.patch: modifications to loopback device
export-2.0.11.patch: more patches, mostly to documentation and the makefile
crypto-2.0.11.patch: export-restricted patches: DES and IDEA
mount-2.5k.patch: modification to mount to pass encryption keys.

The U.S. government continues to interpret the International Traffic in Arms Regulation (ITAR) in a manner that prohibits the export of meaningful cryptographic software via electronic means. There are no restrictions on the export of the same material in printed form or its subsequent distribution from sites outside North America.

The source code in crypto-2.0.11.patch implements DES and IDEA encryption and cannot be legally exported, even though this source is readily available worldwide. Violating export restrictions will not aid the effort to promote the free use of strong encryption, since the government could use this as proof of the need for stronger restrictions on domestic distribution.

Building the Kernel

Building the new kernel is no different than applying any other set of patches. The latest stable kernel release for which this works is 2.0.30. For convenience, I will assume it is stored in /usr/src/linux-2.0.30.tar.gz. Next, build a reference version of the kernel. Then, follow these steps:

Get the latest encrypted file system patches. For convenience, I will assume that they are the 2.0.11 patches and stored in /usr/src/cryptfs.

Apply the patches to the kernel, retaining the reference copy. On my system, this involved making a working directory, and applying the patches and fixing problems. I made the working directory by issuing the following commands:

cd /usr/src
rm linux 
tar xzpf linux-2.0.30.tar.gz
mv linux linux-2.0.30.efs
ln -s linux-2.0.30.efs linux

I applied the patches using these commands:

cd linux
patch < ./cryptfs/export-2.0.11.patch
patch < ./cryptfs/loopfix-2.0.11.patch
patch < ./cryptfs/crypto-2.0.11.patch

I fixed problems using these commands:

mv *.h linux/include/linux
mv des.c linux/kernel
mv idea.c linux/drivers/block
mv loopfix.txt linux/Documentation

Configure and build the new kernel. Remember to enable the loopback device and file system encryption.
Get the source for mount and apply the required patch. Build it.
Reboot the system with your new kernel.

At this point everything should be ready to go, but I've encountered problems after builds. I believe my problem was caused by improper application of the patches, perhaps due to order-based instabilities caused by changes between the 2.0.11 and 2.0.30 and above kernels. One recurrent problem occurred with the urandom command:

od -x /dev/urandom | more

Giving this command produced kernel warning messages. If this happens to you, reinstall the kernel source and patches and check your warnings carefully.

Encrypted File Systems: Ready, Set, Go!

Find a couple of blank floppies on which to test an encrypted file system. Then, create an encrypted file system using DES encryption:

# dd if=/dev/urandom of=/dev/fd0 bs=1k count=1440
# losetup -e des /dev/loop0 /dev/fd0
Pass phrase: des test
# mke2fs /dev/loop0
# losetup -d /dev/loop0

A couple of notes about this example:

The first command initializes the floppy disk with random data. Initializing the disk to zeroed data reduces a blank disk to a ``known plaintext'' cryptology problem--not a good idea.
The second command specifies that we want a loopback device to cover the floppy device driver with a DES encryption layer. We could replace /dev/fd0 with the name of a file. The pass phrase is not echoed. Also, the pass phrase can be 120 characters long--and should definitely be more than 8 characters!
The third command is the normal mkfs(1) utility.
The fourth command releases the loopback device.

We also want to create an encrypted file system using IDEA; the same idea, only replace des with idea.

Finally, create one more pair of disks which use different passwords. (If you want to be unusually perverse, use your previous IDEA test pass phrase on your second DES test disk and vice versa.)

Now we're ready to mount these disks. First, try to mount the floppies using a standard mount command:

# mount /dev/fd0 /mnt -text2

These commands should fail with ``can't find an EXT2 file system.'' Now try mounting each floppy again:

# mount /dev/fd0 /mnt -text2,loop,encryption=idea
# mount /dev/fd0 /mnt -text2,loop,encryption=des

In each case you should be prompted for a pass phrase. Needless to say, you should not be able to mount the DES encrypted disk when specifying IDEA encryption, and vice versa. Likewise, you should not be able to mount the DES encrypted disk 1 with the second password or vice versa, and you should be able to mount the file system when you specify the correct encryption format and password.

This is another area where gremlins have appeared on my system. Once IDEA encryption worked fine but /dev/urandom failed; in another case, /dev/urandom worked but IDEA encryption produced kernel warnings on every even sector.

Now a few more tests. Edit the /etc/fstab file to add these entries:

/dev/fd0 /mnt/des  ext2
	defaults,noauto,loop,encryption=des  0 0
/dev/fd0 /mnt/idea ext2
	defaults,noauto,loop,encryption=idea 0 0

Try to mount your test disks on /mnt/des and /mnt/idea. Once again you should be prompted for a pass phrase and will be successful only when encryption algorithm and pass phrases match.

Finally, reboot your system and repeat these tests. If possible, install the modified kernel on a second system and verify that you can exchange media between the systems. Such is life on the bleeding edge of technology.

Applications

Now that we have encrypted file systems, what can we do?

We can add strong encryption to programs which don't support them natively, and we keep their files on an encrypted file system.
We can add strong encryption to distributed media. Some people already build ISO-9660 images in a file via a loopback device; producing an encrypted image would be trivial.
CD-ROM-based back-up protocols become more attractive. Outdated back-up discs can be discarded without fear of a dumpster diver gaining access to crucial information.
We can improve system security. Programs such as Tripwire, which record cryptographic signatures of key files, traditionally require read-only media to prevent attackers from modifying the reference information. It is still conceivable that an inside attacker could replace this critical disk. Now, we can easily keep this crucial information in an encrypted form, making a spoofed disk much harder to produce.
We can add a measure of strong encryption to entire systems which don't support them natively. Encrypted file systems should be exportable via NFS or SMB--packet sniffers remain a problem but the disk would be protected.

Long-Term Applications

Even taking a cursory glance at the trends of security software, one notices recurring themes. Encrypted file systems protect the data on disks. SSH (Secure Shell) encrypts and authenticates communications. Secure-RPC (remote procedure call) encrypts interprocess communications. RPM authenticates software upgrades.

Is there any question that encryption and authentication routines belong in the kernel? Encryption keys could be stored with each device and process, and with negotiations for unique session keys automatically mediated between any process within and without the system that desired it. There would not be needless duplication of identical routines, or worries about export restrictions since these issues would have already been addressed. If necessary the encryption routines could be localized to a loadable module, although that raises certain security issues.

The downside is anyone with root access can grab the encryption keys from the system tables; however, once root is compromised all bets are off anyway. On the other hand, supplying strong encryption and authentication services in the kernel should reduce the risk of root becoming compromised. Also, DH key negotiation means that my keys aren't compromised even if I'm talking to someone who is compromised.

Bear Giles, bear@coyotesong.com, of Coyote Song LLC, is a UNIX Consultant with almost 15 years of experience. He has used Linux at home since pre-0.99 days.