33
ContentsContents
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
IntroductionIntroduction
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
Byzantine Generals ProblemByzantine Generals Problem
G1
G4G3
G2 G5
4
Solution for Byzantine GeneralsSolution 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
Our Battlefield – State MachineOur 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
Message Passing in State MachineMessage Passing in State Machine
C
0(P)
1(B)
2(B)
3(B)
Request
Pre-Prepare Prepare Commit Result
t<REQUEST, o, t, c>σc
<<PRE-PREPARE, v, n, d> σp, m><PREPARE, v, n, d, i> σi
<COMMIT, v, n, D(m), i> σi
<REPLY, v, t, c, i, r> σi
7
Typical states of a backupTypical 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
Garbage collectionGarbage collection
The logs are cleaned periodicallyThe 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
View - changeView - change
When backups suspect Primary they call for a View When backups suspect Primary they call for a View changechange
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, A backup sends <VIEW-CHANGE, v+1, n, C, P, i >v+1, n, C, P, i >σiσi
C is a proof of last stable check-point
P is a proof of due requests after the check-point
10
View - changeView - 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
Is this algorithm optimum?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
PK and MACPK and MAC
The MAC is a function of the message and the shared secret key
HMACK(M) = H( K1 || H(K2 || 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
Format of Authenticated messagesFormat 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
Session Key establishmentSession Key establishment
< NEW-KEY, i, j, < Kj,i >εj , t >σi
i chooses a new key Kj,i to be used by j, to compute MACs for messages sent by j to i.
t - time stamp (to avoid replay attack)
< Kj,i >εj - encryption with j ’s public key
15
How is the algorithm modified?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
AttacksAttacks
Attack on Safety:
C
0(P)
1(B)
2(B)
3(B)
Request
Pre-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
SolutionSolution
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
Degrading the Performance 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
Correct MAC to primary & Incorrect MAC to Correct MAC to primary & Incorrect MAC to backups backups
C
0(P)
1(B)
2(B)
3(B)
Request
Pre-Prepare
20
SolutionSolution
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
Incorrect MAC to primary & Correct MAC to Incorrect MAC to primary & Correct MAC to backups backups
C
0(P)
1(B)
2(B)
3(B)
Request
Pre-Prepare
22
SolutionSolution
Backups only accept retransmitted requests with digital signatures
23
Pre-Prepares, Prepares, CommitsPre-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
When do you need proof?When do you need proof?
Garbage Collection
View - change
25
Garbage CollectionGarbage 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
Garbage CollectionGarbage 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
View ChangesView 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
View ChangesView 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
OptimizationsOptimizations
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
ConclusionConclusion
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
ReferencesReferences
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 !
