1. Trusted Platform Modules for Encrypted File System Access Control Steven Houston & Thomas Kho CS 252 May 9, 2007 Steven Houston & Thomas Kho CS 252 May 9, 2007

2. Motivation  Efficient access revocation is a problem in distributed storage systems.

3. Current Approaches  Key revocation  Active - re-encrypt on revocation  Con: expensive  Lazy - re-encrypt on file change  Revoked client can’t read more data than before  Con: revoked client still has some access  Key revocation  Active - re-encrypt on revocation  Con: expensive  Lazy - re-encrypt on file change  Revoked client can’t read more data than before  Con: revoked client still has some access

4. Goals  Gain? Minimize key revocation (=> re- keying) by maximizing access revocation  Active revocation of less keys?  Explore what extra security we can get  Even the type that minimizes windows of vulnerability  Quantify performance when TPM is on the datapath  What could make TPMs even more useful?  Gain? Minimize key revocation (=> re- keying) by maximizing access revocation  Active revocation of less keys?  Explore what extra security we can get  Even the type that minimizes windows of vulnerability  Quantify performance when TPM is on the datapath  What could make TPMs even more useful?

5. Trusted Platform Modules  Enables trusted platforms/secure bootstrapping  (We assume it’s not widely available)  Signing/binding/sealing/attestation  Wrapped keys, migratable and not  Transport session logging  Monotonic counters  NOT a crypto accelerator, but we use it like one!  Enables trusted platforms/secure bootstrapping  (We assume it’s not widely available)  Signing/binding/sealing/attestation  Wrapped keys, migratable and not  Transport session logging  Monotonic counters  NOT a crypto accelerator, but we use it like one!

6. Access Revocation  We assume an untrusted storage system and eventually malicious clients  We want  to be able to revoke access  offline access to (some) data  Attested destruction of capabilities  Implemented as transport-logged eviction/flush  “You can only checkout 10 keys at once”  Don’t let keys get into the wild  Remote auth sessions (server “owns” TPM)  Disallow key migration  We assume an untrusted storage system and eventually malicious clients  We want  to be able to revoke access  offline access to (some) data  Attested destruction of capabilities  Implemented as transport-logged eviction/flush  “You can only checkout 10 keys at once”  Don’t let keys get into the wild  Remote auth sessions (server “owns” TPM)  Disallow key migration

7. Architecture os userland apps tpm kext fuse kext secure fs tpm/jfuse-j storage system fs calls vnode layer e-2-e security storage system layering Authorization Server

8. Architecture (2) OIAP Client A’s TPMAuthorization Server Object Independent Auth Protocol  Gives capabilities in the form of keys  Knows (client, tpmownerpass)  Gives capabilities in the form of keys  Knows (client, tpmownerpass)

9. Key management  SK locked to TPM, can export PK  Write  Encrypt with R_PK, signed with W_SK  Read  Decrypt with R_SK, check signature  Write revocation  Unload W_SK; server verifies secure transport log; storage system & clients reject unsigned data  Read revocation  Unload R_SK; server verifies secure transport log  SK locked to TPM, can export PK  Write  Encrypt with R_PK, signed with W_SK  Read  Decrypt with R_SK, check signature  Write revocation  Unload W_SK; server verifies secure transport log; storage system & clients reject unsigned data  Read revocation  Unload R_SK; server verifies secure transport log

10. Are we crazy?  We noticed…  (Untuned) software RSA-2048 encrypt: 75KB/s  TPM RSA-2048 decrypt: 600B/s (yes, bytes!)  Joy’s law, right?  Remember, TPM wasn’t designed as a crypto coprocessor, and it won’t do symmetric crypto (for us)  We noticed…  (Untuned) software RSA-2048 encrypt: 75KB/s  TPM RSA-2048 decrypt: 600B/s (yes, bytes!)  Joy’s law, right?  Remember, TPM wasn’t designed as a crypto coprocessor, and it won’t do symmetric crypto (for us)

11. Conclusion  TPM + Storage System (+ auth server) =  Limited, enforced key distribution (bound to machine)  Attested access revocation  Status: we’re still coding!  TPM + Storage System (+ auth server) =  Limited, enforced key distribution (bound to machine)  Attested access revocation  Status: we’re still coding!