EEC 688/788 Secure and Dependable Computing

EEC 688/788 Secure and Dependable Computing
Lecture 13 Wenbing Zhao Department of Electrical and Computer Engineering Cleveland State University

EEC688/788: Secure & Dependable Computing
Outline Byzantine general problem By Leslie Lamport, Robert Shostak, & Marshall Pease Practical Byzantine fault tolerance By Miguel Castro and Barbara Liskov, OSDI’99 12/8/2018 EEC688/788: Secure & Dependable Computing Wenbing Zhao 2

The Byzantine Generals Problem
Abstract model of a computer system that may have faulty components Faulty components may send conflicting information to different parts of the system Example: clock synchronization, processes i, j, k, k is faulty When process i queries k for the current time at local time 2:40pm, process k reports 2:50pm Concurrently process j queries k at local time 2:30pm, process k reports 2:20pm Scenario where Byzantine Generals must reach agreement in the presence of traitors: Byzantine agreement Generals must reach consensus among themselves => they all agree on an action: retreat or attack 12/8/2018 EEC688/788: Secure & Dependable Computing Wenbing Zhao 3

Byzantine Generals Problem
A group of generals of the Byzantine army encircles an enemy city and decides whether to attack the city together or withdraw One or more generals may be traitors The only way for the Byzantine army to win the battle and conquer the enemy city is for all the loyal generals and their troops attack the enemy city together The generals communicate with each other by using messengers The messengers are trustworthy in that they will deliver a command issued by a general in a timely manner and without any alteration

In a computer system, each general is modeled as a process, and the processes communicate via plain messages that satisfy the following requirements: A message sent is delivered reliably and promptly The message carries the identifier of its sender and the identifier cannot be forged or altered by the network or any other processes A process can detect the missing of a message that is supposed to be sent by another process To make the problem and its solution more general, we expand the scope of the command issued by the commander process to contain an arbitrary value proposed by the commander

A solution of the Byzantine generals problem should ensure the following interactive consistency requirements: IC1 All non-faulty processes (i.e., loyal generals) agree on the same value (i.e., decision) IC2 If the commander process is not faulty, then the value proposed by the commander must be the value that has been agreed upon by non-faulty processes Without IC2, we have a trivial solution: all lieutenants decide on attack or retreat 12/8/2018 EEC688/788: Secure & Dependable Computing Wenbing Zhao 6

Basic Ideas for Solving Byzantine Generals Problems
The commander issues a command to all its lieutenants The lieutenants exchange the commands they have received with each other Each lieutenant applies a deterministic function, such as the majority function, on the commands it has collected to derive a final decision Main Concern: The commander may send different commands to different lieutenants A traitorous general might lie about the command it has received from the commander 12/8/2018 EEC688/788: Secure & Dependable Computing Wenbing Zhao

Why we need 3f+1 generals to tolerate f traitors?
12/8/2018 EEC688/788: Secure & Dependable Computing Wenbing Zhao

The Oral Message Algorithms
The oral message algorithms are defined inductively The solution starts by running an instance of the Oral Message algorithms OM(f) with n generals, where f is the number of traitors tolerated, and n ≥ 3f + 1 One of the generals is designated as the commander and the remaining generals are lieutenants Each general is assigned an integer id, with the commander assigned 0, and the lieutenants assigned 1,...,n−1, respectively 12/8/2018 EEC688/788: Secure & Dependable Computing Wenbing Zhao

The Oral Message Algorithms
OM(f) would trigger n−1 instances of the OM(f −1) algorithm (one per lieutenant), and each instance of the OM(f −1) algorithm involves n − 1 generals (i.e., all the lieutenants), …. A lieutenant for OM(f) would serve as the commander for OM(f − 1), and so on Each lieutenant i uses a scalar variable vi to store the decision value received from the commander, where i is an integer ranges from 1 to n − 1. A lieutenant also uses a variable vj to store the value received from lieutenant j (j ≠ i) 12/8/2018 EEC688/788: Secure & Dependable Computing Wenbing Zhao

