EEC 693793 Special Topics in Electrical Engineering Secure

EEC 693/793 Special Topics in Electrical Engineering Secure and Dependable Computing Lecture 15 Wenbing Zhao Department of Electrical and Computer Engineering Cleveland State University wenbing@ieee. org

2 Outline • Reminder: – Project Progress Report due this Friday midnight • Byzantine general problem – By Leslie Lamport, Robert Shostak, & Marshall Pease – http: //berkeley. intel-research. net/maniatis/p 382 lamport. pdf • Practical Byzantine fault tolerance – By Miguel Castro and Barbara Liskov, OSDI’ 99 – http: //www. pmg. csail. mit. edu/papers/osdi 99. pdf Spring 2008 EEC 693: Secure & Dependable Computing Wenbing Zhao

3 The Byzantine Generals Problem • Abstract model of a computer system that may have faulty components • Faulty components may send conflicting information to different parts of the system • Scenario where Byzantine Generals must reach agreement in the presence of traitors Spring 2008 EEC 693: Secure & Dependable Computing Wenbing Zhao

The Byzantine Generals Scenario General Commanding Lieutenant General Byzantine Army Division Enemy City General Lieutenant General Traitorous General Byzantine Army Division Spring 2008 EEC 693: Secure & Dependable Computing Wenbing Zhao 4

Byzantine Generals Problem • A commanding general must send an order to his n-1 lieutenants such that – IC 1. All loyal lieutenants obey the same order – IC 2. If the commanding general is loyal, then every loyal lieutenant obeys the order he sends • IC 1 = Agreement clause • IC 2 = Validity clause • IC 1 and IC 2 are called interactive consistency Conditions Spring 2008 EEC 693: Secure & Dependable Computing Wenbing Zhao 5

Byzantine Agreement Protocol • Assumption: – Every message that is sent is delivered correctly • Traitors cannot interfere with messages they do not sent – The receiver of a message knows who sent it • Traitors cannot spoof messages – The absence of a message can be detected • Traitors cannot prevent an agreement by not sending => Synchronous system + no spoofing Spring 2008 EEC 693: Secure & Dependable Computing Wenbing Zhao 6

7 Byzantine Agreement Protocol (f=1) • Round 1: the commander sends a value to each of the lieutenants • Round 2: each of the lieutenants sends the value it received to its peers • At the end of round 2, each lieutenant check to see if there is a majority opinion (attack or retreat). We have a solution if there is • Question is: how many generals needed to tolerate f number of traitors? Spring 2008 EEC 693: Secure & Dependable Computing Wenbing Zhao

8 Unsolvable Situations – N=3, f=1 Attack lieutenant Commander Attack He said Retreat lieutenant Commander Attack lieutenant Spring 2008 Retreat He said Retreat EEC 693: Secure & Dependable Computing lieutenant Wenbing Zhao

9 Byzantine Agreement Protocol (f=1) Commander Attack lieutenant Retreat He said Retreat lieutenant He said Attack He said Retreat He said Attack lieutenant He said Attack • If there are f traitors, then there must be at least 3 f + 1 total generals for IC 1 and IC 2 to hold Spring 2008 EEC 693: Secure & Dependable Computing Wenbing Zhao

10 Byzantine Agreement Protocol (f=1) • Under our assumption, if message digital signature is used and assuming the signature cannot be forged, we need only N=2 f+1 to tolerate f traitors – The commander still can send different information to different lieutenant, but a lieutenant cannot lie about what the commander has told him • In asynchronous systems, N=2 f+1 is not sufficient – We have to stop after collecting f+1 input because the f faulty traitor could simply refrain from sending – Unfortunately there might be f inputs from traitors Spring 2008 EEC 693: Secure & Dependable Computing Wenbing Zhao

Introduction to BFT Paper • The growing reliance of industry and government on online information services • Malicious attacks become more serious and successful • More software errors due to increased size and complexity of software • This paper presents “practical” algorithm for state machine replication that works in asynchronous systems like the Internet Spring 2008 EEC 693: Secure & Dependable Computing Wenbing Zhao 11

12 Assumptions • Asynchronous distributed system • The network may fail to deliver, delay, duplicate or deliver them out of order • Faulty nodes may behave arbitrarily • Independent node failures • The adversary cannot delay correct nodes indefinitely • All messages are cryptographically signed by their sender and these signatures cannot be subverted by the adversary Spring 2008 EEC 693: Secure & Dependable Computing Wenbing Zhao

13 Service Properties • A (deterministic) service is replicated among ≥ 3 f+1 processors. Resilient to ≤ f failures • Safety: All non-faulty replicas guaranteed to process the same requests in the same order • Liveness: Clients eventually receive replies to their requests Spring 2008 EEC 693: Secure & Dependable Computing Wenbing Zhao

