CS252 Project TFS: An Encrypted File System using TPM

Transcription

1 CS252 Project TFS: An Encrypted File System using TPM Steven Houston: Thomas Kho: May 15, 2007 Abstract In this project, we implement a trusted file system that uses a Trusted Platform Module (TPM) to securely store file encryption keys. Key management is centralized; in this work, we identify the ability of a key server to verify deletion of file encryption keys on clients to reduce the amount of re-encryption necessary on key revocation. We place the TPM on the read datapath and encrypt files with RSA. In benchmarking performance, we found that read and write performance were orders of magnitude slower than without encryption. Software decryption was about twice as fast as hardware decryption via TPM. 1 Introduction Trusted Platform Modules (TPMs) are microcontrollers with shielded non-volatile storage that are capable of cryptographic functions including key/random number generation, asymmetric encryption (RSA), and secure message authentication (HMAC). TPMs allow authenticated sessions with two mechanisms, Object-Independent Authorization Protocol (OIAP) and Object-Specific Authorization Protocol (OSAP). The two mechanisms are similar, so we discuss the features of OIAP. OIAP allows remote authenticated operations of the TPM on entities (e.g. keys) via HMACs of a shared secret and the operands to an operation. Nonces are established with each message exchange to prevent replay. Implementing access control in distributed storage systems is quite difficult and is an active area of research. In an encrypted distributed file system, encrypted files are stored on remote and possibly malicious storage servers. Traditionally, the clients keep all encryptions keys for the files they own or have proper access to. The main drawback with this setup is that read access revocation (revoking a client s read access to a file) always requires the re-encryption of the file with a new key. We would like a method to 1

2 somehow revoke the decryption key, thereby eliminating a client s ability to decrypt a particular file in the future even though the file is encrypted with the same key. In this project, we consider how TPMs can be used in distributed storage systems to revoke read and write access by revoking keys and reducing the necessity to re-encrypt files. 2 TPM Details Throughout this section and the remainder of the paper, the term key refers to a bit RSA key pair. The terms secret key and public key will refer to the appropriate portions of the asymmetric key pair. Keys on a TPM form a hierarchy, where each key (except for the SRK) has a parent. The SRK (Storage Root Key), as its name suggests, is at the root of the hierarchy, with all other keys underneath it. Each key has a key handle, which is a publicly known integer unique to a particular key, identical in nature to a file handle. Both the secret and public portion of a key are stored on the TPM, and access to either of them requires an application to properly authenticate via a key password. By providing the key password, an application will be able to view the public key and use (encrypt/decrypt with) but not view the secret key. The information contained in secret keys is never revealed in any unencrypted form outside of the TPM. Keys can either be created in software or by the TPM. If an application requests that the TPM create a key, it must choose a key password, a parent for the key and specify the handle and password of the parent. The TPM creates the key internally using its random number generator and then wraps (encrypts) the concatenation of the key and key password with the parent s public key. This wrapped key is returned to the application, but the key will not remain in the TPM s storage until it is loaded. Note that knowledge of the parent key s handle and password are not required to create the wrapped key in software, as only the parent s public key is needed. When an application wishes to load a key into the TPM, it must submit to the TPM a wrapped key along with the parent key s handle and password. The TPM will then decrypt the wrapped key and store the unwrapped key and key password in secure NVRAM. Future applications can use the secret key only if it is able to authenticate with knowledge of the key password, but in no case can it actually view the secret key. 3 Design 3.1 System Components In this section, we briefly describe the roles of the storage system, clients, and key servers Storage System The storage system is, in general, a heterogeneous system of storage servers distributed over some network. We are mainly concerned with the interaction between clients and key servers, and place few assumptions on the storage system that keep encrypted file data. 2

