# 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 Smart Contract Structure and Its Relationships with the Consensus Algorithm
This research was funded by \"Credito Sportivo\" inside the project \"Biomedicina,\" grant number CUP E86C18002330005. We would like to thank [PERSON] of the Inuit Foundation Security Lab for his technical support and for the availability of the hardware devices used during the experiments. The authors declare no conflict of interest. ## Appendix A

We implemented a blockchain prototype in GOLANG language. The communication channels were managed using the GRPC protocol (the same as hyperledger fabric). Each peer knew 4 to 8 adjacent peers. We ran a simulation comprising 5 CAs, 100 web servers, and 100,000 users, where each one was connected to the web servers with a maximum frequency of 10 pages/minute. Experimental trials were saved in a database of two relational tables:

Experiment (Experiment ID, M);

Experiment Trials (idExp, idTrial, M, Absolute Sparsity Index, Time, Time Cost Value, Relative Sparsity Index). Let us consider single fields to explain the experiment details. The first table, Experiment, contains the list of experiments with a parameter M explained in the next lines. In the second table, ExperimentTrials, each record is a single section (certificate checked by a client and associated target peer of the blockchain). The idExp and idTrial columns uniquely identify this section. M is the number of actual peers that check the target certificate in the current section. The optimal value of M is one of the goals of the experimentation. **AbsoluteSparsityIndex**

Given a target peer (TP) and a target certificate (TC) to check, we had to select a subset of the 100,000 IP addresses. To do this task, we used the Raft consensus algorithm [21]. In the background, all peers of the blockchain agreed on a leader peer, known here as the RLp (Raft leader peer). The leader peer is re-negotiated and provides updates via the Raft consensus algorithm. The actual RLp receives a call from the TP. The RLp updates, periodically, in the background, a table with web servers and subsets of associated IP addresses (RandIPSet). The subset of IP addresses is of size M. The Raft consensus algorithm avoids the risk of a target peer being attacked during the procedure of deciding the random subset of IP addresses. A randomly selected peer decides, each time, this random subset. We considered the structure of an IP address (classA.classB.classC.Y) and assumed that IPs of the same class have shorter distances between them than IPs of different classes. The experimental network had two groups of IP addresses:

192.168.x.y (256 \(\times\) 250 = 64,000 available IP addresses)

192.169.x.y (256 \(\times\) 250 = 64,000 available IP addresses)

We left out 6 IP addresses for network management. We had 128,000 available IP addresses. A subset of them was statically assigned to our 100,000 clients. Half of them were assigned to the numbers 1-50,000 in the address set 192.168.x.y, and the other half were assigned to the numbers 1-50,000 in the address set 192.169.x.y. We defined the following distance function between two IP addresses:

IP1 = x1.x2.x3.x4

IP2 = y1.y2.y3.y4

D(IP1,IP2) = (IP1 xor IP2). **AbsoluteSparsityIndex** = Sum of distances of all couples in the sample/M

**RandIPAlgo**

Considering that it works in the background (by the RLp) without adjunctive costs, the RandIPAlgo that outputs the RandIPSet, is as follows:

1. Generate a subset of M/2 random numbers in the set [1,50,000];
2. Get the subset of associated IP in the class 192.168.x.y;
3. Generate a subset of M/2 random numbers in the set [1,50,000];
4. Get a subset of associated IP in the class 192.169.x.y. Given the set of IP addresses, we calculated the absolute sparsity index (AbsoluteSparsityIndex). **Time and TimeCostValue fields**

Given that, we defined the time cost for the target peer as the sum of the costs required to execute the following steps:

* Step 1: Direct connection to the RLp (the target peer TP knows its IP address).