Group Sharing and Random Access in Cryptographic Storage File Systems by Kevin E
Total Page:16
File Type:pdf, Size:1020Kb
Group Sharing and Random Access in Cryptographic Storage File Systems by Kevin E. Fu B.S. Computer Science and Engineering MIT, 1998 Submitted to the Department of Electrical Engineering and Computer Science in Partial Fulfillment of the Requirements for the Degree of Master of Engineering in Electrical Engineering and Computer Science at the MASSACHUSETTS INSTITUTE OF TECHNOLOGY CHUSEU9ISTITUTE OF TECHNdLOGY June 1999 © 1999 Kevin E. Fu. All rights reserved. The author hereby grants to MIT permission to reproduce and distribute publicly paper and electronic copies of this thesis docn CHUSETS INSTITUTE in whole or in part. A uthor .................. I Department of Electrical Engineering and Computer Science ,, May 18, 1999 C ertified by .............................. Ronald L. Rivest E. S. Webster Professor of Electrical Engineering and Computer Science Thestiq Sypervisor Accepted by.......... 7... Arthur C. Smith Chairman, Department Committee on Graduate Students 2 Group Sharing and Random Access in Cryptographic Storage File Systems by Kevin E. Fu Submitted to the Department of Electrical Engineering and Computer Science on May 18, 1999 in Partial Fulfillment of the Requirements for the Degree of Master of Engineering in Electrical Engineering and Computer Science Abstract Traditional cryptographic storage uses encryption to ensure confidentiality of file data. However, encryption can prevent efficient random access to file data. Moreover, no cryptographic storage file system allows file sharing with similar semantics to UNIX group sharing. The Cryptographic Storage File System (Cepheus) provides confiden- tiality and integrity of data while enabling efficient random access and file sharing using mechanisms similar to UNIX groups. Cepheus uses a delayed-write-encryption policy for caching, delayed re-encryption for distributed re-encryption, and a hash tree structure beneath the inode for integrity. While maintaining confidentiality and integrity, the cost of reading a block is 0(1) amortized over a sequential read of the entire file of n blocks. Writes execute in worst-case O(log n) time. Thesis Supervisor: Ronald L. Rivest Title: E. S. Webster Professor of Electrical Engineering and Computer Science 3 Acknowledgments Sivaramakrishnan Rajagopalan and Bill Aiello guided my work on cryptographic stor- age at Telcordia Technologies (formerly Bellcore) in Morristown, New Jersey. Ron Rivest endowed much advice as my on-campus thesis advisor. Their guidance and sug- gestions greatly improved the design of Cepheus. Telcordia Technologies supported my research with a graduate fellowship in the MIT VI-A program. Portions of Cepheus code derive from David Mazieres' Secure File System of the Parallel and Distributed Operating Systems Group at the MIT Laboratory for Com- puter Science[22]. Parts of the low-level file system originated from my 6.033 team's X-File System[12]. Drew Samnick implemented many of the Remote Procedure Calls for his Advanced Undergraduate Project. Other persons deserving credit for help or guidance include Derek Atkins, Giovanni Di Crescenzo, Neil Haller, Sam Hartman, Jeff Hu, Frans Kaashoek, Marcus Kuhn, Anna Lysyanskaya, and Jerome Saltzer. Fi- nally, my fiancee, Teresa, deserves much gratitude for putting up with my midnight coding and bitter moods during this long ordeal. Just one more degree, I promise. 4 Contents 1 Introduction 13 1.1 Background: UNIX File Systems . ..... ..... ..... .... 14 1.2 Motivation .. ...... ...... ...... ...... ....... 18 1.3 Focus . ..... ..... .... ..... ..... ..... ..... 20 1.3.1 Group Sharing .... ...... ..... ...... ..... 20 1.3.2 Random Access .... ..... .... ..... ..... ... 21 1.4 Related Work: Case Studies . ..... ..... ..... ..... .. 21 1.4.1 Cryptographic File System .... ..... ...... ..... 22 1.4.2 Secure FileSystem .. ...... ..... ...... ...... 26 1.4.3 Transparent Cryptographic File System .. ..... ..... 28 1.4.4 SecureDrive ... .... ..... .... ..... ..... .. 29 1.4.5 SecureDevice .. ... .... .... .... .... .... .. 31 1.4.6 CryptDisk .. .... .... .... ... .... .... .... 32 1.5 Common Features .... ...... ...... ...... ....... 33 1.5.1 Key Management & Sharing ... ....... ........ 33 1.5.2 Portability . ...... ...... ..... ...... ..... 33 1.5.3 Transparency ... .... .... .... .... ... .... 34 1.5.4 Encryption Costs ... .... ... .... .... .... ... 34 1.5.5 Fine-grained Access Control . .... .... .... .... .. 34 1.5.6 Key Changes & Revocation .... .... ..... ..... 35 1.5.7 Intrusion Tolerance . ..... ..... .... ..... .... 35 1.5.8 Reliability . .... .... .... .... .... ... .... 35 5 1.5.9 Trust in System Administrators ....... ....... .. 35 1.5.10 Integrity .... ........ ........ ........ 36 2 Design Requirements 37 2.1 Design Criteria ............................. 37 2.1.1 Confidentiality . .... .... .... .... .... .... 3 7 2.1.2 Integrity .............. 38 2.1.3 Availability ...... ...... 38 2.1.4 Secure Group Sharing .. .... 38 2.1.5 Efficient Random Access ..... 39 2.2 Failure Conditions .. .......... 39 2.2.1 Intolerable Failures . ....... 39 2.2.2 Tolerable Failures ....... .. 39 2.3 Cryptographic Storage Trust Model . .. 40 2.3.1 Trust Model Principals ...... 40 2.3.2 Confidentiality .......... 41 2.3.3 Integrity .............. 42 2.3.4 Availability ............ 43 2.3.5 Group Sharing ........ .. 44 3 Cepheus Design 47 3.1 Group Sharing .............. 47 3.2 Random Access .............. 48 3.2.1 Delayed Re-encryption ...... 50 3.2.2 Buffer Cache: Delayed Encryption 51 3.3 File System Structures .......... 51 3.3.1 Inodes ............... 51 3.3.2 Authenticity/Integrity Check Field 52 3.3.3 Crash Recovery .......... 54 3.4 Client Daemon .............. 55 3.4.1 Buffer Cache ........... 55 6 3.4.2 File Server Communication ....... ........ 56 3.5 User Agent ..... .... ..... ..... ..... ..... 56 3.6 File Server .. ...... ..... ...... ...... ...... 57 3.7 Group Database Server ..... ..... ..... ..... ..... 58 3.8 Design Alternatives ..... ....... ...... ...... .... 60 3.8.1 Ciphers .. ...... ...... ..... ...... ..... 60 3.8.2 Initialization Vector ..... ...... ...... ...... 61 3.8.3 Authenticity/Integrity Check Field .. .... ... .... .. 61 3.8.4 Delayed Re-encryption ..... .... ..... ..... ... 63 3.8.5 Buffer Cache .... ..... ..... .... ..... .... 63 4 Implementation Details 65 4.1 User Agent .... ..... ..... ..... ..... ..... ... 65 4.2 Client Daemon ..... ...... ...... ...... ....... 65 4.3 File Server .. .... ..... .... .... .... .... .... .. 67 4.4 Group Database Server ... .... .... .... .... .... ... 67 4.5 Status . .... .... .... ..... .... .... .... .... 68 5 Questions for Cryptographic Storage 71 5.1 Network Versus Storage Encryption ..... ..... ..... .... 71 5.2 File Permissions ... .... .... ..... .... .... ..... 72 5.3 Group Sharing .... .... ... .... ... .... ... .... 72 5.4 Incremental Cryptography . .... .... .... .... .... ... 73 5.5 Delayed Re-encryption .. .... .... .... .... ..... ... 73 5.6 Integrity . .... ... .... ... .... ... .... ... .... 73 5.7 Orphaned Directories .. .... ... ... ... ... .... ... .. 74 5.8 Brittleness ... ... ... ... ... ... ... ... ... .... .. 74 5.9 Encrypted Swap File . ... ... ... ... ... .... ... ... 75 5.10 Key Rings .. ... ... ... .. ... ... ... .. ... ... ... 75 5.11 Trust of System Administrator . ... ... ... ... ... .... .. 75 5.12 Unattended Access . ... .. ... .. ... .. ... .. ... .. .. 75 7 6 Conclusion 77 8 List of Figures 1-1 The layout of data and metadata on the physical disk. .. ...... 14 1-2 The inode contains file attributes and pointers to data blocks. Singly and doubly indirect blocks allow a small inode to address a large am ount of file data. ..... ...... ..... ...... ...... 17 1-3 A complex example of a directory mapping file names to inodes. Thick boxes represent data blocks while thin boxes represent inodes. .... 18 1-4 This diagram of CFS is based on Blaze's paper and an article on cryp- tographic file systems[4, 35]. Dashed lines represent a confidential area protected by encryption. .... ...... ...... ..... 23 1-5 In Blaze's OFB+ECB mode, the OFB mode first computes interme- diate plaintext blocks IP offline. When a plaintext block P needs encryption, it is first XORed with IP, IV, and a function of the block number and seed. This is encrypted in ECB mode for the final ciphertext. 24 1-6 In Yerushalmi's OFB+ECB mode, the OFB mode first computes in- termediate plaintext blocks IP offline, as is done in Blaze's mode. When a plaintext block Pi needs encryption, it is first encrypted in ECB mode, then XORed with 1P. This allows for easier incremental changes. ........ .................................. 25 1-7 SFS interfaces to MS-DOS as a device driver with raw access to the physical disk. The thick dotted line represents confidential storage. 27 2-1 Interactions among the trust model principals in Cepheus. ... .. 41 9 3-1 The client daemon (CD) acts as an NFS loopback server on the client workstation. The CD asks the appropriate user agent (UA) to encrypt, decrypt, sign, or verify data. Each CD communicates with the appro- priate file server (FS). The FS checks with the group database server (GDS) for authentication and authorization of a user agent. The thick dotted line represents confidential storage. ... ...... ...... 48 3-2 In Cepheus, file data is encrypted in CBC mode on a per block basis. Block ciphers typically have two 8-byte inputs. ...... ...... 49 3-3 The data pointer contains an IV and hash node in addition to the pointer to the data block. .... ...... ...... ...... .. 49 3-4