3 Thus, how the storage servers store the encrypted data is of no concern to us. Some portions of the storage system may be malicious, so we place no trust in any particular component of the storage system Client The client is a machine with a TPM that wishes to read files encrypted via asymmetric encryption. The private portion of keys, when stored on the client, are protected inside the TPM. Users on the client machine cannot access the private keys for decryption directly. Users can, however, store the public key outside the TPM and use it for software encryption of files Key Server The key server is a trusted machine (or small group of trusted machines) that keeps track of the keys distributed in the system and is the point-of-contact for all clients that need to checkout a read decryption or write signature key. When a client s access is revoked, the server attempts to verify (via the TPM session log) that the corresponding private key has been unloaded from the TPM (proving the client can no longer decrypt the associated file). Only when the client is uncooperative (and the client continues to keep a copy of the key checked out) will the server re-encrypt the files in the storage system with a new key. 3.2 Client-Server Interaction Client Verification We first discuss how the key server verifies that it is communicating with an authentic TPM. Before the server wraps keys for the client TPM using the storage rook key (SRK) public key, it must be sure that the public key it receives from the client is actually the SRK public key of the client s TPM and not a fake key the client created. We propose doing this via the logged transport session mechanism signed by the endorsement key of the client s TPM (the endorsement key is unique for each TPM and cannot be changed). The SRK public key signed by the TPM s endorsement key is equivalent to a third-party CA certificate. Alternatively, we could have preestablished an owner password on the TPM known only to the server. This would have allowed retrieval of the SRK from the TPM, with the server being ensured that the SRK public key request was handled by the correct TPM and not faked by the client because of OSAP authentication Checking Out Keys Figure 11 shows how a client application checks out keys from the key server. By checking out a key from the key server, the client can then use that key via the TPM (and only within the TPM) for decryption and signing of files. The client first requests an applicationspecific master key from the key server (1). 3

4 Figure 1: Interaction of the client and key server when checking out keys. The server then creates a master key wrapped with the client TPM s SRK public key and returns the wrapped master key to the client (2). This key will be the parent key for all file keys granted to the client by the server. Steps (1) and (2) are performed only once per application. When the client desires to access a file, it requests a file key from the server (3). The server takes the unwrapped file keypair from its stable storage and then wraps it with the master public key. This wrapped object key is loaded into the client s TPM by the server via an OIAP session (4) and the client TPM returns the handle to the server (5), which Figure 2: The client application only sees wrapped (encrypted) keys. The corresponding private keys for decryption are always stored secretly in the TPM. then returns the handle to the client (6). The client can only see a file key wrapped by the master key, so it cannot load the file key as a child of any other key. This means that even though the client knows the SRK password, it is unable to load the file key as a child of the SRK whenever it wants. Furthermore, the client does not know the master key password and, as such, the client cannot itself load file keys (and in particular, replay loading of file keys) Verifying Key Deletion When a client wishes to deletes a key, there are two methods depending on whether or not the client is online. 4

5 If the client is online, the client can request the server initiate key deletion via a remote OIAP session. The server receives verification of key deletion via HMAC based on a shared secret between the TPM and the server. If the client is offline, the client can evict the key in a logged transport session so that the server can later verify that the key was indeed deleted from the TPM. This accounting reduces the amount of re-keying on key revocation Key Revocation When a key is revoked in the system, the key server checks to see if any of the clients who currently have the key checked out have been revoked access. If not, then no action needs to be taken. If so, the server will use the methods of above to verify key deletion on the client. Only when the client is offline or uncooperative must the key server create a new file key and then re-encrypts the file in the storage system with the new key. 4 Implementation We describe the software and hardware components of our system that reside on both the client and server. We used open-source file system components and TPM tools, and tested our system on Apple MacBook Pro machines with Infineon SLB 9635 TT 1.2 TPM chips. The Infineon TPM 1.2 is a 16-bit microprocessor made on a 0.22 um process that complies with the TCG 1.2 specification. It has a single 33 MHz clock, 24 Platform Configuration Registers (PCRs), 10 key slots, 1.5 KB of general-purpose NVRAM, a cryptographic engine with up to 2048-bit RSA keys supported, a hashing engine with hardwareaccelerated SHA-1, a true random number generator, a tick counter with tamper detection Client We implement a filesystem interface using several open-source packages and libraries: MacFuse, Fuse-J and TPM/J. We used a Mac OS X kernel module (called a kext) written by Amit Singh [reference here] to communicate with the TPM. The module is a driver, and when loaded into the kernel, it exposes the TPM via the special device /dev/tpm. TPM/J is a library of Java classes containing several useful high-level TPM routines. These classes, such as TPMCreateKey and TPMLoadKey, provide an object-oriented interface to interact directly with the TPM kernel driver via /dev/tpm. This library was extremely useful as the interface provided by the driver was too low-level to be efficiently utilized. MacFuse is a library and kernel module that allows mounting of userland file system drivers in Mac OS X. It is basically Fuse but modified to work for Mac OS X. Userland file systems mean that 5

