eec 688/788 secure and dependable computing lecture 15 wenbing zhao department of electrical and...

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

Lecture 15Lecture 15

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:

Midterm #3, next Monday 4/25 4/27 no class (work on your project) Project presentation (oral exam):

5/2, 5/4, 5/11 Final Project due: May 11 midnight

Typed project report All source code

Practical Byzantine fault tolerance By Miguel Castro and Barbara Liskov, OSDI’99 http://www.pmg.csail.mit.edu/papers/osdi99.pdf



Garbage CollectionGarbage 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



Garbage CollectionGarbage 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



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

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 lecture 15 wenbing zhao department of electrical and...

Documents