TDB A Trusted Database System on Untrusted Storage

TDB: A Trusted Database System on Untrusted Storage Bill Shapiro Strategic Technologies and Architectural Research Lab, Inter. Trust Technologies February, 2001 In Collaboration with Umesh Maheshwari and Radek Vingralek Feb, 2001 Bill Shapiro, © Copyright, Inter. Trust Technologies Corporation, 2001. All rights reserved. 1

Motivating Application: DRM database net Untrusted consumer Trusted server Digital rights management Database: account balances, contracts Keep database on client for – offline commerce – performance: local aggregation Feb, 2001 Bill Shapiro, © Copyright, Inter. Trust Technologies Corporation, 2001. All rights reserved. 2

Application: DRM trusted app untrusted app Inter. Rights Point PDB Trusted Server Untrusted Consumer Inter. Rights Point (IRP) – a secure process – Trusted processing environment, small amount of trusted storage – May use software obfuscation, self-checking or secure co-processor Protected Database (PDB) – Secures a bulk of data on an untrusted store – May only be accessed through IRP Feb, 2001 Bill Shapiro, © Copyright, Inter. Trust Technologies Corporation, 2001. All rights reserved. 3

Application: Network Storage TDB net Trusted PC/PDA Feb, 2001 storage Untrusted storage server Bill

What does TDB do? trusted processing CPU, RAM, NVRAM TDB untrusted storage Given a trusted processing environment – runs only trusted programs – protects volatile state – has small amount of trusted storage TDB extends trust to scalable storage – secrecy – tamper-detection Feb, 2001 Bill Shapiro, © Copyright, Inter. Trust Technologies Corporation, 2001. All rights reserved. 5

Design Constraints: Integrity Resist accidental corruption (like most Database Systems) – – transactions backups type checking index maintenance Resist malicious corruption, e. g. , replay attack • save a copy of database (credit = $100) • purchase content (credit = $0) • restore saved copy (credit = $100) – Attack works even if data is encrypted and signed Feb, 2001 Bill Shapiro, © Copyright, Inter. Trust Technologies Corporation, 2001. All rights reserved. 6

Target Environment May run in embedded environment – small footprint (~300 KB) – no need for sophisticated query processing / query languages – can be tightly integrated with programming environment (C++) Support concurrent transactions Optimized for single user – low concurrency and load – modest working set – response time more important than throughput Feb, 2001 Bill Shapiro, © Copyright, Inter. Trust Technologies Corporation, 2001. All rights reserved. 7

Tamper Detection Basis Leverage persistent storage in trusted environment trusted storage secret key, hash value collision-resistant hash X Feb, 2001 Y Z W Bill Shapiro, © Copyright, Inter. Trust Technologies Corporation, 2001. All rights reserved. 8

Tamper Resistance Basis Leverage persistent storage in trusted environment trusted storage secret key, h(R) R h(S) h(T) S h(X) h(Y) X Y T h(Z) h(W) Z W Merkle Tree, 1980 Feb, 2001 Bill Shapiro, © Copyright, Inter. Trust Technologies Corporation, 2001. All rights reserved. 9

Potential Architecture Crypto over existing database system write read encryption + hash-tree existing database system metadata Problems – unprotected metadata – no sorted indexes on encrypted data Feb, 2001 Bill Shapiro, © Copyright, Inter. Trust Technologies Corporation, 2001. All rights reserved. 10

TDB Architecture Backup Store • full / incremental • validated restore Archival storage Feb, 2001 Collection Store • index maintenance • scan, match, range Collections of Objects • basic querys Object Store • object cache • concurrency control Object • abstract type • 1 object / chunk Chunk Store • encryption, hashing • atomic updates Chunk • byte sequence • 100 B--100 KB Trusted storage Untrusted storage Bill Shapiro, © Copyright, Inter. Trust Technologies Corporation, 2001. All rights reserved. 11

Chunk Store Interface – allocate() Chunk. Id – write(Chunk. Id, Bytes) – read(Chunk. Id) Bytes – deallocate(Chunk. Id) Crash atomicity – commit = [write|deallocate]* Tamper detection and secrecy – uniform protection of data and metadata Feb, 2001 Bill Shapiro, © Copyright, Inter. Trust Technologies Corporation, 2001. All rights reserved. 12