6 Figure 3: Implementation of TFS on MacOS X all filesystem functions (such as read and getattr) are implemented in userprovided code. Fuse creates the special device /dev/fuse that allow communication between the Fuse library and kernel module. Fuse-J is a Java binding to MacFuse that allows us to implement our userspace filesystem in Java. Because the TPM/J provides all the useful library routines in Java, this turned out to be a small but crucial part of our implementation. We did not implement the log verification of the storage root key as described in Key Server The key server does not require direct access to its own unique TPM; it only communicates with clients TPMs. Accordingly, we implement the server as a Java object accessible by clients through the thin interface a networkconnected server would expose. In a real implementation, the performance overhead of communicating to the server over the network would be small compared to the time spent decrypting/encrypting files by the client. 5 Evaluation We benchmarked our filesystem using Iozone on the Mac OS X. We looked at small file sizes ( 32 KB) because the maximum throughput of our encrypted filesystem is reached rather quickly. All of the results have caching disabled in the Iozone benchmark. This is because the original benchmark failed to call the Fuse implemented read function that decrypted the file and instead used the dirty block recently written to cache. The block size of the files is set to 128 bytes, which was strictly required to be less than the 2048-bit 6

7 Figure 4: Performance of read access to existing file. Figure 5: Performance of read access to recently read file. RSA key. As seen in the graphs, the performance of our implementation suffered. The read performance to existing files and to recently read files is shown in Figures 4 and 5, respectively. The write performance both to new files and existing files is shown in Figures 6 and 7, respectively. Random read performance is shown in Figure 8 and random write performance is shown in Figure 9. In the write performance graphs, we compare no encryption (but with the baseline MacFuse filesystem) versus encryption in software. Notice that there is no need for encryption to be done in the TPM. In the read performance graphs, we compare no decryption (again with the baseline MacFuse filesystem) versus decryption in software versus decryption on the TPM chip. All of these graphs clearly show that our encrypted file system performs magnitudes of order worse than the unencrypted file system regardless of what type of read or write is being performed. Figure 10 shows that RSA encryption performs much better than RSA decryption, independent of whether or not the decryption is done in hardware or software. This is unfortunate because it shows that the operation we care about tuning the most (decryption) is the costliest. Figure 11 shows that the benchmark with decryption in hardware using the TPM chip fared about 2 times slower than the benchmark with decryption in software. This is very encouraging, as it is much better than the slowdown factor of about 125 when we strictly measuring software decryption (75 MB/sec) vs TPM decryption (600 B/sec) outside the filesystem environment. This implies that a significant amount of work is still done outside the TPM such that it s decryption overhead is amortized. Our implementation was only a prototype, 7

