Transcript Document

Practical Byzantine Fault Tolerance
Jayesh V. Salvi
[email protected]
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
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 Problem
G1
G2
G5
G3
G4
4
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
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
Message Passing in State Machine
Request
Pre-Prepare
Prepare
Commit
Result
C
0(P)
1(B)
2(B)
3(B)
,
<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
t
7
Typical states of a backup
PRE-PREPARE from Primary
Sending PREPARE messages
2f PREPAREs that match
PRE-PREPARE
Sending COMMIT
messages
Prepared
(m,v,n,i)
2f+1 COMMITS that
match PRE-PREPARE
Committed-local
(m,v,n,i)
Result To Client
8
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 checkpoint 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 - 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
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
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 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
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
Session Key establishment
i chooses a new key Kj,i to 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
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
Attacks
Attack on Safety:
Request
Pre-Prepare
C
0(P)
1(B)
0 will assign a sequence number for m in its log
1 will not assign a sequence number for m in its log
2(B)
2 will assign a sequence number for m in its log
3(B)
3 will assign a sequence number for m in its log
17
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
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 backups
Request
Pre-Prepare
C
0(P)
1(B)
2(B)
3(B)
20
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
Incorrect MAC to primary & Correct MAC to backups
Request
Pre-Prepare
C
0(P)
1(B)
2(B)
3(B)
22
Solution
Backups only accept retransmitted requests with digital
signatures
23
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
When do you need proof?
Garbage Collection
View - change
25
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
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
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
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
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
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
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-LCSTR-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
Thank You !
33