The commander multicasts a message containing a value to all the lieutenants in the current instance of the algorithm For each i, lieutenant i set vi to the value received from the commander. If it does not receive any value from the commander, it defaults to a predefined decision (such as ”retreat”) 12/8/2018 EEC688/788: Secure & Dependable Computing Wenbing Zhao

OM(f) The commander multicasts a decision to all the lieutenants in the current instance of the algorithm For each i, lieutenant i sets vi to the value received from the commander. If it does not receive any value from the commander, it defaults to a predefined decision Subsequently, lieutenant i launches an instance of the OM(f − 1) algorithm by acting as the commander for OM(f−1). The n−1 generals involved in the instance of the OM(f-1) algorithm consists of all lieutenants in the OM(f,n) instance 12/8/2018 EEC688/788: Secure & Dependable Computing Wenbing Zhao

OM(f) For each i and j ≠ i, lieutenant i sets vj to the value received from lieutenant j ≠ i in step (2). If it does not receive any value from lieutenant j, it sets vj to the predefined default value When all instances of the OM(f − 1) algorithm have been completed, lieutenant i chooses the value returned by the majority function on the set [v1, ..., vn−1] 12/8/2018 EEC688/788: Secure & Dependable Computing Wenbing Zhao

Example: OM(1) f=1, n=4 3 instances of OM(0) In step 3, each lieutenant calculates the final decision based on the three messages it has received one message from the commander in OM(1), and two messages in the two instances of the OM(0) algorithm Case 1, G0 is a traitor and it sends different values to the three lieutenants, i.e., M01 = x, M02 = y, M03 = z. All three lieutenants are loyal, hence, M01,2 = M01,3 = x, M02,1 = M02,3 = y, and M03,1 = M03,2 = z Case 2: G1 is traitor (G0 is loyal), M01 = M02 = M03 = v, M01,2 = x, M01,3 = y, M02,1 = M02,3 = v, and M03,1 = M03,2 = v 12/8/2018 EEC688/788: Secure & Dependable Computing Wenbing Zhao

Example: OM(1) 12/8/2018 EEC688/788: Secure & Dependable Computing Wenbing Zhao

Example: OM(2) 12/8/2018 EEC688/788: Secure & Dependable Computing Wenbing Zhao

Introduction to BFT Paper
The growing reliance of industry and government on online information services Malicious attacks become more serious and successful More software errors due to increased size and complexity of software This paper presents “practical” algorithm for state machine replication that works in asynchronous systems like the Internet 12/8/2018 EEC688/788: Secure & Dependable Computing Wenbing Zhao

Assumptions Asynchronous distributed system The network may fail to deliver, delay, duplicate or deliver them out of order Faulty nodes may behave arbitrarily Independent node failures The adversary cannot delay correct nodes indefinitely All messages are cryptographically signed by their sender and these signatures cannot be subverted by the adversary 12/8/2018 EEC688/788: Secure & Dependable Computing Wenbing Zhao

Service Properties A (deterministic) service is replicated among ≥ 3f+1 processors. Resilient to ≤ f failures Safety: All non-faulty replicas guaranteed to process the same requests in the same order Liveness: Clients eventually receive replies to their requests 12/8/2018 EEC688/788: Secure & Dependable Computing Wenbing Zhao

Optimal Resiliency Imagine non-faulty processors trying to agree upon a piece of data by telling each other what they believe the data to be A non-faulty processor must be sure about a piece of data before it can proceed f replicas may refuse to send messages, so each processor must be ready to proceed after having received (n-1)-f messages Total of n-1 other replicas 12/8/2018 EEC688/788: Secure & Dependable Computing Wenbing Zhao

Optimal Resiliency But what if f of the (n-1)-f messages come from faulty replicas? To avoid confusion, the majority of messages must come from non-faulty nodes, i.e, (n-f-1)/2 ≥ f => Need a total of ≥3f+1 replicas 12/8/2018 EEC688/788: Secure & Dependable Computing Wenbing Zhao

