Feb, 2001Bill Shapiro, © Copyright, InterTrust Technologies Corporation, 2001. All rights...

Feb, 2001 Bill Shapiro, © Copyright, InterTrust Technologies Corporation, 2001. All rights reserved. 1

TDB: A Trusted Database System on Untrusted Storage

Bill Shapiro

Strategic Technologies and Architectural Research Lab,

InterTrust Technologies

February, 2001

In Collaboration with Umesh Maheshwari and Radek Vingralek


Motivating Application: DRM

Untrusted consumer Trusted server

database

Digital rights management

Database: account balances, contracts

Keep database on client for

– offline commerce– performance: local aggregation

net


Application: DRM

InterRights 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

InterRights Point

PDB

trusted app

Trusted Server

untrusted app

Untrusted Consumer


Application: Network Storage

storage

Trusted PC/PDA Untrusted storage server

netTDB


What does TDB do?

trusted processingCPU, RAM, NVRAM

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

trusted processingCPU, RAM, NVRAM

trusted storage

TDB


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


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


Tamper Detection Basis

Leverage persistent storage in trusted environment

collision-resistant hash

trusted environment

trusted storagesecret key, hash value

X Y Z W


Tamper Resistance Basis

Leverage persistent storage in trusted environment

Merkle Tree, 1980

h(X) h(Y) h(Z) h(W)

h(S) h(T)

X Y Z W

S T

R

trusted environment

trusted storagesecret key, h(R)


Potential Architecture

Crypto over existing database system

existing database system

write read

Problems

– unprotected metadata– no sorted indexes on encrypted data

metadata

encryption + hash-tree


TDB Architecture

Trusted storage Untrusted

storage

Chunk Store• encryption, hashing • atomic updates

Object Store• object cache• concurrency control

Collection Store• index maintenance• scan, match, range

Chunk• byte sequence• 100B--100KB

Object• abstract type• 1 object / chunk

Backup Store• full / incremental• validated restore

Archivalstorage

Collections of Objects• basic querys


Chunk Store

Interface– allocate() ChunkId– write(ChunkId, Bytes)– read(ChunkId) Bytes– deallocate(ChunkId)

Crash atomicity– commit = [write|deallocate]*

Tamper detection and secrecy– uniform protection of data and metadata


Implementation

Log-structured ( ala Sprite LFS)– no statically located chunks– log in untrusted store

Advantages

– traffic analysis can’t link updates to same object– supports variable-size chunks – atomic, efficient updates– more ...

X Y Z X


Chunk Map

Combines hash tree and location map

• Map: ChunkId Handle

• Handle = ‹Hash, Location›

• MetaChunk = Array[Handle]

trusted storageh(R)

X Y

meta chunks

data chunks

T

S

R


Read

Basic scheme: Dereference handles from root to X

Derefence

• use location to fetch• use hash to validate

trusted storageh(R)

X Y

T

S

RcachedOptimized

• trusted cache: ChunkId Handle• look for cached handle upward from X• derefence handles down to X• avoids validating entire path


Write

Basic: write chunks from X to root

Optimized:– buffer dirty handle of X in cache – defer upward propagation– as in LFS, but extended to hashing

trusted storageh(R)

X Y

T

S

R

dirty


Checkpointing the Map

When dirty handles fill cache

– write affected meta chunks to log– write root chunk last

X ... X ... S RT

meta chunks

trusted storageh(R)


... Y ...

Crash Recovery

Process log from last root chunk– residual log– checkpointed log

Must validate residual log

crash X ... X ... S RT

trusted storageh(R)

residual log


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

... Y ... crash X ... X ... S RT

trusted storageh(residual-log)

residual log


... c.c.74Xc.c.

73

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

crash X ... X ... S RT

residual log

hash hash


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


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


Multiple Partitions

Partitions may use separate crypto parameters (algorithms, keys)

Enables fast snapshots and efficient backups

e.g., partition copies:

Partition Map

Position Maps

Data chunks

P

Q

Partition Map

Position Maps

Data chunks

PQ

D D2


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


Cleaning and Partition Copies

Q&P

P.a P.b P.c

PQ

P.c P.cP.a P.b

PQ

P.c P.cP.a P.b P.c

Copy PQ P updates c Cleaner moves Q’s c

P.a P.b P.c ... P.c ... P.c ...

Checkpoint Crash!!

Residual log


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


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


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:

252000History

100Branch

1000Teller

100000Account


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– 3DES for encryption


Performance ResultsResponse Time (avg over 100,000 transactions in steady state):

TDB utilization was set to 60%

6.8

3.8

5.8

0

1

2

3

4

5

6

7

8

BerkeleyDB TDB TDB-S

avg

. re

spo

nse

tim

e (

ms

)


Response Time vs. Utilization

Measured response times for different TDB utilizations:

0

1

2

3

4

5

6

7

8

0.5 0.6 0.7 0.8 0.9

utilization

avg

. re

spo

nse

tim

e (m

s)

TDB

BerkeleyDB


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


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/


Database Size vs. Utilization

0

50

100

150

200

250

300

350

0.5 0.6 0.7 0.8 0.9

utilization

dat

abas

e si

ze (

MB

)

TDB

BerkeleyDB


Alternative Architectures

Untrustedstorage

trusted file system

existing DBMS

Untrustedstorage

trusted chunk store

new file system

existing DBMS

Untrustedstorage

trusted chunk store

new DBMS

(1) (2) (3)


Space Overhead

Chunk descriptor

– hash 12– location 6

Chunk header

– chunk id 6– size 4– pad 6

Chunk body

– pad 4

Log utilization

Feb, 2001Bill Shapiro, © Copyright, InterTrust Technologies Corporation, 2001. All rights...

Documents

Transcript of Feb, 2001Bill Shapiro, © Copyright, InterTrust Technologies Corporation, 2001. All rights...