EEC 688/788 Secure and Dependable Computing

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

2. Outline Reminder: 11/6 (Thursday): Project consultation 11/11 (Tuesday): Veteran’s Day, No Class 11/13 (Thursday): Presidential Forum, No Class 11/18 presentation starts All project reports must be uploaded to turnitin.com Practical Byzantine fault tolerance Zyzztva 1/4/2020 EEC688/788: Secure & Dependable Computing Wenbing Zhao

3. 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 1/4/2020 EEC688/788: Secure & Dependable Computing Wenbing Zhao

4. 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 1/4/2020 EEC688/788: Secure & Dependable Computing Wenbing Zhao

5. 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 1/4/2020 EEC688/788: Secure & Dependable Computing Wenbing Zhao

6. 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 1/4/2020 EEC688/788: Secure & Dependable Computing Wenbing Zhao

7. 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 P Adversary f non-faulty replicas P f faulty replicas f faulty replicas YES ≥2f+1 replicas: enough for agreement 1/4/2020 EEC688/788: Secure & Dependable Computing Wenbing Zhao

8. System State: Faulty Primary 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 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 1/4/2020 EEC688/788: Secure & Dependable Computing Wenbing Zhao

9. 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 1/4/2020 EEC688/788: Secure & Dependable Computing Wenbing Zhao

10. 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 1/4/2020 EEC688/788: Secure & Dependable Computing Wenbing Zhao

11. Zyzzyva: Speculative BFT A replica speculatively executes a request as soon as it receives a valid pre-prepare msg Commitment of a request is moved to the client A request is said to have completed at the issuing client if the corresponding reply can be safely delivered If a request completes at a client, the request will eventually be committed at the server replicas Prepare and commit phases are reduced to a single phase View change has one more additional phase

12. Zyzzyva: Speculative BFT History hash: helps client determine if its request has been ordered appropriately Server replica maintains a history hash for each request ordered and appends the history hash hs = H(hs-1,ds) to the reply for the request with sequence number s ds: digest for the request Previous hash: hs-1, new hash with request s executed: hs H(): hash function Prefix concept: h is is a prefix of hsj if sj > si, and there exist a set of requests with sequence numbers si+1, si+2, …, sj-1 with digests dsi+1, dsi+2,…,dsj-1 such that hsi+1=H(hsi, dsi+1), hsi+2 = H(hsi+1,dsi+2),…,hsj=H(hsj-1,dsj)

13. Zyzzyva: Speculative BFT Safety: given any two requests that have completed, they must have been assigned two different sequence numbers. Furthermore, if the two sequence numbers are i and j an i < j, the history hash hi must be a prefix of hj Liveness: if a nonfaulty client issues a request, the request eventually completes

14. Zyzzyva: Agreement Protocol A client maintains a complete timer for each request A request may complete at the client in one of two cases: Case 1: client receives 3f+1 matching replies => all replicas have executed the request in the same total order Case 2: client receives at least 2f+1 matching replies when timer expires. The client then initiates another round of msg exchange with the server replicas before the request is declared as complete

15. Zyzzyva: Agreement Protocol, Case 1

16. Zyzzyva: Agreement Protocol, Case 2

17. Zyzzyva: Case 2 Commit msg: contains a commit certificate: A list of 2f+1 replica ids Signed component of spec-response from each of the 2f+1 replicas Local-commit: a replica sends a local-commit when it receives a valid commit msg from client Verify history hash When the client receives 2f+1 or more local-commit, the request is completed and can be delivered

18. Zyzzyva: View Change Protocol When a view change is triggered Sufficient number of backups timed out the current primary When the client receives spec-response msgs with different sequence numbers or different history hash values In the 2nd case, client broadcasts a POM msg to all replicas Replica initiates a view change A replica also rebroadcasts POM upon receiving one => to speed up view change

19. Zyzzyva: View Change Protocol What is special in Zyzzyva At most one round of msg exchange during normal operation for agreement => equivalent to prepare phase (or commit phase), for case 2. Replicas would have commit certificate For case 1, replicas would not possess a commit certificate Impact on view change: Need an additional round msg exchange – “I hate the primary” Need to change condition on including a request in new-view msg Cannot use PBFT view change protocol: may lose liveness Faulty primary could force f nonfaulty replicas to suspect itself, but cooperate with other f+1 nonfaulty replicas f faulty replicas stops sending spec-response Client cannot complete any request: only receive f+1 matching replies

20. Zyzzyva: View Change Protocol PBFT view change A replica abandons the current view as soon as it suspects the primary: stops participating agreement for current view Zyzzyva view change Make sure a view change will actually take place before abandoning the current view Accomplished by using the “I hate primary” msg exchange: a replica abandons the current view only when it receives f+1 “I hate primary” msgs

21. Zyzzyva: View Change Protocol Zyzzyva view change: deal with case 1 A replica includes all order-req msgs received since latest stable checkpoint, or the most recent commit certificate New primary adopts request-seq# binding if f+1 or more matching order-req msgs The primary may see multiple sets for same seq# (for different requests): can select any of the bindings because none of them could have been completed A backup should accept the decision by the new primary for the ordering

22. Zyzzyva: View Change Protocol