BFT Algorithm in a Nutshell
Backup f + 1 Match (OK) Client Primary Backup Backup 12/8/2018 EEC688/788: Secure & Dependable Computing Wenbing Zhao

Replicas and Views Set of replicas (R): |R| ≥ 3f + 1 R0 R0 R0 R1 R1 R2 R|R-1| ……… View 1 View 0 For view v: primary p is assigned such that p= v mod |R| 12/8/2018 EEC688/788: Secure & Dependable Computing Wenbing Zhao

Safeguards If the client does not receive replies soon enough, it broadcasts the request to all replicas If the request has already been processed, the replicas simply re-send the reply (replicas remember the last reply message they sent to each client) If the primary does not multicast the request to the group, it will eventually be suspected to be faulty by enough replicas to cause a view change 12/8/2018 EEC688/788: Secure & Dependable Computing Wenbing Zhao

Normal Case Operation Client {REQUEST, o, t, c} Primary o – Operation t – Timestamp c - Client Timestamps are totally ordered such that later requests have higher timestamps than earlier ones 12/8/2018 EEC688/788: Secure & Dependable Computing Wenbing Zhao

Normal Case Operation Primary p receives a client request m , it starts a three-phase protocol Three phases are: pre-prepare, prepare, commit 12/8/2018 EEC688/788: Secure & Dependable Computing Wenbing Zhao

Pre-Prepare Phase Backup Primary <<PRE-PREPARE, v, n, d> , m> Backup Note that d is the digest of the message m (i.e., hash value of m). It is NOT the digital signature for the pre-prepare message!!!! The digital signature is not explicitly included in the message shown in the illustration here and later!!! v – view number n – sequence number d – digest of the message D(m) m – message Backup 12/8/2018 EEC688/788: Secure & Dependable Computing Wenbing Zhao 27

Prepare Phase A backup accepts the PRE-PREPARE message only if: The signatures are valid and the digest matches m It is in view v It has not accepted a PRE-PREPARE for the same v and n Sequence number is within accepted bounds 12/8/2018 EEC688/788: Secure & Dependable Computing Wenbing Zhao

Prepare Phase If backup i accepts the pre-prepare message it enters prepare phase by multicasting <PREPARE, v, n, d, i> to all other replicas and adds both messages to its log Otherwise does nothing Replica (including primary) accepts prepare message and adds them to its log, provided that Signatures are correct View numbers match the current view Sequence number is within accepted bounds d is message digest! NOT digital signature! 12/8/2018 EEC688/788: Secure & Dependable Computing Wenbing Zhao 29

Prepare Phase At replica i, prepared (m, v, n, i) = true, iff 2f PREPARE from different backups that match the pre-prepare When prepared = true, replica i multicasts <COMMIT, v, n, d , i> to other replicas 12/8/2018 EEC688/788: Secure & Dependable Computing Wenbing Zhao

Agreement Achieved If primary is non-faulty then all 2f+1 non-faulty replicas agree on the sequence number If primary is faulty Either ≥f+1 non-faulty replicas (majority) agree on some other sequence and the rest realize that the primary is faulty Or, all non-faulty replicas will suspect the primary is faulty When a faulty primary is replaced, the minority of confused non-faulty replicas are brought up to date up by the majority 12/8/2018 EEC688/788: Secure & Dependable Computing Wenbing Zhao

Commit Phase Replicas accept commit messages and insert them in their log provided signatures are same Define committed and committed-local predicates as Committed (m, v, n) = true, iff prepared (m, v, n, i) is true for all i in some set of f+1 non-faulty replicas Committed-local (m, v, n, i) = true iff the replica has accepted 2f+1 commit message from different replicas that match the pre-prepare for m If Committed-local (m,v,n,i) is true for some non-faulty replica i, then committed (m,v,n) is true 12/8/2018 EEC688/788: Secure & Dependable Computing Wenbing Zhao

