490 likes | 769 Views
Secure History Preservation Through Timeline Entanglement. Petros Maniatis, Mary Baker Computer Science Department Stanford University. What Is History?. A temporal ordering of system events E.g., store a file on disk, sign a document
E N D
Secure History Preservation Through Timeline Entanglement Petros Maniatis, Mary Baker Computer Science Department Stanford University
What Is History? • A temporal ordering of system events • E.g., store a file on disk, sign a document • They may happen on different components of the distributed system • E.g., humans in a social network, peers in p2p • The ordering of events on different components may be important • Did I store my file before you sent that email? • The ordering and the semantics of the events are sensitive and tamper-prone USENIX Security 2002
Motivating Example • Marti is an investor • She owns shares of InDupe, Inc. • On Wednesday, Marti’s broker sells her shares • On Friday, the stock price of InDupe dives • Later, the SEC accuses Marti of insider trading • Marti claims her shares were sold according to an earlier, standing sell order USENIX Security 2002
The Events In Pictures USENIX Security 2002
Marti’s Dream USENIX Security 2002
The Sordid Truth? USENIX Security 2002
What If InDupe Goes Under? USENIX Security 2002
Project Goals • How do we maintain the history of a distributed system • So that it encompasses seamlessly individual components’ histories • When components may be untrustworthy • Long after individual “historians” leave • Basic assumption:no one trusts anyone else USENIX Security 2002
Our Approach: Timeweave • Every component • Maintains its own local history • Maintains a local view of global history • Safeguards the integrity of portions of global history it knows about • Only trusts itself or provable information • Requirements • Efficient, scalable, survivable,aggressively decentralized USENIX Security 2002
Talk Overview • Timeweave Design • Secure Timelines: History of a single component • Timeline Entanglement: Collective history • Timeweave Implementation • Persistent Authenticated Archives • Performance USENIX Security 2002
Single Component History • A hash chain of local event commitments • Event: state change, message received, message sent, etc. • Commitment: if an event is purely internal, I don’t have to put it in my history • The one-way hash function defines the “arrow of time” among events USENIX Security 2002
Timeline Example • Marti performs a bunch of “events” between 10am and 1pm • Those she considers significant she places in her local history • With every event she advances her history by one time step USENIX Security 2002
Zoom In On Time Step i • Marti performs a bunch of “events” between 10am and 1pm • Those she considers significant she places in her local history • With every event she advances her history by one time step USENIX Security 2002
Zoom In On Time Step i • A time step consists of • Logical Time (i):counter of time steps • Digest (di):fingerprint of the committed event (Si) • Authenticator (Ti): USENIX Security 2002
The Joy Of Timelines • A timeline step authenticator is a one-way digest of an entire timeline • Given the current authenticator,no previously committed event can • Change contents • Change logical times • Be inserted or deleted • By committing to an authenticator, a component commits to its history thus far USENIX Security 2002
Proof of Precedence • Given the latest timeline authenticator, I can prove the commitment of an old event • “Walk” the hash applications from the event to the authenticator • All the intermediate information in the hash chain makes up the proof USENIX Security 2002
Proof Efficiency Via Skiplists • Proofs of precedence may span millions of logical time steps • Timelines are organized as authenticated skip lists • Traversal and proof sizes are logarithmic in the traversed logical time steps USENIX Security 2002
Multiple Component History • Timeline Entanglement:Multiple interconnected hash chains • A component publishes samples of its timeline for other components to witness • Witness components commit published timeline samples in their own timelines • Witnessed timelines are tamper-evident • Entanglement enables temporal comparisons among different components’ events USENIX Security 2002
Timeline Entanglement • Component A entangles its timeline with B • It sends B a timeline thread : • Name • Logical time • Timeline authenticator • Signature on the above • Validation info • B checks the validity of the thread and then records it in its timeline USENIX Security 2002
Timeline Sampling • Every entanglement conveys a sample of the sender’s timeline USENIX Security 2002
Timeline Sampling • Every entanglement conveys a sample of the sender’s timeline • Receiver’s view of the sender’s timeline has coarser granularity USENIX Security 2002
Timeline Sampling • Every entanglement conveys a sample of the sender’s timeline • Receiver’s view of the sender’s timeline has coarser granularity • Validation info: sample-to-sample precedence proof USENIX Security 2002
Entanglement Receipts • Timeline threads are acknowledged with a receipt USENIX Security 2002
Entanglement Receipts • Timeline threads are acknowledged with a receipt • A receipt acknowledges the commitment of the previous incoming thread USENIX Security 2002
Cross-timeline Precedence • Inclusion of a foreign thread in my timeline builds a precedence • From the past of the foreign timeline • To my future • Sender receives proof of this with the subsequent receipt acknowledging the thread USENIX Security 2002
Mapping Time • Event B,19 follows all of A’s events up to and including 5 USENIX Security 2002
Mapping Time • Event B,19 follows all of A’s events up to and including 5 • Event B,19 also precedes all of A’s starting with 8 USENIX Security 2002
Mapping Time • Event B,19 follows all of A’s events up to and including 5 • Event B,19 also precedes all of A’s starting with 8 • Combining the two, we conclude that B,19 happened between A’s 5 and 8 USENIX Security 2002
Mapping Time • Event B,19 follows all of A’s events up to and including 5 • Event B,19 also precedes all of A’s starting with 8 • Combining the two, we conclude that B,19 happened between A’s 5 and 8 USENIX Security 2002
More On Entanglement • Survivability • Proactively map events of importance on other timelines • Fault tolerance • Cross-check sample reports to locate Byzantine faults • Timeweave design USENIX Security 2002
Archiving Timeline Threads • Goals • Archive threads • Commit the thread archive when it changes • Produce succinct proofs that the archive contains a particular stored thread • Methodology • Authenticated search trees [Buldas CCS2000] USENIX Security 2002
Binary Search Trees USENIX Security 2002
Authenticated Search Trees USENIX Security 2002
Authenticated Search Trees USENIX Security 2002
Existence Proof USENIX Security 2002
Existence Proof Validation USENIX Security 2002
Existence Proof Validation USENIX Security 2002
Existence Proof Validation USENIX Security 2002
B-Trees USENIX Security 2002
Hash B-Trees USENIX Security 2002
Proof Complications USENIX Security 2002
RBB-Trees • A B-tree with embedded binary balanced trees • B-tree • From the point of view of storage, i.e., clustering of data values in disk blocks • Balanced binary tree (red-black tree) • From the point of view of data value structure, i.e., branching factor USENIX Security 2002
RBB-Trees USENIX Security 2002
More On Implementation • Persistent authenticated dictionaries • Keep track of changes in the thread archive and commit intermediate versions as they occur • Freshness of archive changes • Append-only skip lists • For efficient hash chains USENIX Security 2002
Performance • Setting: • 1200 hosts, all entangling with all others • Events occur once a second per host • Every pair entangles every 10 minutes • Steady-state performance • ~8% of PC resources (dual PIII at 1GHz) • Grows linearly with thread processing rate • i.e. same for 2400 hosts, 20-minute entanglement • Signing/verification the major resource sink • Java 1.3 & BerkeleyDB implementation USENIX Security 2002
Status • Distributed, survivable time stamping • Mutually distrustful time stampers • Stampers may go out of business • Accountable historic storage • Large-scale, interconnected historic file repositories • Reputation in P-2-P publishing • Used for online journal publication USENIX Security 2002
Related Work • We build on • Logical Clocks [Lamport 1979] • SHA-1 [FIPS 180-1] • Digital Time Stamping [Haber & Stornetta 1991] • Authenticated Search Trees [Buldas et al 2000] • Similar goals • Tamper-evident update propagation [Theimer 1998] • Tamper-evident logs [Schneier & Kelsey 1998] USENIX Security 2002
Conclusion • History preservation is important in loosely-coupled distributed systems • We use hashing and time stamping techniques to build a tamper-evident single-component history • We combine multiple component histories through timeline entanglement • We have built Timeweave, a prototype framework for secure history preservation USENIX Security 2002
Secure History Preservation Through Timeline Entanglement Petros Maniatis, Mary Baker Stanford University http://identiscape.stanford.edu/