next up previous
Next: 6. Conclusions Up: Cryptfs: A Stackable Vnode Previous: 4. Evaluation


5. Related Work

There are two popular Cryptographic file systems in existence: Matt Blaze's CFS[2] and Cattaneo and Persiano's TCFS[3]. Both are compared to Cryptfs in Section 4. The other works mentioned below suffer from one of two problems: their performance is poor, or they are not portable enough to be readily available on systems used these days.

5.1 CFS

CFS[2] is a portable user-level cryptographic file system based on NFS. It is used to encrypt any local or remote directory on a system, accessible via a different mount point and a user-attached directory. Users first create a secure directory and choose the encryption algorithm and key to use. Any file or directory in a secure one is encrypted.

When users wish to use the secure directory, they run a tool and provide a private key to attach their encrypted directories via CFS. Then they access their cleartext files through the attached point. Once attached, file access is as transparent as any other directory. CFS determines if a user is allowed to access an attached directory based on the UID of the caller.

File data and meta data (symbolic links, file names, etc.) are encrypted. A wide choice of ciphers is available and great care was taken to ensure a high degree of security. A single CFS server can manage multiple directories as well as several users using different keys and ciphers per directory. CFS' performance is limited by the number of context switches that must be performed and the encryption algorithm used.

5.2 TCFS

TCFS[3] is a modified client-side NFS that communicates with a remote NFS server as well as a special RPC based attributes server. TCFS requires the installation of modules and tools on the client, as well as a special attributes daemon on the server. TCFS is available only for Linux systems; both client and server must run a Linux operating system.

TCFS offers a smaller choice of ciphers than CFS does, one of which must be chosen and statically compiled into the file system module. All files are encrypted with the same cipher. User keys default to login passwords that are less secure than passphrases. Encrypted user keys are stored in the file /etc/tcfspasswd which further reduces security. All files belonging to one user are encrypted using the same key.

TCFS allows individual files or directories to be encrypted by turning on or off a new and special flag 'X' on the file or directory in question. This provides finer grained control over which files should or should not be encrypted.

5.3 Truffles

Truffles[13] is a distributed file system that uses the Ficus system developed at UCLA to offer replication and file sharing[4,6]. Truffles uses Privacy Enhanced Mail (PEM) as the method of securely communicating file data over a network. PEM provides authentication and encryption of the data. Truffles was designed to allow users to securely share files without special setup and with minimal system administrator intervention.

Ficus is not as readily available as other network based file systems such as NFS, nor is it very portable because it requires specialized operating system stackable layers support. Also, basing network negotiation on an electronic mail system results in long delays and significantly reduced performance.

5.4 Other Stackable File Systems

Several other operating systems offer a stackable file system interface. Such operating systems have the potential of easy development of file systems offering a much wider range of services than just encryption. Their main disadvantages are that they are not portable enough, not sufficiently developed or stable, or they are not available for common use. Also, new operating systems with new file system interfaces are not likely to perform as well as ones that are several years older.

The ``Herd of Unix-Replacing Daemons'' (HURD) from the Free Software Foundation (FSF) is a set of servers running on the Mach 3.0 microkernel[1] that collectively provide a Unix-like environment. HURD file systems are implemented at user level. The novel concept introduced by HURD is that of the translator. A translator is a program that can be attached to a pathname and perform specialized services when that pathname is accessed. Writing a new translator is a matter of implementing a well defined file access interface and ``filling in'' such operations as opening files, looking up file names, creating directories, etc.

Spring is an object-oriented research operating system built by Sun Microsystems Laboratories[10]. It was designed as a set of cooperating servers on top of a microkernel. Spring provides several generic modules that offer services useful for a file system: caching, coherency, I/O, memory mapping, object naming, and security. Writing a file system for Spring requires defining the operations to be applied on the file objects. Operations not defined are inherited from their parent object.

One work that has resulted from Spring is the Solaris MC (Multi-Computer) File System[7]. It borrowed the object oriented interfaces from Spring and integrated them with the existing Solaris vnode interface to provide a distributed file system infrastructure through a special file system called the pxfs - the Proxy File System. Solaris MC provides all of the benefits that come with Spring, while requiring little or no change to existing file systems; those can be gradually ported over time. Solaris MC was designed to perform well in a closely coupled cluster environment (not a general network) and requires high performance networks and nodes.

next up previous
Next: 6. Conclusions Up: Cryptfs: A Stackable Vnode Previous: 4. Evaluation
Erez Zadok