# A Blockchain based PKI Validation System based on Rare Events Management
## 4 A New Approach to X.509 Certificate Management Using Distributed Ledger Technology (DLT)
### The Closen Consensus Algorithm (CONS)  
Our proposal is based on a fundamental assumption: the rare event assumption. This assumption defines an attack as a rare event in a context or in a network where the majority of the transactions are correct ones [17]. Starting from this assumption, we defined a novel consensus algorithm with one requirement: considering that the aim is to certify to a user/browser that the X.509 public key certificate received (i.e., TLS protocol) from a server is valid (correctly issued, not stolen, not cracked), even a small delay (20 seconds) is not acceptable [18]. The delay spent in certificate verification is added to the loading delay of the first page of the site: when this delay only exceeds several tens of seconds, it makes the site practically unusable. Following that requirement, the novel consensus algorithm has the following main characteristic: the peers that participate in the consensus are a randomly chosen subset of all the peers connected to the blockchain. There are two reasons behind this assumption: first, we need fast certificate validation; second, the validation has to be secure. The random selection of peers protects them from attacks, because no one knows who will be in the next subset for certificate validation. The definition of our consensus algorithm draws inspiration from the consensus algorithm recalled in Algorand [19], but Algorand's performances do not meet our previously recalled requirements [19]. Thanks to our approach, it is possible to limit certificate verification delay to a few seconds. In the following we explain how this is achieved. Details of the CONS Algorithm  
Assume that a web server is S and the server certificate is C, and the i-th client/browser (CB\({}_{i}\)) is associated with the i-th peer of our blockchain. When the CB\({}_{i}\) has to decide to accept or not the certificate C sent by server S, it will accept the certificate only if the execution of the smart contract that checks the certificate validity returns OK or KO, meaning that all the other peers (the random subset chosen using our novel consensus algorithm) involved in the consensus gave OK or KO, and the tuple (ipServer, server name, certificate) is appended to the ledger with a positive/negative attribute. In our assumption, when the CB\({}_{i}\) connects to a fake server S that pretends to be S using a cracked certificate C containing the same attributes of C with, obviously, a different private key signature, the smart contract that has to verify the validity of the certificate will advise that the couple S, C\({}^{\prime}\):  
* Is already in the ledger with a negative attribute and then is an anomaly;
* Alternatively, another couple (S,C) is in the ledger with a positive attribute, and then (S,C\({}^{\prime}\)) has to be rejected;
* Alternatively, there is nothing stored in the ledger, and then a consensus phase has to start. The CONS algorithm then selects randomly, the peers that will participate in the next consensus phase. In Appendix A, we explain the algorithm used in our experiment to decide the random set of peers (RandIpAlgo) and we show that if a peer of the blockchain is periodically elected with a random algorithm responsible for selecting the subset of the other peers that will participate in the next consensus, any probabilistic attack has a very low probability of success, and this probability decreases exponentially with the subset dimension and the periodicity of the elections. The random nature of the selection ensures that an attacker has a very low probability to corrupt all the participants of the consensus. In Appendix A we discuss the minimum dimension for a random subset of the peers. The selected peers check the tuple (ipServer, S, C') and share the results. Therefore, an attacker who does not know which peers have participated to the consensus, must attack a large number of peers (specifically, it should attack the blockchains stored inside the peers) to be sure that his attack will not be detected.