Trusted Platform Modules for Encrypted File System Access

  • Slides: 11
Download presentation
Trusted Platform Modules for Encrypted File System Access Control Steven Houston & Thomas Kho

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.

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

Current Approaches § Key revocation Active - re-encrypt on revocation § Con: expensive Lazy

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

Goals § Gain? Minimize key revocation (=> rekeying) by maximizing access revocation Active revocation

Goals § Gain? Minimize key revocation (=> rekeying) 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?

Trusted Platform Modules § Enables trusted platforms/secure bootstrapping (We assume it’s not widely available)

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!

Access Revocation § We assume an untrusted storage system and eventually malicious clients §

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

Architecture layering e-2 -e security Authorization Server storage system userland storage system secure fs

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

Architecture (2) Client A’s TPM Authorization Server OIAP Object Independent Auth Protocol § Gives

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

Key management § SK locked to TPM, can export PK § Write Encrypt with

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

Are we crazy? § We noticed… (Untuned) software RSA-2048 encrypt: 75 KB/s TPM RSA-2048

Are we crazy? § We noticed… (Untuned) software RSA-2048 encrypt: 75 KB/s TPM RSA-2048 decrypt: 600 B/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)

Conclusion § TPM + Storage System (+ auth server) = Limited, enforced key distribution

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