1、17th ACM Symposium on Operating Systems Principles (SOSP 99)Published as Operating Systems Review 34(5):124139, Dec. 1999Separating key management from file system securityDavid Mazieres, Michael Kaminsky, M. Frans Kaashoek, and Emmett WitchelMIT Laboratory for Computer Sciencedmlcs.mit.edu, kaminsk
2、ylcs.mit.edu, kaashoeklcs.mit.edu, witchellcs.mit.eduAbstractNo secure network file system has ever grown to span the In-ternet. Existing systems all lack adequate key managementfor security at a global scale. Given the diversity of the In-ternet, any particular mechanism a file system employs toman
3、age keys will fail to support many types of use.We propose separating key management from file systemsecurity, letting the world share a single global file system nomatter how individuals manage keys. We present SFS, a se-cure file system that avoids internal key management. Whileother file systems
4、need key management to map file namesto encryption keys, SFS file names effectively contain publickeys, making them self-certifying pathnames. Key manage-ment in SFS occurs outside of the file system, in whateverprocedure users choose to generate file names.Self-certifying pathnames free SFS clients
5、 from any notionof administrative realm, making inter-realm file sharing triv-ial. They let users authenticate servers through a numberof different techniques. The file namespace doubles as a keycertification namespace, so that people can realize many keymanagement schemes using only standard file u
6、tilities. Fi-nally, with self-certifying pathnames, people can bootstrapone key management mechanism using another. These prop-erties make SFS more versatile than any file system withbuilt-in key management.1 IntroductionThis paper presents SFS, a secure network file system de-signed to span the Int
7、ernet. SFS prevents many vulnerabil-ities caused by todays insecure network file system proto-This research was partially supported by a National Science Foundation(NSF) Young Investigator Award and the Defense Advanced ResearchProjects Agency (DARPA) and Rome Laboratory under agreement numberF30602
8、-97-2-0288.Permission to make digital or hard copies of all or part of this work forpersonal or classroom use is granted without fee provided that copies arenot made or distributed for profit or commercial advantage, and that copiesbear this notice and the full citation on the first page. To copy ot
9、herwise, torepublish, to post on servers or to redistribute to lists requires prior specificpermission and/or a fee.SOSP-17 12/1999 Kiawah Island, SCca0 1999 ACM 1-58113-140-2/99/0012 . . . $5.00cols. It makes file sharing across administrative realms triv-ial, letting users access files from anywhe
10、re and share fileswith anyone. Most importantly, SFS supports a more di-verse range of uses than any other secure file system. Itcan meet the needs of software vendors, unclassified mili-tary networks, and even students running file servers in theirdorm rooms. In all cases, SFS strives to avoid cumb
11、ersomesecurity procedures that could hinder deployment.Few people use secure network file systems today, despitethe fact that attackers can easily tamper with network traffic.For years, researchers have known how to design and buildfile systems that work over untrusted networks (for instanceEcho 4).
12、 If such a file system could grow to span the Inter-net, it would let people access and share files securely withanyone anywhere. Unfortunately, no existing file system hasrealized this goal.The problem lies in the fact that, at the scale of the In-ternet, security easily becomes a management and us
13、abilitynightmare. Specifically, there exists no satisfactory means ofmanaging encryption keys in such a large and diverse net-work. The wrong key management policy harms security orseverely inconveniences people. Yet, on a global scale, dif-ferent people have vastly different security needs. No sing
14、leapproach to key management can possibly satisfy every user.Most secure systems limit their usefulness by settling for aparticular approach to key management. Consider how fewpeople run secure web servers compared to ordinary ones.Establishing a secure web server with SSL involves signif-icant time
15、, complexity, and cost. Similarly, in the domainof remote login protocols, anyone who has used both Ker-beros 29 and the decentralized ssh 34 package knows howpoorly the Kerberos security model fits settings in which useraccounts are not centrally managed. Unfortunately, most se-cure file systems co
16、me tightly coupled with a key manage-ment system that closely resembles either Kerberos or SSL.SFS takes a new approach to file system security: it re-moves key management from the file system entirely. SFSintroduces self-certifying pathnamesfile names that effec-tively contain the appropriate remot
17、e servers public key. Be-cause self-certifying pathnames already specify public keys,SFS needs no separate key management machinery to com-municate securely with file servers. Thus, while other filesystems have specific policies for assigning file names to en-124cryption keys, SFSs key management po
18、licy results from thechoice users make of which file names to access in the firstplace.SFS further decouples user authentication from the filesystem through a modular architecture. External programsauthenticate users with protocols opaque to the file systemsoftware itself. These programs communicate
19、 with the filesystem software through well-defined RPC interfaces. Thus,programmers can easily replace them without touching thecore of the file system.Pushing key management out of the file system lets ar-bitrary key management policies coexist on the same filesystem, which in turn makes SFS useful
20、 in a wide rangeof file sharing situations. This paper will describe nu-merous key management techniques built on top of SFS.Two in particularcertification authorities and passwordauthenticationboth fill important needs. Neither couldhave been implemented had the other been wired into thefile system
21、.Without mandating any particular approach to key man-agement, SFS itself also provides a great key managementinfrastructure. Symbolic links assign human-readable namesto self-certifying pathnames. Thus, SFSs global namespacefunctions as a key certification namespace. One can realizemany key managem
22、ent schemes using only simple file utili-ties. Moreover, people can bootstrap one key managementmechanism with another. In practice, we have found theability to combine various key management schemes quitepowerful.We implemented SFS focusing on three major goals: se-curity, extensibility, and portab
23、ility. We achieved portabil-ity by running in user space and speaking an existing net-work file system protocol (NFS 23) to the local machine.As a result, the SFS client and server software run on mostUNIX platforms. We sacrificed performance for portabilityin our implementation. Nonetheless, even f
24、rom user-space,SFS performs comparably to NFS version 3 on applicationbenchmarks. Several of the authors have their home directo-ries on SFS and perform all their work on it.2 DesignSFSs design has a number of key ideas. SFS names fileswith self-certifying pathnames that allow it to authenticateserv
25、ers without performing key management. Through amodular implementation, SFS also pushes user authentica-tion out of the file system. SFS itself functions as a conve-nient key management infrastructure, making it easy to im-plement and combine various key management mechanisms.Finally, SFS separates
26、key revocation from key distribution,preventing flexibility in key management from hindering re-covery from compromised keys. This section details the de-sign of SFS.2.1 GoalsSFSs goal of spanning the Internet faced two challenges: se-curity and the diversity of the Internet. Attackers can easilytam
27、per with network traffic, making strong security neces-sary before people can trust their files to a global file system.At the same time, SFS must satisfy a wide range of Inter-net users with different security needs. It is not sufficient forSFS to scale to many machines in theoryit must also sat-is
28、fy the specific needs of diverse users on the Internet today.In short, SFS needs three properties to achieve its goals: aglobal file system image, security, and versatility.2.1.1 Global file system imageSFSs goal of a single global file system requires that it lookthe same from every client machine
29、in the world. It mustnot matter which client a person uses to access her filesa global file system should behave the same everywhere.Moreover, no incentive should exist for sites to subvert theglobal image by creating an “alternate” SFS (for instance,out of the need to have a different set of server
30、s visible).To meet this goal, we stripped the SFS client software ofany notion of administrative realm. SFS clients have no site-specific configuration options. Servers grant access to users,not to clients. Users can have accounts on multiple, indepen-dently administered servers. SFSs global file sy
31、stem imagethen allows simultaneous access to all the servers from anyclient.2.1.2 SecuritySFS splits overall security into two pieces: file system se-curity and key management. SFS proper provides only filesystem security. Informally, this property means that attack-ers cannot read or modify the fil
32、e system without permission,and programs get the correct contents of whatever files theyask for. We define the term more precisely by enumeratingthe assumptions and guarantees that SFS makes.SFS assumes that users trust the clients they usefor in-stance, clients must actually run the real SFS softwa
33、re to getits benefits. For most file systems, users must also trust theserver to store and return file data correctly (though pub-lic, read-only file systems can reside on untrusted servers).To get practical cryptography, SFS additionally assumescomputationally bounded adversaries and a few standard
34、complexity-theoretic hardness conjectures. Finally, SFS as-sumes that malicious parties entirely control the network.Attackers can intercept packets, tamper with them, and in-ject new packets onto the network.Under these assumptions, SFS ensures that attackers cando no worse than delay the file syst
35、ems operation or concealthe existence of servers until reliable network communica-tion is reestablished. SFS cryptographically enforces all file125access control. Users cannot read, modify, delete, or oth-erwise tamper with files without possessing an appropriatesecret key, unless anonymous access i
36、s explicitly permitted.SFS also cryptographically guarantees that results of file sys-tem operations come from the appropriate server or privatekey owner. Clients and read-write servers always communi-cate over a low-level secure channel that guarantees secrecy,data integrity, freshness (including r
37、eplay prevention), andforward secrecy (secrecy of previously recorded encryptedtransmissions in the face of a subsequent compromise). Theencryption keys for these channels cannot be shortened toinsecure lengths without breaking compatibility.File system security in itself does not usually satisfy au
38、sers overall security needs. Key management lets the userharness file system security to meet higher-level securitygoals. The right key management mechanism depends onthe details of a users higher-level goals. A user may want toaccess a file server authenticated by virtue of a pre-arrangedsecret pas
39、sword, or else the file system of a well-known com-pany, or even the catalog of any reputable merchant selling aparticular product. No key management mechanism satisfiesall needs. Thus, SFS takes the approach of satisfying manykey management mechanisms; it provides powerful primi-tives from which us
40、ers can easily build a wide range of keymanagement mechanisms.2.1.3 VersatilitySFS should support as broad a range of uses as possiblefrom password-authenticated access to ones personal files tobrowsing well-known servers. In all cases, SFS must avoidunnecessary barriers to deployment. In particular
41、, anyonewith an Internet address or domain name should be able tocreate a new file server without consulting or registering withany authority.SFS achieves versatility with three properties: an egalitar-ian namespace, a powerful set of primitives with which toimplement key management, and modularity.
42、 Though SFSgives every file the same name on every client, no one con-trols the global namespace; everyone has the right to add anew server to this namespace.SFSs secure, global namespace also facilitates a broad ar-ray of key management schemes. One can implement manyschemes by simply creating and
43、serving files over SFS. SFSalso lets users employ arbitrary algorithms during file nameresolution to look up and certify public keys. Different userscan employ different techniques to certify the same server;SFS lets them safely share the file cache.Finally, SFS has a modular implementation. The cli
44、entand server are each broken into a number of programs thatcommunicate through well-defined interfaces. This architec-ture makes it easy to replace individual parts of the systemand to add new onesincluding new file system and user-authentication protocols. Several pieces of client functional-ity,
45、including user authentication, occur in unprivileged pro-cesses under the control of individual users. Users thereforehave a maximal amount of configuration control over the filesystem, which helps eliminate the need for clients to knowabout administrative realms.2.2 Self-certifying pathnamesAs a di
46、rect consequence of its design goals, SFS must cryp-tographically guarantee the contents of remote files withoutrelying on external information. SFS cannot use local con-figuration files to help provide this guarantee, as such fileswould violate the global file system image. SFS cannot re-quire a gl
47、obal authority to coordinate security either, as suchan authority would severely limit versatility. Individual usersmight supply clients with security information, but this ap-proach would make sharing a file cache very difficult be-tween mutually distrustful users.Without external information, SFS
48、must obtain file datasecurely given only a file name. SFS therefore introducesself-certifying pathnamesfile names that inherently spec-ify all information necessary to communicate securely withremote file servers, namely a network address and a publickey.Every SFS file system is accessible under a p
49、athname ofthe form a1a3a2a5a4a6a2a5a1 Locationa7 HostID. Location tells an SFSclient where to look for the file systems server, while HostIDtells the client how to certify a secure channel to that server.Location can be either a DNS hostname or an IP address.To achieve secure communication, every SFS server has apublic key. HostID is a cryptographic hash of that key andthe servers Location. HostIDs let clients ask servers for theirpublic keys and verify the authenticity of the reply. Knowingthe public key of a server lets a client communicate securelywith
