CS252 Project An Encrypted File System using TPM

CS252 Project An Encrypted File System using TPM Steven Houston: shouston@eecs.berkeley.edu Thomas Kho: tkho@eecs.berkeley.edu May 14, 2007 Abstract We implement an encrypted file system that uses a Trusted Platform Module (TPM) to securely store file encryption keys. Key management is centralized. We identified 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 file-read datapath and encrypt files with RSA. In benchmarking filesystem performance, we found that read and write speeds 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 asymmetric key and random number generation, encryption and decryption, and monotonic counters [3]. TPMs allow authenticated sessions via 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 local and remote authenticated operations of the TPM on entities (e.g. keys) using hashed message authentication codes (HMACs) constructed from a shared secret and the operands to a TPM operation. Nonces are exchanged with each message to and from the TPM 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 storage servers with no assumptions regarding trust of these 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 ability to read a file) requires the reencryption of the file with a new key. We would like a method to verify the deletion of the decryption key, thereby eliminating a client s ability to decrypt a particular file in the future even though the file remains encrypted with the same key. In this project, we consider how TPMs can reduce the necessity to re-encrypt files on access 1

revocation by verifying deletion of keys. 2 TPM Details Throughout this section and the remainder of the paper, the term key refers to a 2048-bit RSA asymmetric key pair. The terms secret key and public key refer to the appropriate portions of the key pair. We use RSA key pairs because the TPM does not support symmetric key operations outside internal operations. 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 an integer value used as an index to the key in the TPM. Both the private 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 160-bit authentication data word we refer to as the key password. By providing the key password, an application is able to view the public key and use (i.e. encrypt and decrypt) but not view the private key. Generally, private keys are never revealed in any unencrypted form outside of the TPM. Keys can either be created by the TPM or in software for loading into the TPM. If an application requests that the TPM create a key, it must choose a key password, a parent for the key (specified by they parent s key handle) and the password of the parent. The TPM creates the key internally using its random number generator and then concatenates the private key and key password, wrapped (encrypted) with the parent s public key, with the 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. For wrapped keys created in software, 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 using the parent key and store the unwrapped key and key password in its shielded storage. 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. 3.1.1 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. 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. 3.1.2 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 2

keys for decryption directly. Users can, however, store the public key outside the TPM and use it for software encryption of files. 3.1.3 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. The server keeps track of all keys loaded on all clients; when a client s access is revoked, the server checks that the corresponding private key is not loaded on the revoked client s TPM, indicating that 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 3.2.1 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 an arbitrary RSA public key. 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 endorsement key can be verified authentic by a third party. Alternatively, we could have pre-established an owner password on the TPM known only to the server. This would have allowed retrieval of Figure 1: Interaction of the client and key server when checking out keys. 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. This approach has the restriction that only one application can have control of the TPM. 3.2.2 Checking Out Keys Figure 1 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 application-specific master key from the key server (1). The server 3

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 and only the server knows the key password to this master key. Steps (1) and (2) are performed only once per application, and the client can cache this key indefinitely. When the client desires access to 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 of the requesting client. This wrapped key is loaded into the client s TPM by the server via a remote OIAP session (4) and the client TPM returns the key handle to the server (5), which then returns the handle to the client (6). The client can only see a file key wrapped by the master key (see Figure 2), 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 will not be able to load the file key as a child of the SRK. 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). 3.2.3 Verifying Key Deletion When a client wishes to delete a key, we propose two methods depending on whether or not the client is online and can reach a key server. If the client is online, the client can request that the server initiate key deletion via a remote OIAP session. The server receives verification of key deletion via HMAC based on the shared secret between the TPM and the server. If the client is offline, the client can evict the Figure 2: The client application only sees wrapped (encrypted) keys. The corresponding private keys used for decryption are always stored secretly in the TPM. 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 frequency of re-encryption on key revocation. 3.2.4 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 may attempt to use one of the previous methods request verification of key deletion on the client. Only when the client is offline or uncooperative must the key server create a new file key and re-encrypt the file in the storage system. 4

4 Implementation We describe the software and hardware components of our system that reside on both the client and the server 1. 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 µm process that complies with the TCG 1.2 specification [3]. It has a single 33 MHz clock, 24 Platform Configuration Registers (PCRs), 10 key slots, 1.5 KB of generalpurpose NVRAM, a cryptographic engine with up to 2048-bit RSA keys supported, a hashing engine with hardware-accelerated SHA-1, a true random number generator, a tick counter with tamper detection. 4.1 Client We implement a filesystem interface using several open-source packages and libraries: Mac- Fuse, Fuse-J and TPM/J. We used a Mac OS X kernel module (called a kext) written by Amit Singh [9] 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 1 The source code for our project is available at http://www.eecs.berkeley.edu/ tkho/classes/252/ 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 all filesystem functions (such as read and getattr) are implemented in user-provided 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. The block size of the filesystem was set to 128 bytes, which was the largest power of two less than the 2048-bit RSA key. Therefore, each file is split into 128-byte blocks, and reading (writing) leads to decryption (encryption) of the appropriate block. We use local memory as the backing store for the filesystem. This is easier to implement and sufficient for benchmarking purposes. We did not implement the log verification of the storage root key as described in 3.2.1. 4.2 Key Server The key server does not require direct access to its own separate TPM; it only communicates with clients TPMs. Accordingly, we implement the server as a Java object accessible by clients through the thin interface a network-connected 5

