# Security, Privacy, and Reliability in Digital Healthcare Systems Using Blockchain
## 5 Proposed Algorithms
### Authentication Mechanism
Theoretical analysis: We deployed our framework in a key-generation system and used sensors for every domain. Our main objective was to achieve authentication and authorization. In our proposed framework, each node and entity executed the various cryptographic operations that were involved in the system. We summarized the most time-consuming operations performed in Medrec. To evaluate the computational overhead, we counted the cryptographic operations using the \(G1/G2\) addition operations, exponentiation in \(GT\), and bi-linear pairing, which are denoted by \(PA1/PA2,SM1/SM2/SMT/SMr1,ExpT\), and \(BP\), respectively. The rest of the operations, such as hash operations, integer addition, and multiplication, took little time in our tests, so they were not considered here. The numbers of time-consuming cryptographic operations are provided in the simulations results. It should be noted that the operations were not simply added up when combining the authentication and key negotiation. We used two signing and verification algorithms for authentication and authorization. Moreover, we used a ring signature to provide encryption and decryption due to its lightweight features and because it provides anonymity for the signer. More and more, we used different sizes for the messages in order to check and evaluate the variations in the proposed algorithms. ### Equation for the Number of Rounds and Transmissions

In these equations, we describe the energy transmitted by each sensor \(Et\) in the communication process. However, they also describe the residual energy of the transmitter. \(ERx\) describes the receiver node's energy. \(K\) is the constant. \(d\) denotes the diameter of the network or the distance between the nodes. \[ETx(k,d)=ETx-Elec(k)+ETx-amp(k,d), \tag{1}\]

\[ERx(k,d)=ERx-Elec(k), \tag{2}\]

\[ERx(k)=Elec*k. \tag{3}\]

\[P^{L}(f)\varpropto f^{k}, \tag{4}\]

\[P^{L}(f,d)=PLo+10 lnlog10d/do+X\sigma. \tag{5}\]

\[P^{L}o=10 log10. \tag{6}\]

\[(4\pi df)c^{2}, \tag{7}\]

## 8 Results and Discussion

We implemented our proposed smart contract and access control policies using Node.js and the Postman web API. Similarly, we tested our simulations for concurrent requests of \(m\) with \(N=50\), \(200\), \(400\), \(600\), and \(800\) nodes. We kept the total number of requests to \(800\) and the total number of policies to \(1100\). For our initial simulation, we tested the results for \(250\) nodes. Figure 8 shows the simulation results when the average authentication time took \(240\) ms. We set the time for authorization to \(30\) ms, and the \"access control policy\" took \(120\) ms. We also observed that our proposed policy for the delegation and revocation took \(87\) ms. With our proposed method and in the experiments, we achieved significant improvements by running the simulations from \(200\) to \(800\) rounds, respectively. The results are shown in Figures 8 and 9, respectively. We also tested the proposed policies that were mentioned earlier for the number of rounds, which ranged from \(N=50\) to \(800\) clients. The results show that the throughput of the proposed framework increased with an increase

in the number of concurrent requests. Our proposed method provides an efficient access control policy as compared to the other existing benchmark methods. Figures 8 and 9 show that the execution time of user authentication and policy creation was not affected much by the increase in the number of policies. However, the user authorization time and policy revocation time increased due to the increase in the time required to search for a specific policy in a long chain of policies. We also performed experiments for the user authentication, authorization, and delegation policies. We further divided our policies into creation and revocation operations. We evaluated our experiments for the same requests and ran the simulations from \(N=0\) to 4000 concurrent requests. \(N\) shows the total number of concurrent requests. The total number of delegation policies was kept constant, i.e., \(p=1000\).