Commit Phase Replica i executes the operation requested by m after committed-local (m, v, n, i) = true and i’s state reflects the sequential execution of all requests with lower sequence numbers The PRE-PREPARE and PREPARE phases of the protocol ensure agreement on the total order of requests within a view The PREPARE and COMMIT phases ensure total ordering across views 12/8/2018 EEC688/788: Secure & Dependable Computing Wenbing Zhao

Normal Operation Reply
All replicas sends the reply <REPLY, v, t, c, i, r>, directly to the client v = current view number t = timestamp of the corresponding request i = replica number r = result of executing the requested operation c = client id Client waits for f+1 replies with valid signatures from different replicas, and with same t and r, before accepting the result r 12/8/2018 EEC688/788: Secure & Dependable Computing Wenbing Zhao

Normal Case Operation: Summery
Request Pre-prepare Prepare Commit Reply C Primary: 0 1 2 Faulty: 3 X 12/8/2018 EEC688/788: Secure & Dependable Computing Wenbing Zhao

Garbage Collection Used to discard messages from the log For the safety condition to hold, messages must be kept in a replica’s log until it knows that the requests have been executed by at least f+1 non-faulty replicas Achieved using a checkpoint, which occur when a request with sequence number (n) is divisible by some constant is executed May not get to this 12/8/2018 EEC688/788: Secure & Dependable Computing Wenbing Zhao 36

Garbage Collection When a replica i produces a checkpoint it multicasts a message <CHECKPOINT, n, d, i> to other replicas Each replica collects checkpoint messages in its log until it has 2f+1 of them for sequence number n with same digest d This creates a stable checkpoint and the replica discards all the pre-prepare, prepare and commit messages n is the sequence number of the last request whose execution is reflected in the state d is digest of the checkpoint 12/8/2018 EEC688/788: Secure & Dependable Computing Wenbing Zhao 37

View Changes Triggered by timeouts that prevent backups from waiting indefinitely for request to execute If the timer of backup expires in view v, the backup starts a view change to move to view v+1 by, Not accepting messages (other than checkpoint, view-change, and new-view messages) Multicasting a VIEW-CHANGE message What prompts a view change? When does the tiimer start? Stop? 12/8/2018 EEC688/788: Secure & Dependable Computing Wenbing Zhao 38

View Changes VIEW-CHANGE message is defined as <VIEW-CHANGE, v+1, n, C, P, i> where, C = 2f + 1 checkpoint messages P = set of sets Pm Pm = a PRE-PREPARE msg + all PREPARE messages for all messages with committed = false Here n is the sequence number of the last stable checkpoint s known to i, 12/8/2018 EEC688/788: Secure & Dependable Computing Wenbing Zhao 39

View Change - Primary Primary p of view v+1 receives 2f valid VIEW-CHANGE messages Multicasts a <NEW-VIEW, v+ 1, V, O> message to all other replicas where V = set of 2f valid VIEW-CHANGE messages O = set of reissued PRE-PREPARE messages Moves to view v+1 12/8/2018 EEC688/788: Secure & Dependable Computing Wenbing Zhao

View Changes - Backups Accepts NEW-VIEW by checking V and O Sends PREPARE messages for everything in O These PREPARE messages carry view v+1 Moves to view v+1 The primary creates a new pre-prepare message for view v+1 for each sequence number between min-s and max-s. There are two cases: (1) there is at least one set in the P component of some view-change message in V with sequence number n, or (2) there is no such set. In the first case, the primary creates a new message <PRE-PREPARE,v+1,n,d>, where d is the request digest in the pre-prepare message for sequence number with the highest view number in V. In the second case, it creates a new preprepare message <PRE-PREPARE,v+1,d,d^null>, where d^null is the digest of a special null request; a null request goes through the protocol like other requests, but its execution is a no-op. 12/8/2018 EEC688/788: Secure & Dependable Computing Wenbing Zhao 41

