1 / 35

Attested Append-Only Memory: Making Adversaries Stick to their Word

Attested Append-Only Memory: Making Adversaries Stick to their Word. Byung-Gon Chun (ICSI) October 15, 2007 Joint work with Petros Maniatis (Intel Research, Bekeley), Scott Shenker, and John Kubiatowicz (UC Berkeley) . Context. Context. inc (1). 11. 10. 11. dec (1). 10.

lotus
Télécharger la présentation

Attested Append-Only Memory: Making Adversaries Stick to their Word

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. Attested Append-Only Memory: Making Adversaries Stick to their Word Byung-Gon Chun (ICSI) October 15, 2007 Joint work with Petros Maniatis (Intel Research, Bekeley), Scott Shenker, and John Kubiatowicz (UC Berkeley)

  2. Context

  3. Context

  4. inc (1) 11 10 11 dec (1) 10 Centralized Server Alice Counter Bob Alice: inc(1) Counter 11 Bob: dec(1) Counter 10

  5. inc (1) 11 10 dec (1) 9 Centralized Server Alice: inc(1) Counter 11 Bob: dec(1) Counter 10 Alice Counter Bob Bob: dec(1) Counter 9 Alice: inc(1) Counter 10 Linearizability: 1. A serial schedule of operations2. External order Liveness: making progress

  6. S1: 11 S2: 11 inc (1) S3: 11 11 10 10 10 10 Replicated Servers Linearizability and liveness 11 11 3 Alice 1 2 Bob 4 11 Byzantine Fault Tolerant Replicated Systems e.g., PBFT[TOCS02] BFT algorithms can tolerate up to 1/3 faulty replicas. e.g., f out of 3f+1 If the fault assumption is violated, there is no guarantee!

  7. inc (1) dec (9) Servers Equivocating to Servers Sequence 101 Alice:inc(1) Alice 3 1 10 11 2 4 Bob 10 9 Sequence 101 Bob:dec(1)

  8. Servers Equivocating to Clients Sequence 101 Alice:inc(1) S3: 11 Alice 3 1 11 S1: 11 S2: 11 2 4 Bob S1: 9 S2: 9 9 S4: 9 Sequence 101 Bob:dec(1)

  9. Questions • Does preventing equivocation help at all? • Can we improve upon the 1/3 Byzantine fault bound? • How do we prevent equivocation? • Is there any minimal system support?

  10. Talk Outline • Introduction and Motivation • Attested Append-Only Memory (A2M) • A2M Protocols • Evaluation • Conclusion

  11. Equivocation guard Service 1 1 3 3 2 2 4 4 Application + Protocol Non-equivocation High-level View Service Application + Protocol

  12. Attested Append-Only Memory (A2M) • A set of numbered logs • Each log entry contains • Sequence number • Stored value • Crypto digest of entire log • lookup / end • Get a log entry • Attest (sequence number, value, history digest) • Attest freshness • Attest the end of log • append / advance • Cannot overwrite

  13. msg, • <n, h(msg)> append(h(msg)) • msg, • <n, h(msg)> • msg, • <n, h(msg)> An A2M Usage Pattern Replicas need to agree on msg in sequence number n Sending replica • lookup(n)  • <n, h(msg)> A2M Result: the sending replica is forced to say the same msg for n

  14. Software isolation Trusted hardware Virtual machine Virtualmachinemonitor Local Local Local Local Faulty app Faulty app Faulty app Faulty app Faulty operator Faulty app Faulty operator A2M Implementation Scenarios Third-party service Remote

  15. Talk Outline • Introduction and Motivation • Attested Append-Only Memory (A2M) • A2M Protocols • Evaluation • Conclusion

  16. A2M protocols • A2M State Machine Replication • A2M-PBFT-E • A2M-PBFT-EA • A2M-Storage (SUNDR-like) • A2M-Q/U

  17. Background: PBFT • Assumptions • Byzantine faults • Secure cryptography • Weak synchrony • Guarantee linearizability and liveness with up to f faults out of 3f+1 replicas • Three phase protocol • View change

  18. Execution Agreement Quorum = 3 Execute Preprepare Prepare Commit    Reply  [1,a] Request [1,b] Client2 Background: PBFT Primary s1 s2 req,resp s3 s4 time Client1 Quorum: matching messages from different replicas

  19. A2M Quorum = 3 Execute Preprepare Prepare Commit    Reply  Request Attested by A2M A2M-PBFT-E(Execution) Primary s1 s2 req,resp,<seq,req,hist> Request log s3 s4 time Client1

  20. Intuition Client2 S1: req2,resp2,<n, h(req2), h(hist2)> S2: req2,resp2,<n, h(req2), h(hist2)> S4: req2,resp2,<n, h(req2), h(hist2)> Client1 S1: req1,resp1,<n, h(req1), h(hist1)> S2: req1,resp1,<n, h(req1), h(hist1)> S3: req1,resp1,<n, h(req1), h(hist1)>

  21. Quorum = 3 Execute Preprepare Prepare Commit    Reply  Request Attested by A2M Liveness Problems of A2M-PBFT-E Primary s1 s2 req,resp,<seq,req,hist> s3 s4 time Client1

  22. Quorum = 3 Execute Preprepare Prepare Commit    Reply  Request Attested by A2M A2M-PBFT-EA(Execution+Agreement) Primary s1 s2 req,resp,<seq,req,hist> s3 s4 time Client1

  23. Quorum = 2 Execute Preprepare Prepare Commit    Reply Request A2M-PBFT-EA (2f + 1 replicas) Primary s1 s2 req,resp,<seq,req,hist> s3 time Client1 Attested by A2M

  24. PBFT (3f + 1) A2M-PBFT-EA (2f + 1) Quorum1 (2f + 1) Quorum2 (2f + 1) Quorum1 (f + 1) Quorum2 (f + 1) 1 f + 1 1 A2M 1 non-faulty replica Intuition

  25. Quorum = 2 Execute Preprepare Prepare Commit    Reply Request A2M-PBFT-EA (Three phase) Primary s1 s2 req,resp,<seq,req,hist> s3 time Client1 Attested by A2M

  26. Execute Prepare Commit    Reply Request A2M-PBFT-EA (Two phase) Primary s1 s2 req,resp,<seq,req,hist> s3 time Client1 Attested by A2M

  27. Other Results • A2M-PBFT-EA View change • A2M-Storage: achieve linearizability in an untrusted single-server system • A2M-Q/U: require 4f+1 replicas (instead of 5f+1 replicas) to tolerate f faults

  28. Talk Outline • Introduction and Motivation • Attested Append-Only Memory (A2M) • A2M Protocols • Evaluation • Conclusion

  29. 1/3 PBFT 3f+1 2/3 1/3 A2M-PBFT-E 1/2 A2M-PBFT-EA Protocol Trade-offs

  30. Evaluation Setup • Implemented A2M-PBFT-E and A2M-PBFT-EA • A2M protocols use signatures or MACs for authentication • Four replicas in a LAN. Each replica has its own A2M. • Microbenchmarks • Null operation with various request or response sizes • Macrobenchmarks: NFS • Software package compilation

  31. Macro-benchmarks: NFS

  32. Small trusted primitives Untrusted Untrusted Trustworthy system Trustworthy system + Untrusted Untrusted Broader Implications • What small trusted primitives to put to make systems better • e.g., trusted logical clocks for weak consistency guarantees • e.g., network interface card attestation • More classes of components with different fault characteristics • trusted, semi-trusted, untrusted

  33. Conclusions • Present A2M, a small trusted, log-based primitive • Simple and easily implementable • Prevent equivocation • Improve fault tolerance by forcing servers to commit to a single history of operations • Improve fault bounds of BFT state machine replication • Achieve linearizability in an untrusted single-server system • The benefits are achieved with small performance overhead • A2M has broader implications on structuring trustworthy systems

  34. Thank you!Questions? SOSP 2007

  35. Related Work • Weaken the guarantee • fork* consistency [NSDI07] • fork consistency [OSDI04] • Standard trusted hardware like TPM • does not improve the fault bound • Auditing • PeerReview [SOSP07], CATS [FAST07] • Shared file servers • SUNDR[OSDI04], Ivy [OSDI02], Plutus[FAST03] • Separating agreement from execution • Symmetric faults – hybrid fault model • Group communication

More Related