eec 688/788 secure and dependable computing

EEC 688/788EEC 688/788Secure and Dependable Secure and Dependable ComputingComputing

Lecture 14Lecture 14

Wenbing ZhaoWenbing ZhaoDepartment of Electrical and Computer EngineeringDepartment of Electrical and Computer Engineering

Cleveland State UniversityCleveland State University

[email protected]@ieee.org

04/21/2304/21/23EEC688/788: Secure & Dependable EEC688/788: Secure & Dependable

ComputingComputing Wenbing ZhaoWenbing Zhao

OutlineOutline 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



View ChangesView 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



View ChangesView Changes

VIEW-CHANGE message is defined as<VIEW-CHANGE, v+1, n, C, P, i> where, C = 2f + 1 checkpoint messagesP = set of sets PmPm = a PRE-PREPARE msg + all PREPARE messages

for all messages with committed = false



View Change - PrimaryView 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



View Changes - BackupsView 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



Events Before the View Events Before the View ChangeChange

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




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



System State: Faulty PrimarySystem State: Faulty Primary

Confused Minority≤f non-faulty

replicas

Agreed Majority≥f+1 non-faulty replicas

Adversaryf non-faulty replicas

P

System State



≤2f replicas: NOT enough to change views

Is Erroneous View Change Possible?

P

Confused Minority≤f non-faulty replicas

f faulty replicas

f faulty replicas




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







P

System StateIs it possible to continueprocessing requests?



Adversary

YES ≥2f+1 replicas: enough for agreement

P

f faulty replicas f faulty replicas








YES ≥2f+1 replicas: enough for agreement

Faulty replicas cease helping with agreement

PP

Confused Majority2f+1 non-faulty replicas

Enough to agree to change views

Majority now large enough to independently move to a new view

f faulty replicasf faulty replicas



LivenessLiveness 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



LivenessLiveness 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

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

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)

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

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

Zyzzyva: Agreement Protocol, Case 1

Zyzzyva: Agreement Protocol, Case 2

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

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

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

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

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

ExercisesExercises

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



eec 688/788 secure and dependable computing

Documents

view v

view changebefore

view changegiven f

newview messagesmulticasting

groups of nonfaulty

f valid viewchange messageso

view changethe minority

replicas wherev