CS252 Project
An Encrypted File System using TPM
Steven Houston: [email protected]Thomas Kho: [email protected] 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 or-ders of magnitude slower than without encryp-tion. Software decryption was about twice as fast as hardware decryption via TPM.
1
Introduction
Trusted Platform Modules (TPMs) are mi-crocontrollers with shielded non-volatile stor-age that are capable of cryptographic func-tions including asymmetric key and random number generation, encryption and decryp-tion, and monotonic counters [3]. TPMs allow authenticated sessions via two mecha-nisms, Object-Independent Authorization Pro-tocol (OIAP) and Object-Specific Authorization
Protocol (OSAP). The two mechanisms are sim-ilar, 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) con-structed 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 stor-age 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 re-encryption of the file with a new key. We would like a method to verify the deletion of the de-cryption key, thereby eliminating a client’s abil-ity 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
revocation by verifying deletion of keys.
2
TPM Details
Throughout this section and the remainder of the paper, the termkey 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 op-erations outside internal opop-erations. 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 re-fer 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 appli-cation 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 gen-erator 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 knowl-edge 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 heteroge-neous 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 sys-tem 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 encryp-tion. 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.
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 check-out 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, indi-cating that the client can no longer decrypt the associated file. Only when the client is uncoop-erative (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 en-dorsement key of the client’s TPM (the endorse-ment 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 appli-cation 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
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 re-quests 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 re-turns 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, re-play 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 correspond-ing 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 in-deed deleted from the TPM. This account-ing 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 cur-rently have the key checked out have been re-voked 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
Implementation
We describe the software and hardware compo-nents of our system that reside on both the client and the server1. We used open-source file sys-tem 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 micropro-cessor 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 Reg-isters (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 hardware-accelerated SHA-1, a true random number generator, a tick counter with tamper detection.
4.1 Client
We implement a filesystem interface using sev-eral 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 com-municate 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 contain-ing several useful high-level TPM routines. These classes, such as TPMCreateKey and
TPMLoadKey, provide an object-oriented in-terface 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 pro-vided by the driver was too low-level to be efficiently utilized.
• MacFuse is a library and kernel module that allows mounting of userland file sys-tem drivers in Mac OS X. It is basically Fuse but modified to work for Mac OS X. User-land 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 li-brary and kernel module.
• Fuse-J is a Java binding to MacFuse that al-lows us to implement our userspace filesys-tem 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 (writ-ing) leads to decryption (encryption) of the ap-propriate block. We use local memory as the backing store for the filesystem. This is easier to implement and sufficient for benchmarking pur-poses. 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
Figure 3: Components of the filesystem implementation on MacOS X 10.4.7.
server would expose. In a practical implementa-tion 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 imme-diately (due to the low rate of block decryption by the TPM). All Iozone benchmarks were run with caching disabled. This is because the origi-nal benchmark failed to call the custom MacFuse read function when the dirty block recently writ-ten 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 per-formance 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 ran-dom 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
Figure 5: Performance of read access to recently read file.
in the TPM. In the read performance graphs, we compare no decryption (again with the baseline MacFuse filesystem) versus decryption in soft-ware 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 per-forms much better than RSA decryption, inde-pendent 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 = 216+ 1 being hardwired into the TPM to provide fast forward encryption. However, since our bench-marks used software encryption, we are unsure as to why the RSA software encryption performed approximately 60 times faster than the RSA soft-ware decryption, unless this is some mathemat-ical property of the algorithms that we are un-aware of. It is unfortunate that RSA decryption is so much slower than encryption, because RSA encryption is the single operation on our
filesys-Figure 6: Performance of write access to new file.
tem’s critical path.
Figure 11 shows that the benchmark with de-cryption in hardware using the TPM chip fared about 2 times slower than the benchmark with decryption in software. This is very encourag-ing, as future modifications to TPM (such as a faster cryptoengine or support for symmetric en-cryption) 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 sepa-rately. 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 be-comes substantial with large files.
Figure 7: Performance of write access to existing file.
6
Related Work
Sarmenta et al. [8] apply logged transport ses-sions 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 us-ing logged transport sessions to verify actions taken by the TPM. Chun [4] introduces a trusted component called Attested Append-Only Mem-ory and shows improvements to fault tolerance in distributed systems.
Plutus [5] and OceanStore [7] are distributed storage systems with distributed key manage-ment. 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 re-vocation, 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 sym-metric 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 addi-tionally encrypt the accompanying file metadata. We use an in-memory object store; it would be instructive to analyze performance if the back-ing store were a distributed storage system. Our
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 interest-ing to look at the resultinterest-ing performance changes when varying the RSA key size and the filesys-tem block size.
Our original motivation was to improve the state of key revocation in distributed storage sys-tems. Modeling the reduction in re-keying of files given verified key deletion on clients would pro-vide further impetus for this work.
The file read/write experiments were con-ducted 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 granu-larity of file keys and the result on performance and 2) the management of keys to reduce the im-pact of exchanging file keys with the key server. Performance of the TPM was limiting, but soft-ware RSA key generation was also an impedi-ment; 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 sys-tem that used the TPM to securely store file en-cryption keys. Our design contained a trusted key server that keeps track of keys on client ma-chines. Benchmarking showed that performance was orders of magnitude slower when encryp-tion was enabled. Further, hardware decrypencryp-tion was about one-half the speed of software encryp-tion. With the growing need to protect sensitive documents, we see a place for secure symmet-ric encryption on TPMs and cryptographic co-processors that would enable the realization of our trusted file system design.
Figure 11: RSA decryption in software vs hard-ware.
References
[1] ecryptfs. http://ecryptfs.sourceforge.net.
[2] Iozone filesystem benchmark. http://www.iozone.org.
[3] Trusted platform module (tpm) spec-ification version 1.2 revision 94. https://www.trustedcomputinggroup.org/ specs/TPM, 2007.
[4] B. Chun. Improving the fault tolerance of distributed systems with attested append-only memory. Berkeley Systems Lunch.
[5] M. Kallahalla, E. Riedel, R. Swaminathan, Q. Wang, and K. Fu. Plutus — scalable se-cure 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.
http://technet.microsoft.com/en-us/windowsvista/aa906018.aspx#EQB.
[7] S. Rhea, P. Eaton, D. Geels, H. Weather-spoon, B. Zhao, and J. Kubiatowicz. Pond: The oceanstore prototype. In Proceedings of the Conference on File and Storage Tech-nologies. USENIX, 2003.
[8] L. Sarmenta, M. van Dijk, C. O’Donnell, J. Rhodes, and S. Devadas. Virtual mono-tonic counters and count-limited objects us-ing a tpm without a trusted os (extended ver-sion). In MIT Computer Science and Artifi-cial Intelligence Laboratory Technical Report, 2006.
[9] Amit Singh. Trusted computing for mac os x. http://www.osxbook.com/book/bonus/ chapter10/tpm/, 2007.
