Article

jun2003.tar

CFS -- The Cryptographic File System

Keith McDuffee

The use of Linux on laptops has become increasingly popular as a development platform, and with this increased use of laptops comes the necessity for securing a company's intellectual property, namely product source code. Ordinary file security protects a file from unauthorized access within the normal operating context, but an attacker who has physical control of the computer has many other options for gaining access to the file if it is not encrypted. So, when a laptop is stolen, there's often a lot more at stake than the price of the hardware.

Recently I was asked to find a tool to keep product source code on laptops encrypted while being relatively painless for developers to use. We didn't want to require users to enter a password for each file being accessed, much like an encryption application might work. This would also leave too much up to the user in terms of making sure each sensitive file was encrypted when not in use. Another important factor was performance. If developers experienced noticeable performance loss, they'd be more inclined to bypass the encryption route altogether and hope for the best.

For my solution, I chose Matt Blaze's Cryptographic File System (CFS), which is located here:

http://www.crypto.com/software/

Another option I considered was TCFS (http://www.tcfs.it), or Transparent CFS. TCFS requires some kernel modifications and, as of this writing, the latest release only supported the 2.2 Linux kernel. The Linux CryptoAPI project (http://www.kerneli.org) is an ambitious project that also requires kernel modification, and I felt it was a bit beyond what I needed to do in my case.

The original work on CFS dates back to 1992. Matt Blaze has updated it since then, with version 1.4.0 appearing in beta form around 1997, but CFS is not currently in active development, and Blaze warns at his Web site to consider the code unsupported. Nevertheless, the CFS solution worked well for my purposes, and it may work for you also if you are in a similar situation.

In this article, I will cover building and configuration of CFS under Linux only, however, CFS is reported to run under IRIX, AIX, and Solaris. The RPMs I found worked out of the box under Red Hat 7.2 through Red Hat 9, which our laptops use. After applying a small patch, the latest source code also built without issues.

How CFS Works

Unlike application-based solutions for encryption, CFS works on the system level through a standard UNIX file system interface. A daemon (cfsd) runs on the client system as a special NFS server, on its own port (3049), to interpret CFS requests. A user then creates, "attaches", and "detaches" special directories that will contain the encrypted files. Current directories cannot be converted into CFS directories without copying their contents into a new, attached CFS directory. The latest version of CFS supports 3DES encryption as well as DES, Blowfish, MacGuffin, and SAFER-SK128.

Once a CFS directory is created and attached, all files written through the attached directory are encrypted (and decrypted) on the fly. A directory becomes detached when a user manually detaches it or when cfsd is stopped.

Building and Installing CFS

You can obtain a somewhat older version of a CFS RPM at:

http://www.rpmfind.net//linux/RPM/rhcontrib/7.1/i386/cfs-1.4.0.beta2-6.2.i386.html

or the latest sources (1.4.1) from:

http://www.crypto.com/software/

When building from the 1.4.1 sources, you need to apply a patch found either on the Sys Admin Web site:

http:/www.sysadminmag.com/code/

or:

http://www.realistek.com:5150/sources/cfs-1.4.1-patch.


user> tar xvfz cfs-1.4.1.tar.gz
user> patch -p0 <cfs-1.4.1.patch
user> cd cfs-1.4.1
user> make cfs
user> su
# make install_cfs

CFS comes with another piece of software called ESM (Encrypted Session Management). ESM is an encrypted session layer for managing remote encrypted sessions, but that won't be covered here.

To use CFS, you will need to have the nfs-utils and mount packages installed on your system. You should be able to find the RPMs at http://www.rpmfind.net or on your CD distribution.

Starting CFS

Since cfsd runs as an NFS server, we'll be mounting an NFS exported directory onto the local system:

# mkdir /.cfsd
# chmod 0 /.cfsd
# mkdir /mnt/crypt

Make the following addition to /etc/exports:

/.cfsd           localhost(rw)

Add this line to /etc/fstab:

localhost:/.cfsd     /mnt/crypt   nfs   port=3049,intr,vers=2,udp
      0 0

The /.cfsd directory is a placeholder for exporting our CFS directories. It can actually be any name, as long as it's also reflected in the /etc/exports file. It's also important to be sure to mount the directory with the NFSv2 and UDP flags.

Start cfsd and proceed with the export and mount of the CFS:

user> su
# /usr/local/etc/cfsd
# exportfs /.cfsd
# mount /mnt/crypt

Using CFS

Directories are created using the cmkdir command. The resulting directory is essentially a normal directory that contains the key information for decrypting/encrypting files that are passed in/out of it via CFS:

user> cd /home/user
user> /usr/local/bin/cmkdir junk
Key: <enter at least 16-character key>
Again: <enter same key again>

The key you use must be at least 16 characters long, which can include spaces, so using an easy to remember phrase with several shifts in case and added symbols can help lessen the practice of writing it down somewhere (i.e., "Thi$ iz mY Stufff"). It's also a good idea not to use a directory name, like "sourcefiles", that would arouse curiosity.

You will now see the regular directory "junk" in /home/user; however, placing files into this directory does not encrypt them. You need to attach the directory to CFS in order to access it:

user> cd /home/user
user> /usr/local/bin/cattach junk
Key: <enter key used during creation>

You can access the directory via its CFS mountpoint in /mnt/crypt. This is where you will place your files to be encrypted and see them unencrypted, as long as the directory is attached to CFS. For example, let's create a simple text file in the newly attached directory:

user> echo "This is a test" > /mnt/crypt/junk/test.txt
user> ls -l /mnt/crypt/junk/
-rw-rw-r--    1 user   users          15 Sep 24 14:59
/mnt/crypt/junk/test.txt
user> cat /mnt/crypt/sourcefiles/test.txt
This is a test

We can also see what the directory contents look like in their encrypted state to see what's going on behind the scenes:

user> ls -l /home/user/junk
total 1
-rw-rw-r--    1 user   users          23 Sep 24 14:59
fc23b20ec3aa88a8b8c1016cf2575028

If you tried to cat the contents of that file, you'd see a bunch of indistinguishable characters.

cattach can be used with the -t flag to automatically detach the attached directories after a specified number of minutes, or -i for a specified number of minutes of inactivity. Otherwise, to detach directories, you use the cdetach command:

user> /usr/local/bin/cdetach /home/user/junk

Of course, rebooting or shutting down the laptop will also cause attached directories to become detached.

Like other system level daemons, you might want to create a chkconfig script in /etc/init.d to have cfsd start during boot time. Just make sure the script starts after your nfs script and before your netfs scripts or you will run into errors when cfsd tries to start. Having this script in place will make things a bit easier for the user to put CFS into common practice, too.

Other CFS Commands

CFS has a few other useful commands worthy of mention:

cfssh -- A simple Korn Shell script that attaches the CFS directory given, then invokes a new shell within the attached directory. Edit this script as appropriate for your installation.

ccat -- Intended to assist in emergency access to CFS directories when cfsd is not running.

cmkkey -- Creates a secondary copy of the key for an encrypted CFS directory into a new CFS directory.

cpasswd -- Changes the passphrase associated with a CFS directory.

Conclusion

My own tests have shown that there doesn't seem to be a significant impact on read/write performance when using CFS, which should be within range for routine use in typical developer environments.

Computer theft is obviously not limited to laptops. CFS can be put into use on desktop systems as well, but security should of course not end there. A multitude of tools can be used to secure systems from would-be thieves on a software level, and common sense and a secure working environment will obviously help protect physical inventory.

Implementing a policy for using CFS on all developer laptops is much easier than enforcing one. The tools may be simple to use, but making sure sensitive documents and source files are always kept under CFS will still be left up to the individual user. Similarly, keeping access keys to CFS-encrypted directories on scraps of paper within a laptop case is an open invitation for data theft, making CFS worthless. CFS probably won't prevent a skillful hacker from accessing your files, but if a laptop gets left behind in an airport terminal, you'll be glad your data's not left out there with it.

Resources

http://www.crypto.com/software

http://www.crypto.com/papers/cfs.pdf

http://www.tcfs.it

http://www.kerneli.org

Keith McDuffee (gudlyf@realistek.com) has been a Network and Systems Administrator for more than 10 years and is currently employed as the IT Manager for Etnus in Natick, Massachusetts.