Figure 3: Components of the filesystem implementation on MacOS X 10.4.7. server would expose. In a practical implementation with a remote key server, 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 [2] on Mac OS X. We looked at small file sizes ( 32 KB) because the maximum throughput of our encrypted filesystem was reached immediately (due to the low rate of block decryption by the TPM). All Iozone benchmarks were run with caching disabled. This is because the original benchmark failed to call the custom MacFuse read function when the dirty block recently written to cache was fetched. 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 Figure 4: Performance of read access to existing file. 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 6

Figure 5: Performance of read access to recently read file. Figure 6: Performance of write access to new file. 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 orders of magnitude slower than a comparable unencrypted file system regardless of the type of read or write 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. If the RSA encryption was performed in hardware, this result would be an artifact of the public exponent e = 2 16 + 1 being hardwired into the TPM to provide fast forward encryption. However, since our benchmarks used software encryption, we are unsure as to why the RSA software encryption performed approximately 60 times faster than the RSA software decryption, unless this is some mathematical property of the algorithms that we are unaware of. It is unfortunate that RSA decryption is so much slower than encryption, because RSA encryption is the single operation on our filesys- tem s critical path. 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 future modifications to TPM (such as a faster cryptoengine or support for symmetric encryption) could easily improve this slowdown to an acceptable value. Our implementation was only a prototype, and several bottlenecks led to the performance degradation. First, all file decryption (reads) takes place within a single bandwidth-limited TPM. Each file is split into small 128 byte blocks, and each block is decrypted/encrypted separately. For reads of only 4 KB, our filesystem must partition the read into 32 block decrypts. It is clear that the overhead of breaking the file into blocks and decrypting them separately becomes substantial with large files. 7

Figure 7: Performance of write access to existing file. 6 Related Work Sarmenta et al. [8] 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 [4] introduces a trusted component called Attested Append-Only Memory and shows improvements to fault tolerance in distributed systems. Plutus [5] and OceanStore [7] 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 by a public key which in turn secures an ACL that gives write permission. Plutus employs lazy revocation, which delays re-encryption of files until they are modified. BitLocker Drive Encryption [6] for Windows Vista and ecryptfs [1] for Linux provide whole- Figure 8: Performance of random read access. 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 ultimately rely on a trusted OS, something we cannot do since we wish to occasionally revoke read access on potentially malicious clients. Because the symmetric 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 8

Figure 9: Performance of random write access. trusted server is currently implemented as a Java object with a strict API between it and the client and strong encapsulation; measuring the effect of network performance of an standalone server may be fruitful. It would also be interesting to look at the resulting performance changes when varying the RSA key size and the filesystem block size. 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 amount of key storage 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. Figure 10: RSA encryption vs RSA decryption runtimes. Finally, we need to better detail the revocation of write access. In our current implementation, readers are writers and vice-versa. One such strategy implemented in several existing systems is to have the notion of an owner of a file that controls read and 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 coprocessors that would enable the realization of our trusted file system design. 9

http://technet.microsoft.com/enus/windowsvista/aa906018.aspx#eqb. [7] 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, 2003. Figure 11: RSA decryption in software vs hardware. References [1] ecryptfs. http://ecryptfs.sourceforge.net. [8] L. Sarmenta, M. van Dijk, C. O Donnell, J. Rhodes, and S. Devadas. Virtual monotonic counters and count-limited objects using a tpm without a trusted os (extended version). In MIT Computer Science and Artificial Intelligence Laboratory Technical Report, 2006. [9] Amit Singh. Trusted computing for mac os x. http://www.osxbook.com/book/bonus/ chapter10/tpm/, 2007. [2] Iozone filesystem benchmark. http://www.iozone.org. [3] Trusted platform module (tpm) specification version 1.2 revision 94. https://www.trustedcomputinggroup.org/ specs/tpm, 2007. [4] B. Chun. Improving the fault tolerance of distributed systems with attested appendonly memory. Berkeley Systems Lunch. [5] M. Kallahalla, E. Riedel, R. Swaminathan, Q. Wang, and K. Fu. Plutus scalable secure file sharing on untrusted storage. In Proceedings of the 2nd Conference on File and Storage Technologies (FAST 03), March 2003. [6] Microsoft. Windows vista bitlocker drive encryption: Executive overview. 10