## 5 Security Analysis
### Efficiency Comparisons  
In this section, we evaluate our proposed scheme's efficiency. First, we assume that our scheme's parameter \(p\) is of 1024 bits for security consideration. We assume that H is the computation time of one hashing operation, \(Exp\) is the computation time of one modular exponential operation in a 1024 bit module, \(M\) is the computation time of one modular multiplication in a 1024 bit module, \(EC_{M}\) is the computation time of a number over an elliptic curve, and \(EC_{P}\) is the computation time of a bilinear pairing operation of two elements over an elliptic curve in [13; 14; 15]. We also let \(Sig\), \(ASE\), \(ADE\), \(SE\), and \(SD\) be the signature operation time, the asymmetric encryption time, the asymmetric decryption time, the symmetric encryption time, and the symmetric decryption time, respectively. We assume that our proposed scheme can be implemented on an elliptic curve over a 163-bit field and has the same security level of a 1024 bit public key crypto-system such as RSA or the Diffie-Hellman cryptosystem. We also assume that \(Exp=8.24 EC_{M}\) for the ARM CPU to the processor in 200 Mhz [15]. We also determine certain relations from the following: \(Exp\approx 240M=600H\approx 3 EC_{P}\), and \(EC_{A}\approx 5M\) in [16; 17; 18; 19; 20; 21; 22].  
Based on [23], a public key encryption/decryption operation time in an elliptic curve is approximately \(1 EC_{A}\) and \(1 EC_{M}+1 EC_{A}\), respectively. Therefore, our proposed scheme total computation time cost is about \(9H+3 Sig+14\oplus+2 ASE+1 ADE\approx 60.075M+14\oplus\). Due to the different properties of the above schemes, we omitted the efficiency comparisons and found some currently survey papers [11; 24] that have the same functional properties as our proposed scheme.  
In [11], the authors proposed a dynamic consent model of health data sharing using blockchain technology. They combine the consent representation models (DUO) and ADA-M [24] to let patients control their EHR sharing to match the request query with full access rights. Their method is designed for building an EHR platform but is not a practical mechanism for patients exchanging their EHRs with a formal security proof in a blockchain environment. In [12], the authors proposed an EHR with a patient-centric access right framework model by using blockchain technology. We think that this is a good idea for building health information exchange systematic modules with blockchain in the future, but they do not offer a practical solution for EHR migration currently, even in a blockchain environment. Our proposed scheme is established by the functional block such as the signature functions with other authentication functions. In future work, our proposed scheme could functionally add a smart contract function to generate a verifiable functional patient EHR block in blockchain network. Hence, our proposed scheme could be used in blockchain and non-blockchain environments.  
In the efficiency evaluation of our scheme, we used a desktop with Ubuntu 20.04 with Intel(R) Core(TM) i7-8700 CPU @ 3.20 GHz CPU and 15 GB memory. The simulation  
\begin{table}
\begin{tabular}{c c c c c c c} \hline \hline
**Attributes** & **[6]** & **[7]** & **[8]** & **[9]** & **[10]** & **Ours** \\ \hline A1 & Y & Y & Y & Y & Y & Y \\ \hline A2 & N & N & Y & Y & Y & Y \\ \hline A3 & Y & Y & Y & Y & Y & Y \\ \hline A4 & N & N & N & N & N & Y \\ \hline A5 & Y & Y & Y & Y & N & Y \\ \hline A6 & Y & N & N & N & N & Y \\ \hline A7 & N & N & N & N & N & Y \\ \hline A8 & N & N & N & N & N & Y \\ \hline \hline \end{tabular}  
* A1: Replay Attack Resistance; A2: Resist User Impersonation Attack; A3: Provide Mutual Authentication, A4: Provide Data Security; A5: Session Key Establishment, A6: Forward Secrecy Proof; A7: EHR Fair Exchange, A8: Offline Trusted Third Party.  
\end{table}
Table 1: Security comparison.