EEC 688 Secure and Dependable Computing

1. EEC 688Secure and Dependable Computing Lecture 16 Wenbing Zhao Department of Electrical and Computer Engineering Cleveland State University wenbing@ieee.org

2. Outline • Reminder: • Midterm #3, May 4, Monday 4-5:50pm • Project presentation: • May 6 4-5:50pm, attendance mandatory • Project report due: May 11 midnight • Practical Byzantine fault tolerance • By Miguel Castro and Barbara Liskov, OSDI’99 • http://www.pmg.csail.mit.edu/papers/osdi99.pdf EEC688: Secure & Dependable Computing

3. 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 off+1non-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 EEC688: Secure & Dependable Computing

4. Commit Phase • Replica i executes the operation requested by m after committed-local (m, v, n, i) = true andi’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 EEC688: Secure & Dependable Computing

5. 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 operationc = 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 EEC688: Secure & Dependable Computing

6. Normal Case Operation: Summery Request Pre-prepare Prepare Commit Reply C Primary: 0 1 2 Faulty: 3 X EEC688: Secure & Dependable Computing

7. 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 EEC688: Secure & Dependable Computing

8. 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 EEC688: Secure & Dependable Computing

9. 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 EEC688: Secure & Dependable Computing

10. 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 EEC688: Secure & Dependable Computing

11. 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 EEC688: Secure & Dependable Computing

12. 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 EEC688: Secure & Dependable Computing

13. 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 EEC688: Secure & Dependable Computing

14. Events Before the View Change • 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 EEC688: Secure & Dependable Computing

15. 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 f faulty replicas P f faulty replicas ≤2f replicas: NOT enough to change views EEC688: Secure & Dependable Computing

16. Events Before the View Change • 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 EEC688: Secure & Dependable Computing

17. System State: Faulty Primary 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 f non-faulty replicas P Adversary f non-faulty replicas P f faulty replicas f faulty replicas YES ≥2f+1 replicas: enough for agreement EEC688: Secure & Dependable Computing

18. 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 System State: Faulty Primary Majority now large enough to independently move to a new view Confused Majority 2f+1 non-faulty replicas Enough to agree to change views Adversary f non-faulty replicas P P f faulty replicas f faulty replicas Faulty replicas cease helping with agreement EEC688: Secure & Dependable Computing

19. 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 EEC688: Secure & Dependable Computing

20. 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 EEC688: Secure & Dependable Computing

21. Exercises • 1. Prove that the use of 3f+1 replicas to tolerate f Byzantine faulty replicas is optimal • 2. Prove the safety property of the BFT algorithm when all non-faulty replicas reach an agreement within the same view EEC688: Secure & Dependable Computing