data without the use of a separate encryption program, making it
hard to avoid all the problems outlined in the previous paragraph.
Furthermore, rather than being confined to a single program,
encryption is spread among multiple applications, each of which
must be trusted to interoperate securely and correctly with the
others. A single poorly designed component can introduce a sig-
nificant and difficult to detect window of vulnerability.(For
example, some versions of the Unix editor vi can encrypt files
but still leave temporary data in the clear.) Changing the encryp-
tion algorithm entails modification of every program that uses it,
creating many opportunities for implementation errors. Finally,
multiple copies of user-level cryptographic code can introduce a
significant performance penalty.
1.2. System-Level Cryptography Is Often Insufficient
One way to avoid many of the pitfalls of user-level encryp-
tion is to make cryptographic services a basic part of the underly-
ing system. In designing such a system, it is important to identify
exactly what is to be trusted with cleartext and what requires
cryptographic protection. In other words, we must understand
what components of the system are vulnerable to compromise.
In general, the user has little choice but to trust some com-
ponents of the system, since the whole point of storing data on a
computer is to perform various operations on the cleartext. Ide-
ally,however,required trust should be limited to those parts of a
system that are under the user’s direct control.
For files, we are usually interested in protecting the physi-
cal media on which sensitive data are stored. This includes on-
line disks as well as backup copies (which may persist long after
the on-line versions have been deleted). In distributed file server-
based systems, it is often also desirable to protect the network
connection between client and server since these links may be
very easy for an eavesdropper to monitor.Finally,itispossible
that the user may not trust the file server itself, especially when it
is physically or administratively remote.
Physical media can be protected by specialized hardware.
Disk controllers are commercially available with embedded
encryption hardware that can be used to encipher entire disks or
individual file blocks with a specified key.Once the key is pro-
vided to the controller hardware, encryption is completely trans-
parent. This approach has a number of disadvantages for general
use, however.The granularity of encryption keys must be com-
patible with the hardware; often, the entire disk must be thought
of as a single protected entity.Itisdifficult to share resources
among users who are not willing to trust one another with the
same key.Obviously,this approach is only applicable when the
required hardware is available. Backups remain a difficult prob-
lem. If the backups are taken of the raw,undecrypted disk, it
may be difficult to restore files reliably should the disk controller
hardware become unavailable, even when the keys are known. If
the backup is taken of the cleartext data the backup itself will
require separate cryptographic protection. Finally,this approach
does not protect data going into and out of the disk controller
itself, and therefore may not be sufficient for protecting data in
remote file servers.
Network connections between client machines and file
servers can be protected with end-to-end encryption and crypto-
graphic authentication. Again, specialized hardware may be
employed for this purpose, depending on the particular network
involved, or it may be implemented in software. Not all net-
works support encryption, however,and among those that do, not
all system vendors supply working implementations of encryp-
tion as a standard product.
Even when the various problems with media and network
level encryption are ignored, the combination of the two
approaches may not be adequate for the protection of data in
modern distributed systems. In particular,even though cleartext
may never be stored on a disk or sent "over the wire", sensitive
data can be leaked if the file server itself is compromised. The
file server must maintain, at some point, the keys used to enci-
pher both the disk and the network. Even if the server can be
completely trusted, direct media encryption on top of network
encryption has a number of shortcomings from the point of view
of efficient distributed system design. Observe that each file
access requires two cryptographic operations by the server,once
for the network and once for the disk, even though the server
itself never makes use of cleartext data. Such a design violates
the principle that work should be shifted from the (shared, heav-
ily loaded) file server to the (unshared, lightly loaded) client
machine whenever possible[1]. Even if the cryptographic opera-
tions are themselves implemented in hardware, additional server
software complexity is still required to support them.
Several commercial and research systems incorporate cryp-
tographic techniques for protecting file data against various kinds
of attack. In the personal computer (e.g., MS-DOS, Macintosh)
world, there are file encryption systems that can create an
"encrypted area" on a disk. These packages generally require the
preallocation of storage space to a given key,and often support
only a particular kind of storage media (such as a local hard
disk). Encrypted files typically appear outside the system as a
single large file and therefore cannot be readily managed by con-
ventional administration tools or moved to arbitrary storage
devices. In larger-scale systems, cryptographic techniques are
even less widely used, although a few systems do use encryption
for protecting certain vulnerable interfaces. The Truffles sys-
tem[7], for example, uses a combination of cryptographic authen-
tication and secret-key encryption to protect network access to
widely distributed shared files. The files themselves, however,
are stored at the server in clear form.
In the following sections, we describe the alternative
approach taken by the Cryptographic File System (CFS). CFS
pushes file encryption entirely into the client file system interface,
and therefore does not suffer from many of the difficulties inher-
ent in user-level and disk and network based system-level encryp-
tion.
2. CFS: Cryptographic Services in the File System
CFS investigates the question of where in a system respon-
sibility for file encryption properly belongs. As discussed in the
previous section, if encryption is performed at too low a level, we
introduce vulnerability by requiring trust in components that may
be far removed from the user’s control. On the other hand, if
encryption is too close to the user,the high degree of human
interaction required invites errors as well as the perception that
cryptographic protection is not worth the trouble for practical,
day-to-day use. CFS is designed on the principle that the trusted
components of a system should encrypt immediately before send-
ing data to untrusted components.
2.1. Design Goals
CFS occupies something of a middle ground between low-
level and user-level cryptography.Itaims to protect exactly those
aspects of file storage that are vulnerable to attack in a way that is
convenient enough to use routinely.Inparticular,weare guided
by the following specific goals:
•Rational key management. Cryptographic systems restrict
access to sensitive information through knowledge of the
keys used to encrypt the data. Clearly,tobeofany use at
all, a system must have some way of obtaining the key
from the user.But this need not be intrusive; encryption
keys should not have to be supplied more than once per