1 / 26

EEC 688/788 Secure and Dependable Computing

EEC 688/788 Secure and Dependable Computing. Lecture 14 Wenbing Zhao Department of Electrical and Computer Engineering Cleveland State University wenbing@ieee.org. Outline. Reminder: Last day to submit all lab reports: Next Monday 11/25 Midterm #3, next Monday 11/25

maili
Download Presentation

EEC 688/788 Secure and Dependable Computing

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. 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: Last day to submit all lab reports: Next Monday 11/25 Midterm #3, next Monday 11/25 11/27 no class (Thanksgiving eve) Project presentation (oral exam): 12/2, 12/4, 12/9 Final Project due: Dec 9 midnight Typed project report Must be uploaded to turnitin.com Practical Byzantine fault tolerance Zyzztva 9/21/2014 EEC688/788: Secure & Dependable Computing Wenbing Zhao

  3. 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 9/21/2014 EEC688/788: Secure & Dependable Computing Wenbing Zhao

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

  5. 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 9/21/2014 EEC688/788: Secure & Dependable Computing Wenbing Zhao

  6. 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 9/21/2014 EEC688/788: Secure & Dependable Computing Wenbing Zhao

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

  8. 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 9/21/2014 EEC688/788: Secure & Dependable Computing Wenbing Zhao

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

  10. 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 9/21/2014 EEC688/788: Secure & Dependable Computing Wenbing Zhao

  11. 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 9/21/2014 EEC688/788: Secure & Dependable Computing Wenbing Zhao

  12. 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 9/21/2014 EEC688/788: Secure & Dependable Computing Wenbing Zhao

  13. 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 9/21/2014 EEC688/788: Secure & Dependable Computing Wenbing Zhao

  14. 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 9/21/2014 EEC688/788: Secure & Dependable Computing Wenbing Zhao

  15. 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 hthe 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

  16. 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: his 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)

  17. 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

  18. 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

  19. Zyzzyva: Agreement Protocol, Case 1

  20. Zyzzyva: Agreement Protocol, Case 2

  21. 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

  22. 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

  23. Zyzzyva: View Change Protocol What is special in Zyzzyva At most one round 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

  24. 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

  25. 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

  26. 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 9/21/2014 EEC688/788: Secure & Dependable Computing Wenbing Zhao

More Related