Events Before the View Change
Before the view change we have two groups of non-faulty replicas: the Confused minority and the Agreed majority A non-faulty replica becomes Confused when it is kept by the faulty's from agreeing on a sequence number for a request It can't process this request and so it will time out, causing the replica to vote for a new view 12/8/2018 EEC688/788: Secure & Dependable Computing Wenbing Zhao 42

The minority Confused replicas send a VIEW-CHANGE message and drop off the network The majority Agreed replicas continue working as long as the faulty's help with agreement The two groups can go out of synch but the majority keeps working until the faulty's cease helping with agreement 12/8/2018 EEC688/788: Secure & Dependable Computing Wenbing Zhao 43

System State: Faulty Primary
Is Erroneous View Change Possible? System State Confused Minority ≤f non-faulty replicas Agreed Majority ≥f+1 non-faulty replicas Agreed Majority ≥f+1 non-faulty replicas Confused Minority ≤f non-faulty replicas Adversary f non-faulty replicas P Adversary f non-faulty replicas P f faulty replicas f faulty replicas ≤2f replicas: NOT enough to change views 12/8/2018 EEC688/788: Secure & Dependable Computing Wenbing Zhao 44

Given ≥f+1 non-faulty replicas that are trying to agree, the faulty replicas can either help that or hinder that If they help, then agreement on request ordering is achieved and the clients get ≥f+1 matching replies for all requests with the faulty's help If they hinder, then the ≥f+1 non-faulty's will time out and demand for a new view When the new majority is in favor of a view change, we can proceed to the new view Can we have a confused majority while the remaining minority correct replicas keep working? No because they have no way to get 2f+1 matching messages to do anything 12/8/2018 EEC688/788: Secure & Dependable Computing Wenbing Zhao 45

Is it possible to continue processing requests? System State Confused Minority ≤f non-faulty replicas Confused Minority ≤f non-faulty replicas Agreed Majority ≥f+1 non-faulty replicas Agreed Majority ≥f+1 non-faulty replicas Adversary P Adversary f non-faulty replicas P f faulty replicas f faulty replicas YES ≥2f+1 replicas: enough for agreement 12/8/2018 EEC688/788: Secure & Dependable Computing Wenbing Zhao 46

Majority now large enough to independently move to a new view Confused Minority ≤f non-faulty replicas Agreed Majority ≥f+1 non-faulty replicas Adversary f non-faulty replicas YES ≥2f+1 replicas: enough for agreement Confused Majority 2f+1 non-faulty replicas Enough to agree to change views P Adversary f non-faulty replicas P f faulty replicas f faulty replicas Faulty replicas cease helping with agreement 12/8/2018 EEC688/788: Secure & Dependable Computing Wenbing Zhao 47

Liveness Replicas must move to a new view if they are unable to execute a request To avoid starting a view change too soon, a replica that multicasts a view-change message for view v+1, waits for 2f+1 view-change messages and then starts the timer T If the timer T expires before receiving new-view message it starts the view change for view v+2 The timer will wait 2T before starting a view-change from v+2 to v+3 12/8/2018 EEC688/788: Secure & Dependable Computing Wenbing Zhao

Liveness If a replica receives f+1 valid view-change messages from other replicas for views greater than its current view, it sends a view-change message for the smallest view in the set, even if T has not expired Faulty replicas cannot cause a view-change by sending a view-change message since a view-change will happen only if at least f+1 replicas send view-change message The above techniques guarantee liveness, unless message delays grow faster than the timeout period indefinitely 12/8/2018 EEC688/788: Secure & Dependable Computing Wenbing Zhao

EEC 688/788 Secure and Dependable Computing

Similar presentations

Presentation on theme: "EEC 688/788 Secure and Dependable Computing"— Presentation transcript:

Similar presentations

About project

Feedback

Log in

Auth with social network:

EEC 688/788 Secure and Dependable Computing

Similar presentations

Presentation on theme: "EEC 688/788 Secure and Dependable Computing"— Presentation transcript:

Similar presentations

About project

Feedback