TrInc: Small Trusted Hardware for Large Distributed Systems
|
|
|
- Marcus Shields
- 5 years ago
- Views:
Transcription
1 TrInc: Small Trusted Hardware for Large Distributed Systems University of Maryland John R. Douceur Jacob R. Lorch Thomas Moscibroda Microsoft Research
2 Trust in distributed systems Selfish Participants Malicious Participants 2
3 Trust in distributed systems Selfish Participants Malicious Participants Powerful tool: Equivocation A participant equivocates by sending conflicting messages to others 2
4 Equivocation is common and powerful Byz. Generals 3
5 Equivocation is common and powerful Byz. Generals Advance Retreat 3
6 Equivocation is common and powerful Byz. Generals Voting Advance Retreat 3
7 Equivocation is common and powerful Byz. Generals Voting Advance Counted your vote Retreat Tally w/o s vote 3
8 Equivocation is common and powerful Byz. Generals Voting BitTorrent Advance Counted your vote Retreat Tally w/o s vote 3
9 Equivocation is common and powerful Byz. Generals Voting BitTorrent Advance Counted your vote I have piece 5 Retreat Tally w/o s vote I don t have piece 5 3
10 Equivocation is common and powerful Byz. Generals Voting BitTorrent Advance Counted your vote I have piece 5 Retreat Tally w/o s vote I don t have piece 5 Leader election Trusted logs sobgp Digital cash Online games Version control Auctions DHTs 3
11 Equivocation is common and powerful Byz. Generals Advance f malicious users If completely untrusted, 3f+1 users needed for consensus [Lamport et al, 1982] Retreat 3
12 Equivocation is common and powerful Byz. Generals Advance Retreat f malicious users If completely untrusted, 3f+1 users needed for consensus [Lamport et al, 1982] If users cannot equivocate, only 2f+1 users are needed [Chun et al, 2007] 3
13 Enter Trusted Hardware Equivocation can be rendered impossible with trusted hardware New design space All participants have a trusted component 4
14 Enter Trusted Hardware Equivocation can be rendered impossible with trusted hardware New design space All participants have a trusted component 4
15 Enter Trusted Hardware Equivocation can be rendered impossible with trusted hardware New design space All participants have a trusted component 4
16 Enter Trusted Hardware Equivocation can be rendered impossible with trusted hardware New design space All participants have a trusted component To be practical, the hardware must be small Ubiquity via low cost Tamper-resilient Easier to verify a small TCB 4
17 Contributions 1 TrInc A new, practical primitive for eliminating equivocation 2 Applications of TrInc 3 Implementation in currently available hardware 5
18 Contributions 1 TrInc A new, practical primitive for eliminating equivocation 2 Applications of TrInc 3 Implementation in currently available hardware 5
19 Motivating question What is the minimal abstraction needed to make equivocation impossible? 6
20 Motivating question What is the minimal abstraction needed to make equivocation impossible? A counter and a key are enough 6
21 TrInc: Trusted Incrementer 1. Monotonically increasing counter 2. Key for signing attestations 34 K 7
22 TrInc: Trusted Incrementer 1. Monotonically increasing counter 2. Key for signing attestations 34 K Attestations bind data to counters 7
23 TrInc: Trusted Incrementer 1. Monotonically increasing counter 2. Key for signing attestations 34 K Attestations bind data to counters Bind this data to counter value 36 7
24 TrInc: Trusted Incrementer 1. Monotonically increasing counter 2. Key for signing attestations Attest( 36, data) 34 K Attestations bind data to counters Bind this data to counter value 36 7
25 TrInc: Trusted Incrementer 1. Monotonically increasing counter 2. Key for signing attestations Attest( 36, data) 34 K Attestations bind data to counters Bind this data to counter value 36 7
26 TrInc: Trusted Incrementer 1. Monotonically increasing counter 2. Key for signing attestations Attest( 36, data) K Attestations bind data to counters Bind this data to counter value 36 7
27 TrInc: Trusted Incrementer 1. Monotonically increasing counter 2. Key for signing attestations Attest( 36, data) K Attestations bind data to counters Bind this data to counter value 36 7
28 TrInc: Trusted Incrementer 1. Monotonically increasing counter 2. Key for signing attestations Attest( 36, data) < 34, 36, data >K K Attestations bind data to counters Bind this data to counter value 36 7
29 TrInc Attestations < 34, 36, data >K < 36, 36, nonce >K 8
30 TrInc Attestations Advance attestation Can only move to a state once data is forever bound to 36 There was nothing bound to 35 < 34, 36, data >K Status attestation < 36, 36, nonce >K What is your current counter? Nonces assure freshness There is nothing beyond 36 (yet) 8
31 Multiple counters Need multiple trusted counters Systems running concurrently Some systems benefit from more counters
32 Multiple counters Need multiple trusted counters Systems running concurrently Some systems benefit from more counters Trinket Hardware that contains 1 counter is a Trinket Allocates and frees counters Establishes session keys 9
33 TrInc is practical Trusted Platform Module (TPM) is ubiquitous Has what we need Tamper-resistance Counters (currently 4) Crypto Small amount of storage It just lacks the right interface 100% 80% 60% 40% 20% 0% TPM Penetration Source: IDC Desktop PCs Mobile PCs x86 Servers 10
34 Contributions 1 TrInc A new, practical primitive for eliminating equivocation 2 Applications of TrInc 3 Implementation in currently available hardware 11
35 Contributions 1 TrInc A new, practical primitive for eliminating equivocation 2 Applications of TrInc 3 Implementation in currently available hardware 11
36 What can TrInc do? Trusted append-only logs Prevent under-reporting in BitTorrent Reduces communication in PeerReview BFT with fewer nodes and messages Ensure fresh data in DHTs Prevent Sybil attacks 12
37 What can TrInc do? Trusted append-only logs Prevent under-reporting in BitTorrent Reduces communication in PeerReview BFT with fewer nodes and messages Ensure fresh data in DHTs Prevent Sybil attacks 12
38 What can TrInc do? Trusted append-only logs Prevent under-reporting in BitTorrent Reduces communication in PeerReview BFT with fewer nodes and messages Ensure fresh data in DHTs Prevent Sybil attacks 12
39 Implementing a trusted log in TrInc Append(data): Bind new data to the end of the log Lookup(sequence num): No equivocating on what is or is not stored 13
40 Implementing a trusted log in TrInc Append(data): Bind new data to the end of the log 10 Lookup(sequence num): No equivocating on what is or is not stored 13
41 Implementing a trusted log in TrInc Append(data): Bind new data to the end of the log 10 Lookup(sequence num): No equivocating on what is or is not stored < 3,8, > < 8,9, > < 9,10, > Untrusted storage 13
42 Implementing a trusted log in TrInc append Append(data): Bind new data to the end of the log 10 Lookup(sequence num): No equivocating on what is or is not stored < 3,8, > < 8,9, > < 9,10, > Untrusted storage 13
43 Implementing a trusted log in TrInc attest(11,, ) Append(data): Bind new data to the end of the log 10 Lookup(sequence num): No equivocating on what is or is not stored < 3,8, > < 8,9, > < 9,10, > Untrusted storage 13
44 Implementing a trusted log in TrInc Append(data): Bind new data to the end of the log 10 Lookup(sequence num): No equivocating on what is or is not stored < 3,8, > < 8,9, > < 9,10, > Untrusted storage 13
45 Implementing a trusted log in TrInc Append(data): Bind new data to the end of the log Lookup(sequence num): No equivocating on what is or is not stored < 3,8, > < 8,9, > < 9,10, > Untrusted storage 13
46 Implementing a trusted log in TrInc < 10,11, > Append(data): Bind new data to the end of the log Lookup(sequence num): No equivocating on what is or is not stored < 3,8, > < 8,9, > < 9,10, > Untrusted storage 13
47 Implementing a trusted log in TrInc Append(data): Bind new data to the end of the log Lookup(sequence num): No equivocating on what is or is not stored < 3,8, > < 8,9, > < 9,10, > < 10,11, > Untrusted storage 13
48 Implementing a trusted log in TrInc lookup 10 Append(data): Bind new data to the end of the log Lookup(sequence num): No equivocating on what is or is not stored < 3,8, > < 8,9, > < 9,10, > < 10,11, > Untrusted storage 13
49 Implementing a trusted log in TrInc Append(data): Bind new data to the end of the log lookup Lookup(sequence num): No equivocating on what is or is not stored < 3,8, > < 8,9, > < 9,10, > < 10,11, > Untrusted storage 13
50 Implementing a trusted log in TrInc Append(data): Bind new data to the end of the log lookup Lookup(sequence num): No equivocating on what is or is not stored < 3,8, > < 8,9, > < 9,10, > < 10,11, > Untrusted storage 13
51 Implementing a trusted log in TrInc Append(data): Bind new data to the end of the log Lookup(sequence num): No equivocating on what is or is not stored < 3,8, > < 8,9, > < 9,10, > < 10,11, > Untrusted storage 13
52 Implementing a trusted log in TrInc Append(data): Bind new data to the end of the log Lookup(sequence num): No equivocating on what is or is not stored < 3,8, > < 8,9, > < 9,10, > < 9,10, > < 10,11, > Untrusted storage 13
53 Implementing a trusted log in TrInc Append(data): Bind new data to the end of the log Lookup(sequence num): No equivocating on what is or is not stored < 3,8, > < 8,9, > < 9,10, > < 10,11, > < 9,10, > Fast lookups Few hardware accesses Untrusted storage 13
54 TrInc-A2M Attested Append-only Memory (A2M) Stores logs in trusted storage Accesses trusted storage for all methods A2M shown to solve Byzantine fault tolerance using fewer nodes SUNDR file system Quorum/Update protocol By construction, TrInc solves these systems, too 14
55 What can TrInc do? Trusted append-only logs Prevent under-reporting in BitTorrent Reduces communication in PeerReview BFT with fewer nodes and messages Ensure fresh data in DHTs Prevent Sybil attacks 15
56 What can TrInc do? Trusted append-only logs Prevent under-reporting in BitTorrent Reduces communication in PeerReview BFT with fewer nodes and messages Ensure fresh data in DHTs Prevent Sybil attacks 15
57 BitTorrent primer 16
58 BitTorrent primer File pieces Fast, users share the work 16
59 BitTorrent primer File pieces Fast, users share the work 16
60 BitTorrent primer Does not have piece File pieces Fast, users share the work 16
61 BitTorrent primer File pieces Fast, users share the work 16
62 BitTorrent primer File pieces Fast, users share the work 16
63 BitTorrent primer File pieces Fast, users share the work 16
64 BitTorrent primer File pieces Interested Fast, users share the work
65 BitTorrent primer File pieces Interested Fast, users share the work Interested
66 BitTorrent primer File pieces Interested Fast, users share the work Interested
67 Piece under-reporting is equivocation [SIGCOMM 08] Yields prolonged interest from others and faster download times 17
68 Piece under-reporting is equivocation 17
69 Piece under-reporting is equivocation 17
70 Piece under-reporting is equivocation Ack 17
71 Piece under-reporting is equivocation Ack 17
72 Piece under-reporting is equivocation I received 17
73 Piece under-reporting is equivocation I never received I received 17
74 Applying TrInc What does the counter represent? The number of pieces received To what do peers attest? Their bitfield The most recent piece received When do peers attest? When they receive When they sync their counters 18
75 TrInc-BitTorrent 19
76 TrInc-BitTorrent 19
77 TrInc-BitTorrent 1 I have and most recently received 19
78 TrInc-BitTorrent 1 I have and most recently received 2 I have and most recently received 3 I have and most recently received 19
79 TrInc-BitTorrent 1 I have and most recently received 2 I have and most recently received 3 I have and most recently received Counter matches the bitfield size 19
80 TrInc-BitTorrent 1 I have and most recently received 2 I have and most recently received 3 I have and most recently received Counter matches the bitfield size 19
81 TrInc-BitTorrent 1 I have and most recently received 2 I have and most recently received 3 I have and most recently received Counter matches the bitfield size Attests to most recent piece 19
82 TrInc-BitTorrent 1 I have and most recently received 2 I have and most recently received 3 I have and most recently received Counter matches the bitfield size Attests to most recent piece 19
83 Why attest to the latest piece? 20
84 Why attest to the latest piece? 20
85 Why attest to the latest piece? 1 I have 20
86 Why attest to the latest piece? 1 I have 20
87 Why attest to the latest piece? 1 I have 20
88 Why attest to the latest piece? 1 I have 2 I have 2 I have 20
89 Why attest to the latest piece? 1 I have Looks good to me 2 I have Looks good to me 2 I have Looks good to me 20
90 Why attest to the latest piece? 1 I have Looks good to me 2 I have Looks good to me 2 I have Looks good to me 20
91 Why attest to the latest piece? 1 I have Looks good to me 2 I have Looks good to me 2 I have Looks good to me Lesson: Without the full log, must ensure proper behavior at each step 20
92 Macrobenchmarks TrInc-BitTorrent Solves piece under-reporting TrInc-A2M Reduces hardware requirements Higher throughput TrInc-PeerReview Reduces the communication necessary to achieve fault detection 21
93 Contributions 1 TrInc A new, practical primitive for eliminating equivocation 2 Applications of TrInc 3 Implementation in currently available hardware 22
94 Contributions 1 TrInc A new, practical primitive for eliminating equivocation 2 Applications of TrInc 3 Implementation in currently available hardware 22
95 Implementation Gemalto.NET Smartcard Crypto unit (RSA & 3-DES) 32-bit micro-controller 80 KB persistent memory A few dozen lines of C# Case studies TrInc-A2M TrInc-PeerReview TrInc-BitTorrent 23
96 TrInc microbenchmarks 250 Operation time (msec) noop Asym Attest Asym Attest Symm attest Symm Attest Verify (advance) (status) (advance) (status) 24
97 TrInc microbenchmarks 250 Operation time (msec) noop Asym Attest Asym Attest Symm attest Symm Attest Verify (advance) (status) (advance) (status) 24
98 TrInc microbenchmarks msec to write a counter Operation time (msec) noop Asym Attest Asym Attest Symm attest Symm Attest Verify (advance) (status) (advance) (status) 24
99 TrInc microbenchmarks msec to write a counter Operation time (msec) Only 2x noop Asym Attest Asym Attest Symm attest Symm Attest Verify (advance) (status) (advance) (status) 24
100 Why so slow? Fundamentally new application of trusted hardware Typically used for bootstrapping TrInc makes it intrinsic to the protocol It can be faster There just has not been the call for it prior to TrInc 25
101 Summary Equivocation is a versatile and powerful A small amount of trust can secure a large system TrInc is Minimal A counter and a key Versatile Applies to a wide range of systems Practical Uses the same components available today 26
102 TrInc speeds up A2M 600 TrInc-A2M A2M Operation time (msec) Append Lookup Lookup Lookup End Truncate Advance (successful) (too early) (forgotten) 27
103 TrInc speeds up A2M 600 TrInc-A2M A2M Operation time (msec) TrInc does not go to h/w for successful lookups Append Lookup Lookup Lookup End Truncate Advance (successful) (too early) (forgotten) 27
104 TrInc speeds up A2M 600 TrInc-A2M A2M Operation time (msec) TrInc does not go to h/w for successful lookups TrInc requires attestations 0 Append Lookup Lookup Lookup End Truncate Advance (successful) (too early) (forgotten) 27
105 Block Revelation SIGCOMM 08 - BitTorrent is an Auction 28
106 Block Revelation SIGCOMM 08 - BitTorrent is an Auction 28
107 Block Revelation SIGCOMM 08 - BitTorrent is an Auction 28
108 Block Revelation SIGCOMM 08 - BitTorrent is an Auction 28
109 Block Revelation SIGCOMM 08 - BitTorrent is an Auction 28
110 Block Revelation SIGCOMM 08 - BitTorrent is an Auction 28
111 Block Revelation SIGCOMM 08 - BitTorrent is an Auction 28
112 Block Revelation SIGCOMM 08 - BitTorrent is an Auction 28
113 Block Revelation SIGCOMM 08 - BitTorrent is an Auction 28
114 Block Revelation SIGCOMM 08 - BitTorrent is an Auction 28
115 Block Revelation SIGCOMM 08 - BitTorrent is an Auction 28
116 Block Revelation SIGCOMM 08 - BitTorrent is an Auction 28
117 Block Revelation Strategically under-report SIGCOMM 08 - BitTorrent is an Auction 28
118 TrInc-BitTorrent Results Cumulative number of blocks obtained Time into the download (sec) 29
119 TrInc-BitTorrent Results Cumulative number of blocks obtained Representative peer Time into the download (sec) 29
120 TrInc-BitTorrent Results Cumulative number of blocks obtained Representative peer Under-reporter: from all Time into the download (sec) 29
121 TrInc-BitTorrent Results Cumulative number of blocks obtained Representative peer Under-reporter: from all Time into the download (sec) Under-reporter pulls ahead 29
122 TrInc-BitTorrent Results But ultimately downloads slower Cumulative number of blocks obtained Representative peer Under-reporter: from all Time into the download (sec) Under-reporter pulls ahead 29
123 TrInc-BitTorrent Results But ultimately downloads slower Cumulative number of blocks obtained Representative peer Under-reporter: from all Under-reporter: from seed Time into the download (sec) Under-reporter pulls ahead 29
124 TrInc-BitTorrent Results But ultimately downloads slower Cumulative number of blocks obtained Representative peer Under-reporter: from all Under-reporter: from seed Truth-tellers A median of 6% from the seeder Under-reporter 73% of file from the seeder Time into the download (sec) Under-reporter pulls ahead 29
Proving the Impossible with Alibi Protocols
Proving the Impossible with Alibi Protocols Dave Levin Victoria Lai, Cristian Lumezanu, Neil Spring, Bobby Bhattacharjee, Bo Han, John Douceur, Jacob Lorch, Thomas Moscibroda Uncooperative behavior Cooperation
TrInc: Small Trusted Hardware for Large Distributed Systems
TrInc: Small Trusted Hardware for Large Distributed Systems Dave Levin John R. Douceur Jacob R. Lorch Thomas Moscibroda University of Maryland Microsoft Research Microsoft Research Microsoft Research Abstract
Terra: A Virtual Machine-Based Platform for Trusted Computing by Garfinkel et al. (Some slides taken from Jason Franklin s 712 lecture, Fall 2006)
Terra: A Virtual Machine-Based Platform for Trusted Computing by Garfinkel et al. (Some slides taken from Jason Franklin s 712 lecture, Fall 2006) Trusted Computing Hardware What can you do if you have
Security (and finale) Dan Ports, CSEP 552
Security (and finale) Dan Ports, CSEP 552 Today Security: what if parts of your distributed system are malicious? BFT: state machine replication Bitcoin: peer-to-peer currency Course wrap-up Security Too
Problem: Equivocation!
Bitcoin: 10,000 foot view Bitcoin and the Blockchain New bitcoins are created every ~10 min, owned by miner (more on this later) Thereafter, just keep record of transfers e.g., Alice pays Bob 1 BTC COS
Blockchain. CS 240: Computing Systems and Concurrency Lecture 20. Marco Canini
Blockchain CS 240: Computing Systems and Concurrency Lecture 20 Marco Canini Credits: Michael Freedman and Kyle Jamieson developed much of the original material. Bitcoin: 10,000 foot view New bitcoins
Failure models. Byzantine Fault Tolerance. What can go wrong? Paxos is fail-stop tolerant. BFT model. BFT replication 5/25/18
Failure models Byzantine Fault Tolerance Fail-stop: nodes either execute the protocol correctly or just stop Byzantine failures: nodes can behave in any arbitrary way Send illegal messages, try to trick
Byzantine Techniques
November 29, 2005 Reliability and Failure There can be no unity without agreement, and there can be no agreement without conciliation René Maowad Reliability and Failure There can be no unity without agreement,
ROTE: Rollback Protection for Trusted Execution
ROTE: Rollback Protection for Trusted Execution Sinisa Matetic, Mansoor Ahmed, Kari Kostiainen, Aritra Dhar, David Sommer, Arthur Gervais, Ari Juels, Srdjan Capkun Siniša Matetić ETH Zurich Institute of
Failures, Elections, and Raft
Failures, Elections, and Raft CS 8 XI Copyright 06 Thomas W. Doeppner, Rodrigo Fonseca. All rights reserved. Distributed Banking SFO add interest based on current balance PVD deposit $000 CS 8 XI Copyright
BYZANTINE GENERALS BYZANTINE GENERALS (1) A fable: Michał Szychowiak, 2002 Dependability of Distributed Systems (Byzantine agreement)
BYZANTINE GENERALS (1) BYZANTINE GENERALS A fable: BYZANTINE GENERALS (2) Byzantine Generals Problem: Condition 1: All loyal generals decide upon the same plan of action. Condition 2: A small number of
Secure Set Intersection with Untrusted Hardware Tokens
Secure Set Intersection with Untrusted Hardware Tokens Thomas Schneider Engineering Cryptographic Protocols Group, TU Darmstadt http://encrypto.de joint work with Marc Fischlin (TU Darmstadt) Benny Pinkas
Hyperledger fabric: towards scalable blockchain for business
Marko Vukolić, IBM Research - Zurich Hyperledger fabric: towards scalable blockchain for business Trust in Digital Life The Hague, Netherlands, June 17 2016 Blockchain shared, replicated, ledger Consensus
BlockFin A Fork-Tolerant, Leaderless Consensus Protocol April
BlockFin A Fork-Tolerant, Leaderless Consensus Protocol April 2018 @storecoin What are the most desirable features in a blockchain? Scalability (throughput) and decentralization (censorship resistance),
Overview. Background: Sybil Attack. Background: Defending Against Sybil Attack. Social Networks. Multiplayer Games. Class Feedback Discussion
Overview Social Networks Multiplayer Games Class Feedback Discussion L-27 Social Networks and Other Stuff 2 Background: Sybil Attack Sybil attack: Single user pretends many fake/sybil identities Creating
Towards Recoverable Hybrid Byzantine Consensus
Towards Recoverable Hybrid Byzantine Consensus Hans P. Reiser 1, Rüdiger Kapitza 2 1 University of Lisboa, Portugal 2 University of Erlangen-Nürnberg, Germany September 22, 2009 Overview 1 Background Why?
Introduction to Cryptoeconomics
Introduction to Cryptoeconomics What is cryptoeconomics? Cryptoeconomics is about... Building systems that have certain desired properties Use cryptography to prove properties about messages that happened
Cryptocurrency and Blockchain Research
Cryptocurrency and Blockchain Research CHANATHIP NAMPREMPRE, PH.D. 1 Agenda Recall bitcoin consensus protocol Components of bitcoin consensus protocol Variations on the same theme Beware of snake oil Solution:
Machine Fault Tolerance for Reliable Datacenter Systems
Machine Fault Tolerance for Reliable Datacenter Systems Danyang Zhuo, Qiao Zhang, Dan R. K. Ports, Arvind Krishnamurthy and Thomas Anderson University of Washington {danyangz, qiao, drkp, arvind, tom}@cs.washington.edu
Announcements. me your survey: See the Announcements page. Today. Reading. Take a break around 10:15am. Ack: Some figures are from Coulouris
Announcements Email me your survey: See the Announcements page Today Conceptual overview of distributed systems System models Reading Today: Chapter 2 of Coulouris Next topic: client-side processing (HTML,
Lecture 17: Peer-to-Peer System and BitTorrent
CSCI-351 Data communication and Networks Lecture 17: Peer-to-Peer System and BitTorrent (I swear I only use it for Linux ISOs) The slide is built with the help of Prof. Alan Mislove, Christo Wilson, and
Lecture Embedded System Security Introduction to Trusted Computing
1 Lecture Embedded System Security Introduction to Trusted Computing Prof. Dr.-Ing. Ahmad-Reza Sadeghi System Security Lab Technische Universität Darmstadt Summer Term 2017 Roadmap: Trusted Computing Motivation
Arvind Krishnamurthy Fall Collection of individual computing devices/processes that can communicate with each other
Distributed Systems Arvind Krishnamurthy Fall 2003 Concurrent Systems Collection of individual computing devices/processes that can communicate with each other General definition encompasses a wide range
Performance and Forgiveness. June 23, 2008 Margo Seltzer Harvard University School of Engineering and Applied Sciences
Performance and Forgiveness June 23, 2008 Margo Seltzer Harvard University School of Engineering and Applied Sciences Margo Seltzer Architect Outline A consistency primer Techniques and costs of consistency
Intel Software Guard Extensions (Intel SGX) Memory Encryption Engine (MEE) Shay Gueron
Real World Cryptography Conference 2016 6-8 January 2016, Stanford, CA, USA Intel Software Guard Extensions (Intel SGX) Memory Encryption Engine (MEE) Shay Gueron Intel Corp., Intel Development Center,
SCP: A Computationally Scalable Byzantine Consensus Protocol for Blockchains
SCP: A Computationally Scalable Byzantine Consensus Protocol for Blockchains Loi Luu, Viswesh Narayanan, Kunal Baweja, Chaodong Zheng, Seth Gilbert, Prateek Saxena National University of Singapore Bitcoin
A Case For OneSwarm. Tom Anderson University of Washington.
A Case For OneSwarm Tom Anderson University of Washington http://oneswarm.cs.washington.edu/ With: Jarret Falkner, Tomas Isdal, Alex Jaffe, John P. John, Arvind Krishnamurthy, Harsha Madhyastha and Mike
Extreme Computing. BitTorrent and incentive-based overlay networks.
Extreme Computing BitTorrent and incentive-based overlay networks BitTorrent Today we will focus on BitTorrent The technology really has three aspects A standard that BitTorrent client systems follow Some
Lecture 3. Introduction to Cryptocurrencies
Lecture 3 Introduction to Cryptocurrencies Public Keys as Identities public key := an identity if you see sig such that verify(pk, msg, sig)=true, think of it as: pk says, [msg] to speak for pk, you must
Distributed Systems 11. Consensus. Paul Krzyzanowski
Distributed Systems 11. Consensus Paul Krzyzanowski pxk@cs.rutgers.edu 1 Consensus Goal Allow a group of processes to agree on a result All processes must agree on the same value The value must be one
Distributed Consensus Protocols
Distributed Consensus Protocols ABSTRACT In this paper, I compare Paxos, the most popular and influential of distributed consensus protocols, and Raft, a fairly new protocol that is considered to be a
Efficient Tamper-Evident Data Structures for Untrusted Servers
Efficient Tamper-Evident Data Structures for Untrusted Servers Dan S. Wallach Rice University Joint work with Scott A. Crosby This talk vs. Preneel s talk Preneel: how hash functions work (or don t work)
Scalable Bias-Resistant Distributed Randomness
Scalable Bias-Resistant Distributed Randomness Ewa Syta*, Philipp Jovanovic, Eleftherios Kokoris Kogias, Nicolas Gailly, Linus Gasser, Ismail Khoffi, Michael J. Fischer, Bryan Ford *Trinity College, USA
Department of Computer Science Institute for System Architecture, Operating Systems Group TRUSTED COMPUTING CARSTEN WEINHOLD
Department of Computer Science Institute for System Architecture, Operating Systems Group TRUSTED COMPUTING CARSTEN WEINHOLD THIS LECTURE... Today: Technology Lecture discusses basics in context of TPMs
Low-Latency Network-Scalable Byzantine Fault-Tolerant Replication 12th EuroSys Doctoral Workshop (EuroDW 2018)
Low-Latency Network-Scalable Byzantine Fault-Tolerant tion 12th EuroSys Doctoral Workshop (EuroDW 2018) Ines Messadi, TU Braunschweig, Germany, 2018-04-23 New PhD student (Second month) in the distributed
MENCIUS: BUILDING EFFICIENT
MENCIUS: BUILDING EFFICIENT STATE MACHINE FOR WANS By: Yanhua Mao Flavio P. Junqueira Keith Marzullo Fabian Fuxa, Chun-Yu Hsiung November 14, 2018 AGENDA 1. Motivation 2. Breakthrough 3. Rules of Mencius
Bitcoin. CS6450: Distributed Systems Lecture 20 Ryan Stutsman
Bitcoin CS6450: Distributed Systems Lecture 20 Ryan Stutsman Material taken/derived from Princeton COS-418 materials created by Michael Freedman and Kyle Jamieson at Princeton University. Licensed for
Sybil defenses via social networks
Sybil defenses via social networks Abhishek University of Oslo, Norway 19/04/2012 1 / 24 Sybil identities Single user pretends many fake/sybil identities i.e., creating multiple accounts observed in real-world
Practical Byzantine Fault
Practical Byzantine Fault Tolerance Practical Byzantine Fault Tolerance Castro and Liskov, OSDI 1999 Nathan Baker, presenting on 23 September 2005 What is a Byzantine fault? Rationale for Byzantine Fault
HDFS Architecture. Gregory Kesden, CSE-291 (Storage Systems) Fall 2017
HDFS Architecture Gregory Kesden, CSE-291 (Storage Systems) Fall 2017 Based Upon: http://hadoop.apache.org/docs/r3.0.0-alpha1/hadoopproject-dist/hadoop-hdfs/hdfsdesign.html Assumptions At scale, hardware
Efficient Data Structures for Tamper-Evident Logging
Efficient Data Structures for Tamper-Evident Logging Scott A. Crosby Dan S. Wallach Rice University Everyone has logs Tamper evident solutions Current commercial solutions Write only hardware appliances
Quiz II Solutions MASSACHUSETTS INSTITUTE OF TECHNOLOGY Fall Department of Electrical Engineering and Computer Science
Department of Electrical Engineering and Computer Science MASSACHUSETTS INSTITUTE OF TECHNOLOGY 6.858 Fall 2012 Quiz II Solutions 20 Grade for q2 15 10 5 0 0 10 20 30 40 50 60 70 80 90 100 Histogram of
Trojan-tolerant Hardware & Supply Chain Security in Practice
Trojan-tolerant Hardware & Supply Chain Security in Practice Who we are Vasilios Mavroudis Doctoral Researcher, UCL Dan Cvrcek CEO, Enigma Bridge George Danezis Professor, UCL Petr Svenda CTO, Enigma Bridge
Byzantine Fault Tolerance
Byzantine Fault Tolerance CS 240: Computing Systems and Concurrency Lecture 11 Marco Canini Credits: Michael Freedman and Kyle Jamieson developed much of the original material. So far: Fail-stop failures
Practical Byzantine Fault Tolerance. Miguel Castro and Barbara Liskov
Practical Byzantine Fault Tolerance Miguel Castro and Barbara Liskov Outline 1. Introduction to Byzantine Fault Tolerance Problem 2. PBFT Algorithm a. Models and overview b. Three-phase protocol c. View-change
Process groups and message ordering
Process groups and message ordering If processes belong to groups, certain algorithms can be used that depend on group properties membership create ( name ), kill ( name ) join ( name, process ), leave
A systematic approach to eliminating the vulnerabilities in smart cards evaluation
A systematic approach to eliminating the vulnerabilities in smart cards evaluation Hongsong Shi, Jinping Gao, Chongbing Zhang hongsongshi@gmail.com China Information Technology Security Evaluation Center
CONSENSUS PROTOCOLS & BLOCKCHAINS. Techruption Lecture March 16 th, 2017 Maarten Everts (TNO & University of Twente)
CONSENSUS PROTOCOLS & BLOCKCHAINS Techruption Lecture March 16 th, 2017 Maarten Everts (TNO & University of Twente) 2 Consensus protocols & blockchain 3 Consensus protocols & blockchain 4 Consensus protocols
Justifying Integrity Using a Virtual Machine Verifier
Justifying Integrity Using a Virtual Machine Verifier Joshua Schiffman, Thomas Moyer, Christopher Shal, Trent Jaeger, and Patrick McDaniel ACSAC 09 1 1 Cloudy Horizons Utility-based cloud computing is
Some Lessons Learned from Designing the Resource PKI
Some Lessons Learned from Designing the Resource PKI Geoff Huston Chief Scientist, APNIC May 2007 Address and Routing Security The basic security questions that need to be answered are: Is this a valid
Data Consistency and Blockchain. Bei Chun Zhou (BlockChainZ)
Data Consistency and Blockchain Bei Chun Zhou (BlockChainZ) beichunz@cn.ibm.com 1 Data Consistency Point-in-time consistency Transaction consistency Application consistency 2 Strong Consistency ACID Atomicity.
The Design and Implementation of a Next Generation Name Service for the Internet (CoDoNS) Presented By: Kamalakar Kambhatla
The Design and Implementation of a Next Generation Name Service for the Internet (CoDoNS) Venugopalan Ramasubramanian Emin Gün Sirer Presented By: Kamalakar Kambhatla * Slides adapted from the paper -
Distributed Algorithms. Partha Sarathi Mandal Department of Mathematics IIT Guwahati
Distributed Algorithms Partha Sarathi Mandal Department of Mathematics IIT Guwahati Thanks to Dr. Sukumar Ghosh for the slides Distributed Algorithms Distributed algorithms for various graph theoretic
Blockchains & Cryptocurrencies
1 Blockchains & Cryptocurrencies A Technical Introduction Lorenz Breidenbach ETH Zürich Cornell Tech The Initiative for CryptoCurrencies & Contracts (IC3) 2 Cryptocurrency Mania Market cap as of yesterday:
Today: Fault Tolerance
Today: Fault Tolerance Agreement in presence of faults Two army problem Byzantine generals problem Reliable communication Distributed commit Two phase commit Three phase commit Paxos Failure recovery Checkpointing
Horizontal or vertical scalability? Horizontal scaling is challenging. Today. Scaling Out Key-Value Storage
Horizontal or vertical scalability? Scaling Out Key-Value Storage COS 418: Distributed Systems Lecture 8 Kyle Jamieson Vertical Scaling Horizontal Scaling [Selected content adapted from M. Freedman, B.
Lecture Embedded System Security Introduction to Trusted Computing
1 Lecture Embedded System Security Prof. Dr.-Ing. Ahmad-Reza Sadeghi System Security Lab Technische Universität Darmstadt (CASED) Summer Term 2015 Roadmap: Trusted Computing Motivation Notion of trust
To do. Consensus and related problems. q Failure. q Raft
Consensus and related problems To do q Failure q Consensus and related problems q Raft Consensus We have seen protocols tailored for individual types of consensus/agreements Which process can enter the
Lecture Embedded System Security Introduction to Trusted Computing
1 Lecture Embedded System Security Prof. Dr.-Ing. Ahmad-Reza Sadeghi System Security Lab Technische Universität Darmstadt (CASED) Summer Term 2012 Roadmap: Trusted Computing Motivation Notion of trust
Motivation and goal Design concepts and service model Architecture and implementation Performance, and so on...
Motivation and goal Design concepts and service model Architecture and implementation Performance, and so on... Autonomous applications have a demand for grasping the state of hosts and networks for: sustaining
GNUnet Distributed Data Storage
GNUnet Distributed Data Storage DHT and Distance Vector Transport Nathan S. Evans 1 1 Technische Universität München Department of Computer Science Network Architectures and Services July, 24 2010 Overview
DISTRIBUTED COMPUTER SYSTEMS ARCHITECTURES
DISTRIBUTED COMPUTER SYSTEMS ARCHITECTURES Dr. Jack Lange Computer Science Department University of Pittsburgh Fall 2015 Outline System Architectural Design Issues Centralized Architectures Application
Do incentives build robustness in BitTorrent?
Do incentives build robustness in BitTorrent? ronghui.gu@yale.edu Agenda 2 Introduction BitTorrent Overview Modeling Altruism in BitTorrent Building BitTyrant Evaluation Conclusion Introduction 3 MAIN
EECS 498 Introduction to Distributed Systems
EECS 498 Introduction to Distributed Systems Fall 2017 Harsha V. Madhyastha Today Bitcoin: A peer-to-peer digital currency Spark: In-memory big data processing December 4, 2017 EECS 498 Lecture 21 2 December
Enhanced Immutability of Permissioned Blockchain Networks by Tethering Provenance with a Public Blockchain Network
Enhanced Immutability of Permissioned Blockchain Networks by Tethering Provenance with a Public Blockchain Network Abstract Azeem Ahmed (azeem.ahmed@consensys.net) Jim Zhang (jim.zhang@consensys.net) Permissioned
Paxos and Raft (Lecture 21, cs262a) Ion Stoica, UC Berkeley November 7, 2016
Paxos and Raft (Lecture 21, cs262a) Ion Stoica, UC Berkeley November 7, 2016 Bezos mandate for service-oriented-architecture (~2002) 1. All teams will henceforth expose their data and functionality through
Proseminar Distributed Systems Summer Semester Paxos algorithm. Stefan Resmerita
Proseminar Distributed Systems Summer Semester 2016 Paxos algorithm stefan.resmerita@cs.uni-salzburg.at The Paxos algorithm Family of protocols for reaching consensus among distributed agents Agents may
RapidChain: Scaling Blockchain via Full Sharding
RapidChain: Scaling Blockchain via Full Sharding Mahdi Zamani Visa Research Join work with Mahnush Movahedi, Dfinity Mariana Raykova, Yale University Stanford Blockchain Seminar August 2018 Agenda! Part
Robust BFT Protocols
Robust BFT Protocols Sonia Ben Mokhtar, LIRIS, CNRS, Lyon Joint work with Pierre Louis Aublin, Grenoble university Vivien Quéma, Grenoble INP 18/10/2013 Who am I? CNRS reseacher, LIRIS lab, DRIM research
Distributed systems. Lecture 6: distributed transactions, elections, consensus and replication. Malte Schwarzkopf
Distributed systems Lecture 6: distributed transactions, elections, consensus and replication Malte Schwarzkopf Last time Saw how we can build ordered multicast Messages between processes in a group Need
Cooperation in Open Distributed Systems. Stefan Schmid
Cooperation in Open Distributed Systems Stefan Schmid T-Labs, Berlin, July 2, 2009 Distributed Systems 2008/9 Wireless: Many mobile phones today have WLAN (and even Skype) P2P: Olympic games 2008 live-broadcast
Toward Intrusion Tolerant Clouds
Toward Intrusion Tolerant Clouds Prof. Yair Amir, Prof. Vladimir Braverman Daniel Obenshain, Tom Tantillo Department of Computer Science Johns Hopkins University Prof. Cristina Nita-Rotaru, Prof. Jennifer
Availability, Reliability, and Fault Tolerance
Availability, Reliability, and Fault Tolerance Guest Lecture for Software Systems Security Tim Wood Professor Tim Wood - The George Washington University Distributed Systems have Problems Hardware breaks
Versioning, Consistency, and Agreement
Lee Lorenz, Brent Sheppard Jenkins, if I want another yes man, I ll build one! Versioning, Consistency, and Agreement COS 461: Computer Networks Spring 2010 (MW 3:00 4:20 in CS105) Mike Freedman hip://www.cs.princeton.edu/courses/archive/spring10/cos461/
Distributed Computing. CS439: Principles of Computer Systems November 20, 2017
Distributed Computing CS439: Principles of Computer Systems November 20, 2017 Last Time Network Programming: Sockets End point of communication Identified by (IP address : port number) pair Client-Side
Consensus and related problems
Consensus and related problems Today l Consensus l Google s Chubby l Paxos for Chubby Consensus and failures How to make process agree on a value after one or more have proposed what the value should be?
Middleware and Distributed Systems. System Models. Dr. Martin v. Löwis
Middleware and Distributed Systems System Models Dr. Martin v. Löwis System Models (Coulouris et al.) Architectural models of distributed systems placement of parts and relationships between them e.g.
Session key establishment protocols
our task is to program a computer which gives answers which are subtly and maliciously wrong at the most inconvenient possible moment. -- Ross Anderson and Roger Needham, Programming Satan s computer Session
Peer-to-peer Sender Authentication for . Vivek Pathak and Liviu Iftode Rutgers University
Peer-to-peer Sender Authentication for Email Vivek Pathak and Liviu Iftode Rutgers University Email Trustworthiness Sender can be spoofed Need for Sender Authentication Importance depends on sender Update
Session key establishment protocols
our task is to program a computer which gives answers which are subtly and maliciously wrong at the most inconvenient possible moment. -- Ross Anderson and Roger Needham, Programming Satan s computer Session
Distributed Consensus: Making Impossible Possible
Distributed Consensus: Making Impossible Possible QCon London Tuesday 29/3/2016 Heidi Howard PhD Student @ University of Cambridge heidi.howard@cl.cam.ac.uk @heidiann360 What is Consensus? The process
Alternative Consensus Algorithms. Murat Osmanoglu
Alternative Consensus Algorithms Murat Osmanoglu Bitcoin Block i-1 Block i Block i+1 Hash i-2 Nonce i-1 Hash i-1 Nonce i Hash i Nonce i+1 tx tx tx tx tx tx tx tx tx tx tx tx Do you really need a Blockchain?
Distributed Systems Conclusions & Exam. Brian Nielsen
Distributed Systems Conclusions & Exam Brian Nielsen bnielsen@cs.aau.dk Definition A distributed system is the one in which hardware and software components at networked computers communicate and coordinate
Modern key distribution with ClaimChains
Modern key distribution with ClaimChains A decentralized Public Key Infrastructure that supports privacy-friendly social verification NEXTLEAP Bogdan Kulynych Marios Isaakidis Carmela Troncoso George Danezis
Dynamo. Smruti R. Sarangi. Department of Computer Science Indian Institute of Technology New Delhi, India. Motivation System Architecture Evaluation
Dynamo Smruti R. Sarangi Department of Computer Science Indian Institute of Technology New Delhi, India Smruti R. Sarangi Leader Election 1/20 Outline Motivation 1 Motivation 2 3 Smruti R. Sarangi Leader
Transactions. CS 475, Spring 2018 Concurrent & Distributed Systems
Transactions CS 475, Spring 2018 Concurrent & Distributed Systems Review: Transactions boolean transfermoney(person from, Person to, float amount){ if(from.balance >= amount) { from.balance = from.balance
Replication in Distributed Systems
Replication in Distributed Systems Replication Basics Multiple copies of data kept in different nodes A set of replicas holding copies of a data Nodes can be physically very close or distributed all over
Replications and Consensus
CPSC 426/526 Replications and Consensus Ennan Zhai Computer Science Department Yale University Recall: Lec-8 and 9 In the lec-8 and 9, we learned: - Cloud storage and data processing - File system: Google
Consensus Problem. Pradipta De
Consensus Problem Slides are based on the book chapter from Distributed Computing: Principles, Paradigms and Algorithms (Chapter 14) by Kshemkalyani and Singhal Pradipta De pradipta.de@sunykorea.ac.kr
Distributed Systems Conclusions & Exam. Brian Nielsen
Distributed Systems Conclusions & Exam Brian Nielsen bnielsen@cs.aau.dk Study Regulations Purpose: That the student obtains knowledge about concepts in distributed systems, knowledge about their construction,
Survivable Trust for Critical Infrastructure David M. Nicol, Sean W. Smith, Chris Hawblitzel, Ed Feustel, John Marchesini, Bennet Yee*
Survivable Trust for Critical Infrastructure David M. Nicol, Sean W. Smith, Chris Hawblitzel, Ed Feustel, John Marchesini, Bennet Yee* Cybersecurity Research Group Institute for Security Technology Studies,
Apache ZooKeeper and orchestration in distributed systems. Andrew Kondratovich
Apache ZooKeeper and orchestration in distributed systems Andrew Kondratovich andrew.kondratovich@gmail.com «A distributed system is one in which the failure of a computer you didn't even know existed
Zyzzyva. Speculative Byzantine Fault Tolerance. Ramakrishna Kotla. L. Alvisi, M. Dahlin, A. Clement, E. Wong University of Texas at Austin
Zyzzyva Speculative Byzantine Fault Tolerance Ramakrishna Kotla L. Alvisi, M. Dahlin, A. Clement, E. Wong University of Texas at Austin The Goal Transform high-performance service into high-performance
Recall: Primary-Backup. State machine replication. Extend PB for high availability. Consensus 2. Mechanism: Replicate and separate servers
Replicated s, RAFT COS 8: Distributed Systems Lecture 8 Recall: Primary-Backup Mechanism: Replicate and separate servers Goal #: Provide a highly reliable service Goal #: Servers should behave just like
On the (Limited) Power of Non-Equivocation
On the (Limited) Power of Non-Equivocation ABSTRACT Allen Clement MPI-SWS aclement@mpi-sws.org Aniket Kate MPI-SWS aniket@mpi-sws.org In recent years, there have been a few proposals to add a small amount
There Is More Consensus in Egalitarian Parliaments
There Is More Consensus in Egalitarian Parliaments Iulian Moraru, David Andersen, Michael Kaminsky Carnegie Mellon University Intel Labs Fault tolerance Redundancy State Machine Replication 3 State Machine
An Offline Foundation for Accountable Pseudonyms
An Offline Foundation for Accountable Pseudonyms Bryan Ford MIT CSAIL Jacob Strauss SocialNets April 1, 2008 Introduction Anonymity is a cherished principle Traditional: voting, peer review Online: email,
Lecture 6: Overlay Networks. CS 598: Advanced Internetworking Matthew Caesar February 15, 2011
Lecture 6: Overlay Networks CS 598: Advanced Internetworking Matthew Caesar February 15, 2011 1 Overlay networks: Motivations Protocol changes in the network happen very slowly Why? Internet is shared
Scaling Out Key-Value Storage
Scaling Out Key-Value Storage COS 418: Distributed Systems Logan Stafman [Adapted from K. Jamieson, M. Freedman, B. Karp] Horizontal or vertical scalability? Vertical Scaling Horizontal Scaling 2 Horizontal
Curriculum 2013 Knowledge Units Pertaining to PDC
Curriculum 2013 Knowledge Units Pertaining to C KA KU Tier Level NumC Learning Outcome Assembly level machine Describe how an instruction is executed in a classical von Neumann machine, with organization