14 Optimal Resiliency • Imagine non-faulty processors trying to agree upon a piece of data by telling each other what they believe the data to be • A non-faulty processor must be sure about a piece of data before it can proceed • f replicas may refuse to send messages, so each processor must be ready to proceed after having received (n-1)-f messages – Total of n-1 other replicas Spring 2008 EEC 693: Secure & Dependable Computing Wenbing Zhao

15 Optimal Resiliency • But what if f of the (n-1)-f messages come from faulty replicas? • To avoid confusion, the majority of messages must come from non-faulty nodes, i. e, (n-f-1)/2 ≥ f => Need a total of ≥ 3 f+1 replicas Spring 2008 EEC 693: Secure & Dependable Computing Wenbing Zhao

BFT Algorithm in a Nutshell Backup f + 1 Match (OK) Client Primary Backup Spring 2008 EEC 693: Secure & Dependable Computing Wenbing Zhao 16

17 Replicas and Views Set of replicas (R): |R| ≥ 3 f + 1 R 0 R 1 R 2 ……… R|R-1| 0 View 1 For view v: primary p is assigned such that p= v mod |R| Spring 2008 EEC 693: Secure & Dependable Computing Wenbing Zhao

18 Safeguards • If the client does not receive replies soon enough, it broadcasts the request to all replicas • If the request has already been processed, the replicas simply re-send the reply (replicas remember the last reply message they sent to each client) • If the primary does not multicast the request to the group, it will eventually be suspected to be faulty by enough replicas to cause a view change Spring 2008 EEC 693: Secure & Dependable Computing Wenbing Zhao

19 Normal Case Operation Client {REQUEST, o, t, c} Primary o – Operation t – Timestamp c - Client Timestamps are totally ordered such that later requests have higher timestamps than earlier ones Spring 2008 EEC 693: Secure & Dependable Computing Wenbing Zhao

20 Normal Case Operation • Primary p receives a client request m , it starts a three-phase protocol • Three phases are: pre-prepare, commit Spring 2008 EEC 693: Secure & Dependable Computing Wenbing Zhao

21 Pre-Prepare Phase Backup Primary <<PRE-PREPARE, v, n, d> , m> v – view number n – sequence number d – digest of the message D(m) m – message Spring 2008 EEC 693: Secure & Dependable Computing Backup Wenbing Zhao

22 Prepare Phase • A backup accepts the PRE-PREPARE message only if: – The signatures are valid and the digest matches m – It is in view v – It has not accepted a PRE-PREPARE for the same v and n – Sequence number is within accepted bounds Spring 2008 EEC 693: Secure & Dependable Computing Wenbing Zhao

23 Prepare Phase • If backup i accepts the pre-prepare message it enters prepare phase by multicasting <PREPARE, v, n, d, i> to all other replicas and adds both messages to its log • Otherwise does nothing • Replica (including primary) accepts prepare message and adds them to its log, provided that – Signatures are correct – View numbers match the current view – Sequence number is within accepted bounds Spring 2008 EEC 693: Secure & Dependable Computing Wenbing Zhao

24 Prepare Phase • • At replica i, prepared (m, v, n, i) = true, iff 2 f PREPARE from different backups (not including replica i) that match the pre-prepare When prepared = true, replica i multicasts <COMMIT, v, n, d , i> to other replicas Spring 2008 EEC 693: Secure & Dependable Computing Wenbing Zhao

25 Agreement Achieved • If primary is non-faulty then all 2 f+1 non-faulty replicas agree on the sequence number • If primary is faulty – Either ≥f+1 non-faulty replicas (majority) agree on some other sequence and the rest realize that the primary is faulty – Or, all non-faulty replicas will suspect the primary is faulty • When a faulty primary is replaced, the minority of confused non-faulty replicas are brought up to date up by the majority Spring 2008 EEC 693: Secure & Dependable Computing Wenbing Zhao

26 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 of f+1 non-faulty replicas – Committed-local (m, v, n, i) = true iff the replica has accepted 2 f+1 commit message from different replicas that match the pre-prepare for m • If Committed-local (m, v, n, i) is true for some nonfaulty replica i, then committed (m, v, n) is true Spring 2008 EEC 693: Secure & Dependable Computing Wenbing Zhao

27 Commit Phase • Replica i executes the operation requested by m after committed-local (m, v, n, i) = true and i’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 Spring 2008 EEC 693: Secure & Dependable Computing Wenbing Zhao

28 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 operation c = 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 Spring 2008 EEC 693: Secure & Dependable Computing Wenbing Zhao

Normal Case Operation: Summery Request Pre-prepare Prepare Commit Reply C Primary: 0 1 2 Faulty: 3 Spring 2008 X EEC 693: Secure & Dependable Computing Wenbing Zhao 29