AI helps you reading Science
AI generates interpretation videos
AI extracts and analyses the key points of the paper to generate videos automatically
AI parses the academic lineage of this thesis
AI extracts a summary of this paper
This paper has introduced novel uses of cryptographic primitives applied to the problem of secure storage in the presence of untrusted servers and a desire for ownermanaged key distribution
Plutus: Scalable Secure File Sharing on Untrusted Storage
FAST, pp.29-42, (2003)
Plutus is a cryptographic storage system that enables secure file sharing without placing much trust on the file servers. In particular, it makes novel use of cryptographic primitives to protect and share files. Plutus features highly scalable key management while allowing individual users to retain direct control over who gets access to ...More
PPT (Upload PPT)
- As storage systems and individual storage devices themselves become networked, they must defend both against the usual attacks on messages traversing an untrusted, potentially public, network as well as attacks on the stored data itself.
- This is a challenge because the primary purpose of networked storage is to enable easy sharing of data, which is often at odds with data security.
- Stored data must be protected over longer periods of time than typical message round-trip times
- As storage systems and individual storage devices themselves become networked, they must defend both against the usual attacks on messages traversing an untrusted, potentially public, network as well as attacks on the stored data itself
- Since the same piece of data could be read by multiple users, when one user places data into a shared storage system, the eventual recipient of this “message”
- Because multiple users could update the same piece of data, a third user may from time-to-time update “the message” before it reaches its eventual recipient
- This paper introduces a new secure file system, Plutus, which strives to provide strong security even with an untrusted server
- This paper has introduced novel uses of cryptographic primitives applied to the problem of secure storage in the presence of untrusted servers and a desire for ownermanaged key distribution
- In an encrypted file system, the authors need techniques to (1) differentiate between readers and writers; (2) prevent destruction of data by malicious writers; (3) prevent known plaintext attacks with different keys for different files; (4) revoke readers and writers; and (5) minimize the number of keys exchanged between users.
- Aggregating keys into filegroups has the obvious advantage that it reduces the number of keys that users need to manage, distribute, and receive.
- Key aggregation is necessary to support semi-online users: as in today’s systems, Plutus assumes that users are frequently online, but not always
- This means that the authors need an easy mechanism to let an owner share a group of related files, so that the other user may be able to access the related files even when the owner is not online.
- If files were not aggregated and each file had its own key pair, from the measurements in Section 7, each create operation would incur a 2.5 seconds latency to generate the RSA key pair – in comparison, it takes 2.9 seconds to encrypt/decrypt a 20M file with 3DES
- This paper has introduced novel uses of cryptographic primitives applied to the problem of secure storage in the presence of untrusted servers and a desire for ownermanaged key distribution.
- The mechanisms described in this paper are used as building blocks to design Plutus, a comprehensive, secure, and efficient file system.
- Almost all of Plutus’ cryptography is performed on clients, not servers, so Plutus has superior scalability along with stronger security
- Table1: Attacks tabulated against what is changed following a revocation. The heading row presents different choices in the component that is changed following a revocation: the read/write verification token is changed (T), the file’s lockbox is changed (L), or the file itself is re-encrypted with a new key (D). The entries in the table correspond to the most serious attack that can be mounted, the letter code corresponding to those described in the main text. “n/a” indicates an impossible combination – such as readers having updated keys but files not being re-encrypted or lockboxes not changed. A “–” is used to denote that no attack is possible
- Table2: Using filegroups to aggregate keys
- Table3: Parameters of the system that affect revocation. These are statistics indicating the number of files in a single filegroup owned by a user, the total size of all these files, the number of other users who have read permission to at least one of these files, and the number of other users who have write permission to at least one of these files. The number of readers and writers were determined by considering the accesses in the 10-day trace, while the static information was gathered by considering a snapshot of the filesystem taken at the end of the 10 days. The table separates statistics for regular users and system users
- Table4: Cryptographic primitive cost. This table lists the cost of the basic cryptographic primitives, and the file systems operations where they are incurred. The root signature and verification is done only once per file read or write, irrespective of the size of the file. Wire integrity is needed only for messages, not for file contents
- Table5: Performance of Plutus, OpenAFS (version 1.2.8) and SFS (version 0.7.2) accessing 40 MB files with random and sequential access. The crypto option for Plutus indicates the cipher used for block encryption; the OpenAFS crypto option indicates whether it uses wire-crypto or not; SFS uses wire-crypto. OpenAFS uses fcrypt [<a class="ref-link" id="c3" href="#r3">3</a>] for block encryption whereas SFS uses ARC4 . The version of Plutus w/o crypto still performed all the operations required to manage and maintain the Merkle hash tree; the results indicate that this overhead is small
- Most file systems including those in MS Windows, traditional UNIX systems, and secure file systems [19, 22, 30] do not store files encrypted on the server. Of course, the user may decide to encrypt files before stor- File systems
Plutus OpenAFS SFS
Crypto options w/ 3DES cipher w/ DES cipher w/o crypto w/o wire-crypto w/ wire-crypto w/ crypto Read seq rand
7.84 s 4.58 s 1.39 s 1.28 s 4.66 s 5.55 s
7.78 s 4.54 s 1.51 s 1.31 s 4.90 s 5.30 s Write seq rand
7.92 s 4.27 s 1.59 s 1.57 s 5.34 s 4.47 s
8.13 s 4.79 s 2.64 s 1.67 s 5.43 s 7.21 s age but this overwhelms the user with the manual encryption/decryption and sharing the file with other users – while trying to minimize the amount of computation. This is precisely the problem that Plutus addresses.
Though MacOS X and Windows CIFS offer encrypted disks, they do not allow group sharing short of sharing a password.
- A. Adya, W. Bolosky, M. Castro, G. Cermak, R. Chaiken, J. Douceur, J. Howell, J. Lorch, M. Theimer, and R. Wattenhofer. FARSITE: Federated, available, and reliable storage for an incompletely trusted environment. In OSDI, pages 1–14, December 2002.
-  K. Fu, M. Kallahalla, and R. Swaminathan. A simple protocol for maintaining fork consistency. Manuscript, 2002.
-  G. Ganger and M. Kaashoek. Embedded inodes and explicit grouping: Exploiting disk bandwidth for small files. In USENIX Tech. Conf., pages 1–17, 1997.
-  N. Alon, H. Kaplan, M. Krivelevich, D. Malkhi, and J. Stern. Scalable secure storage when half the system is faulty. In ICALP, 2000.
-  T. Anderson. Specification of FCrypt: Encryption for AFS remote procedure calls,. http://www.transarc.ibm.com/ota/fcrypt-paper.txt.
-  M. Bellare, R. Canetti, and H. Krawczyk. Keying hash functions for message authentication. In CRYPTO, pages 1–15, 1996.
-  M. Blaze. A cryptographic file system for UNIX. In CCS, 1993.
-  D. Boneh. Twenty years of attacks on the RSA cryptosystem. Notices of the AMS, 46, 1999.
-  M. Castro and B. Liskov. Proactive recovery in a Byzantine-fault-tolerant system. In OSDI, pages 273–288, October 2000.
-  G. Cattaneo, G. Persiano, A. Del Sorbo, A. Cozzolino, E. Mauriello, and R. Pisapia. Design and implementation of a transparent cryptographic file system for UNIX. Technical report, University of Salerno, 1997.
-  G. Ganger, P. Khosla, M. Bakkaloglu, M. Bigrigg, G. Goodson, S. Oguz, V. Pandurangan, C. Soules, J. Strunk, and J. Wylie. Survivable storage systems. In DARPA Information Survivability Conference and Exposition, IEEE, volume 2, pages 184–195, June 2001.
-  D. Gifford, R. Needham, and M. Schroeder. The Cedar file system. In CACM, pages 288–298, March 1988.
-  H. Gobioff, D. Nagle, and G. Gibson. Embedded security for network-attached storage. Technical Report CMU-CS-99-154, CMU, June 1999.
-  H. Gobioff, D. Nagle, and G. A. Gibson. Integrity and performance in network attached storage. Technical Report CMU-CS-98-182, CMU, December 1998.
-  E. Goh, H. Shacham, N. Modadugu, and D. Boneh. SiRiUS: Securing remote untrusted storage. In NDSS, 2003. To appear.
-  J. Howard, M. Kazar, S. Menees, D. Nichols, M. Satyanarayanan, R. Sidebotham, and M. West. Scale and performance in a distributed file system. ACM TOCS, 6(1), February 1988.