PBFT: Add Byzantine mode to servers

[rfairley]

Byzantine mode causes servers to simulate a fault where whenever they receive a client message, they rewrite the value of the message with the character 'b', and overwrite the digest, before sending a pre-prepare. Nonfaulty servers will detect this fault by checking the pre-prepare for a valid client signature, and will not accept the pre-prepare if the client signature is valid. Assuming the cryptographic techniques cannot be subverted, the Byzantine servers cannot modify the message contents without invalidating contents that the client's private key was applied to when creating the client signature. See section 4.2 in http://pmg.csail.mit.edu/papers/osdi99.pdf, and https://github.com/zzlyn/ConsensusVisualization/pull/95#issuecomment-604792222, for more details.

Assuming this is a coordinated attack, Byzantine servers accept each other's messages. Thus if at least 2f+1 (3 for our case of 5 servers) are Byzantine, the unintended value "b" will be committed instead of the client's requested value "a".

This builds on https://github.com/zzlyn/ConsensusVisualization/pull/95 and also rebases on to the latest commit in the raftscope branch.

[zzlyn]

Thanks for doing this! I planned to fix my code after your comment but somehow forgot about it. Sorry.

If I understand correctly the patch adds basically another layer of authentic to servers so that coordinated byzantine attack can be executed correctly? While I totally agree with this it might be a better implementation to somehow merge authentic and hasValidClientSignature. (Don't do this, not worth the time, just random thought for the future that I think is worth noting lol)

Is it possible to add comment somewhere on the patched code to explain basically what you gathered in the main comment of this PR? Doesn't have to be specific but an overview + few pointers/links may help others understand after we hand this over to Edward.

[rfairley]

If I understand correctly the patch adds basically another layer of authentic to servers so that coordinated byzantine attack can be executed correctly? While I totally agree with this it might be a better implementation to somehow merge authentic and hasValidClientSignature.

Yes, this is just another way a requests can become identified as unauthenticated - simulating the use of the client signature in making sure the message came from a client. When the client sends the value a, it should really be sending a+signature(clientPrivateKey, a) - any client requests are wrapped with the client's signature. When a Byzantine primary overwrites the contents a with b, what will be left is b+signature(clientPrivateKey, a). Once a (nonfaulty) replica reads this message, it will see the signature does not agree, and that the b did not come from the client.

Agreed this could be merged with authentic - the same effect would be achieved by setting authentic = false for pre-prepare messages, if the sender of the pre-prepare message has inByzantineMode true. Will keep them separate for now as some refactoring will be needed, a future task could be to rethink how we are simulating the authentication between servers / client, and do some rework. Merging for now, just to get the quick implementation in for the demo.

[rfairley]

Also added the comment, thank you for the suggestions and review!