1 / 33

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

Practical Byzantine Fault Tolerance Jayesh V. Salvi salvi@cs.umn.edu. 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. Introduction.

gafna
Download Presentation

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

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  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 nnumber 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 G2 G5 G3 G4 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. <REQUEST, o, t, c>σc <PREPARE, v, n, d, i> σi <REPLY, v, t, c, i, r> σi <<PRE-PREPARE, v, n, d>σp, m> <COMMIT, v, n, D(m), i> σi Message Passing in State Machine Request Pre-Prepare Prepare Commit Result C 0(P) 1(B) 2(B) 3(B) t 7

  8. PRE-PREPARE from Primary Sending PREPARE messages 2f PREPAREs that match PRE-PREPARE Prepared (m,v,n,i) Sending COMMIT messages 2f+1 COMMITS that match PRE-PREPARE Committed-local (m,v,n,i) Result To Client Typical states of a backup 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 • < CHECKPOINT, n,d,i >σ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 • 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 <VIEW-CHANGE, v+1, n, C, P, i >σ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 • < NEW-VIEW, v+1, V, O >σ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 • 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 • The MAC is a function of the message and the shared secret key • HMACK(M) = H( K1 || H(K2 || M) ) 13

  14. Format of Authenticated messages • Using MAC to authenticate point to point messages – • < m >, μi,j(m) • Using MACs in multicast messages – • < m > α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 i chooses a new key Kj,ito be used by j, to compute MACs for messages sent by j to i. < NEW-KEY,i, j, < Kj,i >εj , t >σi t - time stamp (to avoid replay attack) < Kj,i >εj - encryption with j ’s public key 15

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

  17. Attacks • Attack on Safety: Request Pre-Prepare C 0 will assign a sequence number for m in its log 0(P) 1 will not assign a sequence number for m in its log 1(B) 2 will assign a sequence number for m in its log 2(B) 3 will assign a sequence number for m in its log 3(B) 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 Request Pre-Prepare C 0(P) 1(B) 2(B) 3(B) 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 Request Pre-Prepare C 0(P) 1(B) 2(B) 3(B) 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 < CHECK-SIGN, n, i > α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 • <VIEW-CHANGE, v+1, n, C, P, i >σi • C is built as discussed in Garbage Collection • P is built by transmitting • <PREPARE-SIGN, v, n’, D(m), i >α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. Thank You ! 33

More Related