8 Figure 6: Performance of write access to new file. Figure 7: Performance of write access to recently written file. and several bottlenecks led to the performance degradation. First, all file decryption (reads) takes place within the TPM. For RSA encryption, the file is split into 128 byte blocks, and each block is decrypted/encrypted separately. For much larger reads of 4 KB, which is still extremely small compared to most files, the overhead of breaking the file into blocks and decrypting them separately is substantial. 6 Related Work Sarmenta et al. [6] apply logged transport sessions to implement trusted monotonic counters. Third parties can verify the current value of a monotonic counter, and a client can produce a chain of logs of each time the monotonic counter is incremented. We borrow from this idea of using logged transport sessions to verify actions taken by the TPM. Chun [2] introduces a trusted compo- nent called Attested Append-Only Memory and shows improvements to fault tolerance in distributed systems. Plutus [3] and OceanStore [5] are distributed storage systems with distributed key management. Both systems assume untrusted file servers and implement client-side security. In OceanStore, files have an owner identified with by public key which secures an ACL that gives write permission. Plutus employs lazy revocation, which delays reencryption of files until they are modified. BitLocker Drive Encryption [4] for Windows Vista and ecryptfs [1] for Linux provide whole-disk symmetric encryption, enabling use of the disk via password verification of the TPM where the symmetric key is bound in stable storage. However, all current techniques at some point rely on a trusted OS, something we cannot assume since we wish to occasionally revoke read access on potentially malicious clients. Because the symmet- 8

9 Figure 8: Performance of random read access. ric key is eventually loaded into memory in BitLocker and ecryptfs, a root exploit unnoticed by system administrators can reveal the key. 7 Future Work In this project, we showed that it was possible to implement an encrypted storage system where a trusted key server could be assured that clients deleted their decryption keys. We propose future work to evolve this into a usable system. The current implementation only encrypts file data, and a practical extension would be to additionally encrypt the accompanying file metadata. We use an in-memory object store; it would be instructive to analyze performance if the backing store were a distributed storage system. Our trusted server is currently implemented as a Java object with a strict interface between it and the client and strong encapsulation; measuring the effect of Figure 9: Performance of random write access. network performance of an standalone server maybe fruitful. Our original motivation was to improve the state of key revocation in distributed storage systems. Modeling the reduction in re-keying of files given verified key deletion on clients would provide further impetus for this work. The file read/write experiments were conducted with one file key for all files. Because of the limited number of keys able to be stored in the TPM and the strict check-out policy of the key server, future work would be to look at 1) the granularity of file keys and the result on performance and 2) the management of keys to reduce the impact of exchanging file keys with the key server. Performance of the TPM was limiting, but software RSA key generation was also an impediment; the use of cryptographic accelerators may help on this front. Finally, we need to better detail the revocation of write access. In our current implementation, readers are writers and vice-versa. 9

10 Figure 10: Analysis of RSA encryption vs RSA decryption runtimes. Figure 11: hardware. RSA decryption in software vs One such strategy implemented in several existing systems is to have the notion of an owner of a file that controls read write access. 8 Conclusion We proposed and implemented a trusted file system that used the TPM to securely store file encryption keys. Our design contained a trusted key server that keeps track of keys on client machines. Benchmarking showed that performance was orders of magnitude slower when encryption was enabled. Further, hardware decryption was about one-half the speed of software encryption. With the growing need to protect sensitive documents, we see a place for secure symmetric encryption on TPMs and cryptographic co-processors that would enable the realization of our trusted file system design. References [1] ecryptfs. [2] B. Chun. Improving the fault tolerance of distributed systems with attested append-only memory. [3] M. Kallahalla, E. Riedel, R. Swaminathan, Q. Wang, and K. Fu. Plutus scalable secure file sharing on untrusted storage, March [4] Microsoft. Windows vista bitlocker drive encryption: Executive overview. [5] S. Rhea, P. Eaton, D. Geels, H. Weatherspoon, B. Zhao, and J. Kubiatowicz. Pond: The oceanstore prototype. In Proceedings of the Conference on File and Storage Technologies. USENIX, [6] L. Sarmenta, M. van Dijk, C. O Donnell, J. Rhodes, and S. Devadas. Virtual monotonic counters and count-limited objects 10

11 using a tpm without a trusted os (extended version),