1 / 11

Trusted Platform Modules for Encrypted File System Access Control

Trusted Platform Modules for Encrypted File System Access Control. Steven Houston & Thomas Kho CS 252 May 9, 2007. Motivation. Efficient access revocation is a problem in distributed storage systems. Current Approaches. Key revocation Active - re-encrypt on revocation Con: expensive

trista
Download Presentation

Trusted Platform Modules for Encrypted File System Access Control

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Trusted Platform Modules for Encrypted File System Access Control 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

  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?

  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!

  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

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

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

  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

  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)

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

More Related