Tahoe – the Least-Authority Filesystem
Total Page：16
File Type：pdf, Size：1020Kb
Tahoe – The Least-Authority Filesystem Zooko Wilcox-O’Hearn Brian Warner allmydata.com allmydata.com 555 De Haro St. 555 De Haro St. San Francisco, CA 94107 San Francisco, CA 94107 [email protected] [email protected] ABSTRACT are used in the allmydata.com service, are K = 3, N = 10, so Tahoe is a system for secure, distributed storage. It uses ca- each file is shared across 10 different servers, and the correct pabilities for access control, cryptography for confidentiality function of any 3 of those servers is sufficient to access the and integrity, and erasure coding for fault-tolerance. It has file. been deployed in a commercial backup service and is cur- The combination of cryptography and erasure coding min- rently operational. The implementation is Open Source. imizes the user's vulnerability to these servers. It is an un- avoidable fact of life that servers can fail, or can turn against Categories and Subject Descriptors: D.4.6 [Security their clients. This can happen if the server is compromised and Protection]: Access controls; E.3 [Data Encryp- through a remote exploit, subverted by insider attack, or if tion]: Public key cryptosystems; H.3 [Information Sys- the owners of the server are required by their government to tems]: Information Storage and Retrieval; E.4 [Coding change its behavior, as in the case of Hushmail in 2007 [29]. and Information Theory]: Error control codes Tahoe's cryptography ensures that even if the servers fail General Terms: Design, Human Factors, Reliability, Se- or turn against the client they cannot violate confidentiality curity by reading the plaintext, nor can they violate integrity by Keywords: capabilities, fault-tolerance, open source, peer- forging file contents. In addition, the servers cannot violate to-peer freshness by causing file contents to rollback to an earlier state without a collusion of multiple servers. 1. INTRODUCTION Tahoe is a storage grid designed to provide secure, long- term storage, such as for backup applications. It consists 2. ACCESS CONTROL of userspace processes running on commodity PC hardware Tahoe uses the capability access control model [6] to man- and communicating with one another over TCP/IP. Tahoe age access to files and directories. In Tahoe, a capability was designed following the Principle of Least Authority [21] is a short string of bits which uniquely identifies one file or { each user or process that needs to accomplish a task should directory. Knowledge of that identifier is necessary and suf- be able to perform that task without having or wielding more ficient to gain access to the object that it identifies. The authority than is necessary. strings must be short enough to be convenient to store and Tahoe was developed by allmydata.com to serve as the transmit, but must be long enough that they are unguess- storage backend for their backup service. It is now in oper- able (this requires them to be at least 96 bits). ation and customers are relying on the Tahoe grid for the Such an access scheme is known as \capabilities as keys" safety of their data. Allmydata.com has released the com- or \cryptographic capabilities" [22]. This approach allows plete Tahoe implementation under open source software li- fine-grained and dynamic sharing of files or directories. cences [1]. The Tahoe filesystem consists of files and directories. Files The data and metadata in the filesystem is distributed can be mutable, such that their contents can change, includ- among servers using erasure coding and cryptography. The ing their size, or immutable, such that they are writable only erasure coding parameters determine how many servers are once. used to store each file { denoted N, and how many of them Each immutable file has two capabilities associated with are necessary for the file to be available { denoted K. The it, a read capability or read-cap for short, which identifies default settings for those parameters, and the settings which the immutable file and grants the ability to read its content, and a verify capability or verify-cap, which identifies the im- mutable file and grants the ability to check its integrity but not to read its contents. Permission to make digital or hard copies of all or part of this work for For mutable files, there are three capabilities, the read- personal or classroom use is granted without fee provided that copies are write-cap, the read-only-cap, and the verify-cap. not made or distributed for profit or commercial advantage and that copies Users who have access to a file or directory can delegate bear this notice and the full citation on the first page. To copy otherwise, to that access to other users simply by sharing the capability. republish, to post on servers or to redistribute to lists, requires prior specific Users can also produce a verify-cap from a read-cap, or pro- permission and/or a fee. StorageSS’08, October 31, 2008, Fairfax, Virginia, USA. duce a read-only-cap from a read-write-cap. This is called Copyright 2008 ACM 978-1-60558-299-3/08/10 ...$5.00. diminishing a capability. 3. ERASURE CODING read-cap All data is erasure coded using Reed-Solomon codes over encryption verify 8 data GF (2 ) [28]. When writing, a writer chooses erasure cod- key cap ing parameters N { the total number of shares that will be (plaintext) written { and K { the number of shares to be used on read. Using this codec allows an efficient byte-wise implemen- AES ciphertext tation of encoding and decoding, and constrains the choice Merkle tree sha256d of erasure coding parameters to be 1 <= N <= 256 and data 1 <= K <= N. (ciphertext) Compared to erasure codes such as Tornado Codes [5], ciphertext root Reed-Solomon codes offer optimal storage overheard { ex- FEC share root actly b blocks of erasure code data (plus metadata { the in- share dex number of each block) are necessary to decode a b-block Merkle tree Capability Extension Block file. On the other hand, Reed-Solomon codes suffer from shares asymptotically worse computational complexity { the time to encode or decode a file with a Reed-Solomon codec is in 2 the worst case proportional to N where N is the number of Figure 1: immutable file erasure code blocks. Other codes offer asymptotically faster encoding and decoding { O(N) computational complexity { but they impose storage overhead { more than b blocks are without being able to produce texts which would pass the in- necessary to reconstruct a b block file. Also, many of these tegrity check. This excludes symmetric integrity primitives faster codes are patented. such as Message Authentication Codes [19], and requires us In Tahoe we have learned that since K and N are small to use the more computationally expensive digital signatures and since our implementation of Reed-Solomon (\zfec") is [19]. fast [25], the measured computational cost of erasure coding An additional requirement that we impose on read-only- is low, and in fact is lower than the cost of the encryption caps and read-write-caps is that they are short enough to and secure hash algorithms. be conveniently used by humans, for example by being em- bedded in URLs. This requirement is not common in cryp- 4. CRYPTOGRAPHY tography, and satisfying it turns out to require some careful cryptographic constructions. 4.1 Requirements Tahoe is designed to run in software without requiring 4.2 Cryptographic Preliminaries \Trusted Computing" (also called \Treacherous Computing" In the description that follows a \secure hash", denoted [2]) hardware. Therefore, the only robust way to constrain H, always means SHA256d [8]. SHA256d(x) is equal to users or administrators from certain behavior such as unau- SHA256(SHA256(x)). This construction prevents length- thorizedly reading or altering files is to make such behavior extension attacks [26]. require secrets, and to withhold those secrets from people In addition, each time we use a secure hash function for a who are not authorized to perform those behaviors. Thus, particular purpose (for example hashing a block of data to cryptography. form a small identifer for that block, or hashing a master key In this section we will describe the access control require- to form a sub-key), we prepend to the input a tag specific ments of the different kinds of capabilities and how Tahoe to that purpose. This ensures that two uses of a secure hash satisfies those requirements using cryptographic techniques. function for different purposes cannot result in the same We want a verify-cap to enable its wielder to check the value. This is necessary to ensure that the root of a Merkle integrity of a file, but not to enable its wielder to learn the Tree can match at most one file, and it is a good hygienic file's plaintext. This way a user can delegate to some other practice in any case [15] [23]. entity (such as a backup service) the job of checking that a \Merkle Tree" always means a binary Merkle Tree [20] file is still correctly stored, without sacrificing confidential- using SHA256d as its secure hash, using one tag for the ity. secure hash function to generate an internal node from its A read-only-cap to a file has to give the ability to read children and another tag for the secure hash function to the plaintext of the file and also to verify its integrity. We generate a leaf from a segment of the file that the tree covers. also require that a holder of a read-only-cap to a file is able \Encrypt" always means encrypt using AES-128 in CTR to diminish it to produce a verify-cap to the same file.