Implementation Log-structured ( ala Sprite LFS) – no statically located chunks – log in untrusted store X Y Z X Advantages – – Feb, 2001 traffic analysis can’t link updates to same object supports variable-size chunks atomic, efficient updates more. . . Bill Shapiro, © Copyright, Inter. Trust Technologies Corporation, 2001. All rights reserved. 13

Chunk Map Combines hash tree and location map • Map: Chunk. Id Handle • Handle = ‹Hash, Location› • Meta. Chunk = Array[Handle] trusted storage h(R) R meta chunks S T data chunks Feb, 2001 X Y Bill Shapiro, © Copyright, Inter. Trust Technologies Corporation, 2001. All rights reserved. 14

Read Basic scheme: Dereference handles from root to X Derefence trusted storage h(R) • use location to fetch • use hash to validate cached Optimized • • trusted cache: Chunk. Id Handle look for cached handle upward from X derefence handles down to X avoids validating entire path X Feb, 2001 R S T Y Bill Shapiro, © Copyright, Inter. Trust Technologies Corporation, 2001. All rights reserved. 15

Write Basic: write chunks from X to root Optimized: trusted storage h(R) – buffer dirty handle of X in cache – defer upward propagation – as in LFS, but extended to hashing R S dirty T X Feb, 2001 Y Bill Shapiro, © Copyright, Inter. Trust Technologies Corporation, 2001. All rights reserved. 16

Checkpointing the Map When dirty handles fill cache – write affected meta chunks to log – write root chunk last trusted storage h(R) X. . . X . . . T S R meta chunks Feb, 2001 Bill Shapiro, © Copyright, Inter. Trust Technologies Corporation, 2001. All rights reserved. 17

Crash Recovery Process log from last root chunk – residual log – checkpointed log Must validate residual log trusted storage h(R) X. . . X . . . T S R. . . Y . . . crash residual log Feb, 2001 Bill Shapiro, © Copyright, Inter. Trust Technologies Corporation, 2001. All rights reserved. 18

Validating the Log Keep sequential hash of residual log in trusted storage – updated after each commit Hash protects all current chunks – in residual log: directly – in checkpointed log: through chunk map trusted storage h(residual-log) X. . . X . . . T S R. . . Y . . . crash residual log Feb, 2001 Bill Shapiro, © Copyright, Inter. Trust Technologies Corporation, 2001. All rights reserved. 19

Counter-Based Log Validation A commit chunk is written with each commit – contains a sequential hash of commit set – authenticated with system secret key Increment-only counter used to prevent replays Benefits: – allows bounded discrepancy between TR store and untrusted store – doesn’t require writing to TR store after each transaction hash X. . . X . . . T S R c. c. 73 X c. c. 74 . . . crash residual log Feb, 2001 Bill Shapiro, © Copyright, Inter. Trust Technologies Corporation, 2001. All rights reserved. 20

Log Cleaning Segments – Log divided into fixed-sized regions called segments ( ~100 KB) – Segments are threaded in the residual log for recovery Log cleaner reclaims obsolete chunk versions, creating free segments Cleaning step – read 1 or more segments – write current chunk versions to end of log – mark segments as free May not clean segments in residual log Feb, 2001 Bill Shapiro, © Copyright, Inter. Trust Technologies Corporation, 2001. All rights reserved. 21

Log Cleaning Cleans segments based on statistics (e. g. , segment utilization) Performance – cleaning occurs mostly during idle periods – can trade-off DB size (utilization) for performance Feb, 2001 Bill Shapiro, © Copyright, Inter. Trust Technologies Corporation, 2001. All rights reserved. 22

Multiple Partitions may use separate crypto parameters (algorithms, keys) Enables fast snapshots and efficient backups e. g. , partition copies: Partition Map Q P Feb, 2001 Position Maps Data chunks D Bill Shapiro, © Copyright, Inter. Trust Technologies Corporation, 2001. All rights reserved. D 2 23

Backup Store Guarantees backup consistency without locking Supports full and incremental backups of partitions Full backup: – create a partition snapshot Incremental backup – Created with respect to a previous snapshot (base) A trusted program must authorize backup restores Feb, 2001 Bill Shapiro, © Copyright, Inter. Trust Technologies Corporation, 2001. All rights reserved. 24

