EEC 693/793 Special Topics in Electrical Engineering Secure and Dependable Computing

1. EEC 693/793Special Topics in Electrical EngineeringSecure 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/p382-lamport.pdf • Practical Byzantine fault tolerance • By Miguel Castro and Barbara Liskov, OSDI’99 • http://www.pmg.csail.mit.edu/papers/osdi99.pdf EEC693: Secure & Dependable Computing

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 EEC693: Secure & Dependable Computing

4. The Byzantine Generals Scenario Lieutenant General General General Commanding General Byzantine Army Division Byzantine Army Division Enemy City General General Lieutenant General Lieutenant General Traitorous General Byzantine Army Division Byzantine Army Division EEC693: Secure & Dependable Computing

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

6. 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 EEC693: Secure & Dependable Computing

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? EEC693: Secure & Dependable Computing

8. Unsolvable Situations – N=3, f=1 Commander Attack Attack He said Retreat lieutenant lieutenant Commander Attack Retreat He said Retreat lieutenant lieutenant EEC693: Secure & Dependable Computing

9. Byzantine Agreement Protocol (f=1) Commander • If there are f traitors, then there must be at least 3f + 1 total generals for IC1 and IC2 to hold Attack Retreat He said Retreat lieutenant lieutenant He said Attack He said Attack He said Attack Attack He said Retreat He said Attack lieutenant He said Attack EEC693: Secure & Dependable Computing

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=2f+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=2f+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 EEC693: Secure & Dependable Computing

11. Introduction to BFTPaper • 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 EEC693: Secure & Dependable Computing

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 EEC693: Secure & Dependable Computing

13. Service Properties • A (deterministic) service is replicated among ≥ 3f+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 EEC693: Secure & Dependable Computing

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 EEC693: Secure & Dependable Computing

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 ≥3f+1 replicas EEC693: Secure & Dependable Computing

16. BFT Algorithm in a Nutshell Backup f + 1 Match (OK) Primary Client Backup Backup EEC693: Secure & Dependable Computing

17. Replicas and Views Set of replicas (R): |R| ≥ 3f + 1 R1 R1 R0 R0 R0 R|R-1| R2 ……… View 0 View 1 For view v: primary p is assigned such that p= v mod |R| EEC693: Secure & Dependable Computing

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 EEC693: Secure & Dependable Computing

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

20. Normal Case Operation • Primary p receives a client request m , it starts a three-phase protocol • Three phases are: pre-prepare, prepare, commit EEC693: Secure & Dependable Computing

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

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 EEC693: Secure & Dependable Computing

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 EEC693: Secure & Dependable Computing

24. Prepare Phase • At replica i, prepared (m, v, n, i) = true, iff 2f 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 EEC693: Secure & Dependable Computing

25. Agreement Achieved • If primary is non-faulty then all 2f+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 EEC693: Secure & Dependable Computing

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

27. Commit Phase • Replica i executes the operation requested by m after committed-local (m, v, n, i) = true andi’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 EEC693: Secure & Dependable Computing

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 operationc = 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 EEC693: Secure & Dependable Computing

29. Normal Case Operation: Summery Request Pre-prepare Prepare Commit Reply C Primary: 0 1 2 Faulty: 3 X EEC693: Secure & Dependable Computing