1. Practical Byzantine Fault Tolerance Jayesh V. Salvi salvi@cs.umn.edu

2. Contents Introduction State Machine Working of state machine with Public Key Cryptography Alternative to PK - MAC Modification of algorithm to use with MACs Optimizations Conclusion 2

3. Introduction What is Byzantine Generals Problem? If n number of Byzantine generals are attacking an enemy city, then what is the maximum number of traitors that can be tolerated and the battle be won? Yes, it has a mathematical proof… 3

4. Byzantine Generals Problem G1 G4G3 G2G5 4

5. Solution for Byzantine Generals Traitors send wrong messages, so that the loyal generals cannot reach a valid consensus Loyal generals try to reach consensus, despite of the wrong messages sent by traitors It can be mathematically proved that, the army of n generals can reach consensus in the presence of (n-1)/3 or less traitors [ Ref: The Byzantine Generals Problem, Leslie Lamport, Robert Shostak, Marshall Pease, ACM Transactions on Programming Languages and systems, Vol. 4,No. 3, July 1982 ] 5

6. Our Battlefield – State Machine A state machine is a collection of multiple, identical, deterministic servers, providing a service Clients send requests to this machine and collect replies from multiple servers Principal tasks of state machine Request sequencing Execution of requests and result delivery Garbage collection (cleaning logs) View - change 6

7. Message Passing in State Machine C 0(P) 1(B) 2(B) 3(B) RequestPre-PreparePrepareCommitResult t σc σp, m> σi 7

8. Typical states of a backup PRE-PREPARE from Primary Prepared (m,v,n,i) 2f PREPAREs that match PRE-PREPARE Committed-local (m,v,n,i) 2f+1 COMMITS that match PRE-PREPARE Sending COMMIT messages Sending PREPARE messages Result To Client 8

9. Garbage collection The logs are cleaned periodically Before cleaning the logs a backup must be sure that all requests whose messages it is going to clean have been successfully executed After fixed number of requests replicas send check- point signals σi When a replica receives f+1 check-point messages, it clears all messages for requests up to n. 9

10. View - change When backups suspect Primary they call for a View change When backups suspect Primary they call for a View change A backup starts timer when it is waiting for executing a request and stops it when it is waiting no longer If timer times out something is wrong with Primary So change view so that Primary gets changed A backup sends σi C is a proof of last stable check-point P is a proof of due requests after the check-point 10

11. View - change When a primary of new view gets 2f VIEW-CHANGE messages, it declares new view The new Primary sends σi V is a proof containing valid VIEW-CHANGE messages O is a set containing PRE-PREPARE messages needed to carry the incomplete messages from previous view into new view 11

12. Is this algorithm optimum? Calculation of digital signatures is very time-consuming Is there any alternative – MACs ? + MACs are 3 orders of magnitude faster to compute than digital signatures – But, receiver of MAC cannot prove the authenticity of sender to third party 12

13. PK and MAC The MAC is a function of the message and the shared secret key HMAC K (M) = H( K 1 || H(K 2 || M) ) In Public Key Cryptography, it has been assumed that there are means for the sender of a message to obtain an authentic copy of the intended receiver’s public key Sender signs the message with his Private key and sends the message to receiver. The receiver verifies the authenticity by using sender’s public key 13

14. Format of Authenticated messages Using MAC to authenticate point to point messages –, μ i,j (m) Using MACs in multicast messages – αi This denotes that, it is an authenticator generated by i for a message m having an entry for every replica j other than i. 14

15. Session Key establishment εj, t > σi i chooses a new key K j,i to be used by j, to compute MACs for messages sent by j to i. t - time stamp (to avoid replay attack) εj - encryption with j ’s public key 15

16. How is the algorithm modified? Request αc, μ c,p (r) > Possible attacks from Client in Request phase: Attack on safety Degrading the performance 16

17. Attacks Attack on Safety: C 0(P) 1(B) 2(B) 3(B) RequestPre-Prepare 2 will assign a sequence number for m in its log 0 will assign a sequence number for m in its log 3 will assign a sequence number for m in its log 1 will not assign a sequence number for m in its log 17

18. Solution Even if the authenticity of a request cannot be verified at a backup, assign a sequence number to it Don’t transmit PREPARE message for it either But, if it is found that this sequence number request is committed at 2f+1 other backups, go ahead and execute the request 18

19. Degrading the Performance Performance can be degraded by forcing unnecessary view-changes, i.e. creating distrust between backups and primary Correct MAC to primary and Incorrect MACs to backups Incorrect MAC to primary and Correct MACs to backups 19

20. Correct MAC to primary & Incorrect MAC to backups C 0(P) 1(B) 2(B) 3(B) RequestPre-Prepare 20

21. Solution Primary aborts such requests The view changes are performed but with Primary unchanged Subsequently Primary accepts requests from the Client only if they are signed with its private key 21

22. Incorrect MAC to primary & Correct MAC to backups C 0(P) 1(B) 2(B) 3(B) RequestPre-Prepare 22

23. Solution Backups only accept retransmitted requests with digital signatures 23

24. Pre-Prepares, Prepares, Commits They work same as in previous algorithm In normal cases replicas only need to authenticate the sender of message and need not prove that to others MACs are sufficient for this But you need proof sometime… 24

25. When do you need proof? Garbage Collection View - change 25

26. Garbage Collection To reach a stable check-point you need f+1 CHECKPOINT messages You have to prove this in your VIEWCHANGE message The backup lazily builds the proof Proof is nothing but the same messages resent by the non-faulty backups, with the signature A backups ask for proof by sending αi When they receive f+1 signed check-point messages they are ready with a proof 26

27. Garbage Collection But what if not all of f+1 backups resend check-point messages Those might have come from disguised faulty replicas So wait for 2f+1 messages in the first place, so that at least f+1 of them will reply at the time of building proof 27

28. View Changes View change message is same σi C is built as discussed in Garbage Collection P is built by transmitting αi for each m, such that prepared(m,v,n’,i) is true for some v and n’ > n 28

29. View Changes The receiving non-faulty replica responds in following two ways: If it has stable checkpoint >= n’, then it responds as if the message was CHECK-SIGN message Else it sends signed copy of PRE-PREPARE and PREPARES for m, which it has in its log 29

30. Optimizations The C component and P component can be formed by digests of messages to reduce the size of these messages Don’t make all replicas to send same big result to the client. Send one original result and other digests of that result 30

31. Conclusion This algorithm can tolerate independent software errors occurring at different replicas It is the first to work correctly in an asynchronous system like the Internet Use of MAC vectors instead of Public Keys improves performance. 31

32. References Miguel Castro, Barbara Liskov, Practical Byzantine Fault Tolerance, Proceedings of the Third Symposium on Operating Systems Design and Implementation,New Orleans, LA, February 1999 Miquel Castro, Barbara Liskov, Authenticated Byzantine Fault Tolerance, Without Public-Key Cryptography, Technical Memo MIT/LCS/TM-589,MIT Laboratory for Computer Science, June 1999 Miguel Castro, Practical Byzantine Fault Tolerance, MIT-LCS- TR-817, (Thesis) Leslie Lamport, Robert Shostak, and Marshall Pease, The Byzantine Generals Problem, ACM Transactions on Programming Languages and Systems, Vol. 4, No.3, July 1982 32

33. 33 Thank You !