Cleaning and Partition Copies Copy P Q P updates c Q&P Q P. a P. b P. c Cleaner moves Q’s c P Q P. a P. b P. c Checkpoint P. a P. b P. c . . . P. c P . . . P. c Crash!! P. c . . . Residual log Feb, 2001 Bill Shapiro, © Copyright, Inter. Trust Technologies Corporation, 2001. All rights reserved. 25

Object Store Provides type-safe access to named (C++) objects Implements full transactional semantics, concurrency control Objects provide pickle and unpickle methods for persistence Provides an in-memory cache of C++ objects Implements no-steal buffer management policy Feb, 2001 Bill Shapiro, © Copyright, Inter. Trust Technologies Corporation, 2001. All rights reserved. 26

Collection Store Supports indexed collections of C++ objects Provides automatic index maintenance during updates Uses functional indices – An extractor function is used to obtain a key from an object Supports exact match, range and scan queries Currently includes B-tree, dynamic hash table and list indices Feb, 2001 Bill Shapiro, © Copyright, Inter. Trust Technologies Corporation, 2001. All rights reserved. 27

Performance Evaluation Compared TDB to Berkeley DB using TPC-B Used TPC-B because: – Included with Berkeley DB – Berkeley DB functionality limited choice of benchmarks (e. g. , 1 index per collection) TPC-B Table sizes: Feb, 2001 Account 100000 Teller 1000 Branch 100 History 252000 Bill Shapiro, © Copyright, Inter. Trust Technologies Corporation, 2001. All rights reserved. 28

Performance Evaluation: Platform TDB -- C++ implementation, 6000 semicolons Static library (. text section 297 KB) Evaluation platform – – – 733 MHz Pentium II, 256 MB Windows NT 4. 0, NTFS files EIDE disk, 8. 9 ms (read), 10. 9 ms write seek time 7200 RPM (4. 2 ms avg. rot. latency) One-way counter: file on NTFS Both systems used a 4 MB cache Crypto Params (for secure version of TDB): – SHA-1 for hashing – 3 DES for encryption Feb, 2001 Bill Shapiro, © Copyright, Inter. Trust Technologies Corporation, 2001. All rights reserved. 29

Performance Results Response Time (avg over 100, 000 transactions in steady state): TDB utilization was set to 60% avg. response time (ms) 8 7 6. 8 5. 8 6 5 3. 8 4 3 2 1 0 Berkeley. DB Feb, 2001 TDB-S Bill Shapiro, © Copyright, Inter. Trust Technologies Corporation, 2001. All rights reserved. 30

Response Time vs. Utilization Measured response times for different TDB utilizations: Feb, 2001 Bill

Related Work Theoretical work – Merkle Tree 1980 – Checking correctness of memory (Blum, et. al. 1992) Secure audit logs, Schneier & Kelsey 1998 – append-only data – read sequentially Information dispersal to multiple storage servers – Rabin 1989, Castro & Liskov 1999 – assumes weakly protected servers, honest quorum – provides tamper recovery Read-only SFS, Fu et al. 2000 – offline update – supports many readers Feb, 2001 Bill Shapiro, © Copyright, Inter. Trust Technologies Corporation, 2001. All rights reserved. 32

Conclusions Architecture – To protect data and metadata alike, integrate crypto with low-level storage management Implementation – Industrial-strength implementation of a Trusted Database System – Synergies between log-structured storage and trust management Performance – TDB performs well compared to Berkeley DB – Can maintain up to 80% utilization with little performance degradation For More Information: – OSDI 2000 -- “How to Build a Trusted Database System on Untrusted Storage. ” Umesh Maheshwari, Radek Vingralek, William Shapiro – Technical Report available at http: //www. star-lab. com/ Feb, 2001 Bill Shapiro, © Copyright, Inter. Trust Technologies Corporation, 2001. All rights reserved. 33

Database Size vs. Utilization Feb, 2001 Bill Shapiro, © Copyright, Inter. Trust Technologies Corporation,

Alternative Architectures existing DBMS new file system trusted chunk store Untrusted storage (1) (2) (3) Feb, 2001 Bill Shapiro, © Copyright, Inter. Trust Technologies Corporation, 2001. All rights reserved. 35

Space Overhead Chunk descriptor – hash 12 – location 6 Chunk header – chunk id 6 – size 4 – pad 6 Chunk body – pad 4 Log utilization Feb, 2001 Bill Shapiro, © Copyright, Inter. Trust Technologies Corporation, 2001. All rights reserved. 36