Enhancing Transaction Security for Handling Accountability in Electronic Health Records

Electronic healthcare systems have received extensive attention during the last decade due to the advancement of digital technology. Using these systems in the healthcare industry can improve the quality of healthcare services tremendously. However, a major issue that needs to be concerned, when utilizing this kind of system, is accountability. Employments of electronic health records, the core of the systems, without accountability can be a big risk to both patients and service personals and, consequently, to the entire society. Accountability in electronic health records is essential to creating trust among parties. Many researchers have been introduced to the accountability protocol. However, most of them still lack some essential security property that is mutual authentication. This leads to both information traceability and nonrepudiation which are necessary for resolving any conflict that may arise. In this paper, we propose accountability protocol for electronic health records; the protocol employs both asymmetric and symmetric encryptions to ensure that the electronic health records are having confidentiality, integrity, authentication, and authorization. The accountability analysis and performance analysis show that the proposed protocol is more capable and effective than others. The novel aspect of this idea lies in the inclusion of certain forms of security that are necessary to protect the patient’s electronic health records. To the best of our knowledge, the proposed protocol consumes less cost, energy, and time compared with the existing protocols. A proof of concept of our protocol is also presented in this paper by using BAN logic, an automated security protocol proof tool named Scyther, and AVISPA


Introduction
During the past decade, electronic health records (EHRs) have been an attractive topic in the healthcare industry. It has been recognized that EHRs can improve the quality of healthcare services tremendously. However, the realization of the systems in the real world is not straightforward because it still faces a major obstacle to transaction accountability concerning patient data. Obviously, with no accountability, patient privacy could be violated and confidential data could be leaked. As a result, their personal life could be ruined. us, in order to implement EHRs successfully, the accountability issue needs to be treated properly. e formal definitions of accountability in information systems have been presented in various ways. For example, Feigenbaum et al. and Weitzner et al. [1,2] defined accountability as referring to an entity that is accountable concerning a certain policy. If this entity violates accountability, a punishment will be raised. According to Gajanayake et al. [3][4][5], information accountability concerns the use of information where the user is held liable to explain, justify, or answer for its use when so requested by the party to whom the information belongs. Accountability in the computer security systems is the requirement that actions of an entity may be traced uniquely to that entity and directly supports nonrepudiation, deterrence, fault isolation, intrusion detection and prevention, and after-action recovery and legal action that involve confidentiality, integrity, authentication, and authorization of the transaction by all relevant parties [6]. However, the accountability in healthcare is an audit trail, a record of exactly what was done, who did it, and how they did it; in other words, verify, analyze, and investigate users' actions [7,8].
Basically, the systems must be able to authenticate every party who is authorized to carry out a transaction and also to keep all transactional data confidential and integrity. When a dispute arises, the systems can disclose necessary information to clarify all activities within the transaction in order to resolve it. is will make all involved parties unable to deny their actions in the transaction. Until recently, there have been a lot of researchers investigating accountability in healthcare records. However, most of them [9][10][11][12][13][14][15][16] proposed protocols that cannot handle full accountability because of the lack of mutual authentication, which is a preliminary mechanism for nonrepudiation. Hence, when a dispute arises, transactional information cannot be traced, and an engaging party may be able to deny its action. at is to say, the dispute cannot be resolved, and therefore, there is no accountability in the system. In this paper, we proposed an accountability model and a novel protocol that can handle the accountability, as defined by the model, in healthcare records and their transactions. e protocol possesses all necessary properties of security and can provide confidential evidence to a trustworthy party in case of a dispute. e details of existing protocols will be discussed in Section 2, and the comparison of the existing protocols and the proposed protocol is given in Section 4.
is paper is organized as follows. Section 2 discusses some related works and existing protocols. Section 3 presents the techniques of our proposed protocol. Section 4 discusses security analysis using BAN logic, Scyther tool, and AVISPA. Section 5 discusses the accountability analysis of the protocol. Finally, Section 6 concludes our work.

Related Works
Accountability in computer security is a crucial security property that leads to nonrepudiation of engaging parties relevant to the transactions. Hence, many researchers have proposed a security protocol for electronic health records to eliminate any barriers or disputes that may arise after the transaction is complete. Although accountability has been used in many different ways in terms of information accountability for electronic health records, all of these approaches have the same goal. Gajanayake et al. [15,17,18] proposed the role-based access control to control the use of patient health records by designing fixed roles for each position in the hospital. Anyway, the role can be replaced by the administrator of the system. is can lead to a serious security problem. Mashima and Ahamad [9,10] proposed a patient's centric protocol for monitoring the uses of patient health records. e protocol was flexible and helpful to the patient for monitoring who was using his/her health records. However, the protocol still lacks integrity and nonrepudiation properties. Hou and Yeh [11] proposed authentication schemes to ensure authentication between the user, the authentication server, and a trusted third-party authority before using the patient's data. e proposed schemes were lightweight but lacked integrity, nonmutualize authentication, and did not support accountability. Al Alkeem et al. and Al Ameen et al. [12,19] proposed the systems using the cryptographic protocol to send and receive the patient's data via the cloud system. e system was well proposed but with weak authentication. e strong asymmetric encryption protocol was proposed by Lo et al. [13] with fourteen messages sent via the network. is makes the authors' protocol very secure and encountered all security properties; however, it is rising the computational cost, cryptographic operations cost, energy consumption and time consumption. However, Ibrahim et al. [14] proposed a framework to exchange information between healthcare providers using a hybrid cryptographic operation to offer the security of the system. e proposed framework is complying with most security properties but still lacks accountability, is not resistant for a replay attack and man-in-the-middle attack, and does not support mutual authentication. Hu et al. [20] proposed the hybrid public key infrastructure solution for HIPPA privacy and security regulations. e proposed method was very strong and secure which was complied with confidentiality, integrity, patient control, and consent exception when in emergencies by using mutual authentication. However, the proposed methods were affecting the performance of the system. Blobel et al. [21] proposed the cross-security platform that consists of seven basic components using a public key infrastructure for authentication and a prototypical privilege management infrastructure for authorization and access control to secure web-based electronic health applications. e author applied an idea from their research in [22,23]. e proposed system was secure as designed; however, it requires greater computation, communication cost, energy consumption, and time consumption. As discussed above, many proposed protocols are secure and with strong encryption. Nevertheless, some protocols are weak in accountability and security properties such as confidentiality, integrity, and authentication. Meanwhile, some protocols are secure and achieve all security properties but have affected the performance of the systems. Moreover, when a dispute arises, these protocols cannot resolve.

Proposed Model and Protocol for Electronic Health Records
In the context of information security, many researchers define accountability as involving confidentiality, authorization, authentication, integrity, and nonrepudiation. However, we argue that traceability is also one of the most important features that needs to be part of the systems' accountability. It allows the trustworthy proof of the identity of any participating party and his/her activities in transaction processing. is traceable information will help to solve any dispute that may arise after the end of the transaction. is notion is essential for the success of any electronic healthcare records. erefore, in our work, we will concentrate on a model of accountability and its supporting protocol to accommodate traceability in electronic health records. In this section, the proposed model and protocol for electronic health records are described. Figure 1 illustrates conceptually how three engaging parties interact with each other in the healthcare transaction. Whenever C (a hospital, insurance company, or technical lab) needs to access P's health records, a request is sent to the HCP for authorization (Step 1). When the HCP receives the request from C, the identity of C is validated. If correct, the HCP will forward a request to P (Step 2); if not, the HCP sends a notification back to C, and the transaction will end. When the patient receives a request for authorization from the HCP, he/ she decides whether to accept or reject this request. P will then notify the HCP of this decision (Step 3). In case of acceptance, the encrypted patient health records are sent to both C and P (Steps 4 and 5, respectively). If rejected, HCP will send a denial of the request to C, and the transaction will end. e details of the protocol are explained in the next section.

Accountability Model.
In this section, we propose a new accountability model for electronic health records. As illustrated previously in Figure 1, there are three parties involved in the healthcare transactions: healthcare professional (HCP), the patient (P), and an information consumer (C). e model defines the accountability of each party and is a baseline to design the proposed protocol of healthcare transactions. e details of the proposed model are described as follows.
Healthcare professional's accountability: HCP CanProve (C authorized ReqPHR(C, HCP)) to V ∧ HCP CanProve (P authorized PHR(P, HCP)) to V ∧ HCP CanProve (HCP authorized PHR(HCP, C)) to V ⟶ HCP is accountable for PHR to V e above statements show that the HCP is accountable for a PHR.
e details of HCP's accountability can be explained as follows. First, HCP needs to prove that the request to access the P's health records is sent from C. Second, HCP must also prove that the HCP is allowed by P to provide the health records to C. Finally, HCP needs to prove that the health records have been sent to C on behalf of P's authorization.
Patient's accountability: P CanProve (HCP authorized ReqPHR(HCP, P)) to V ∧ P CanProve (P authorized PHR(P, HCP) to V∧ P CanProve (HCP authorized PHR(HCP, C)) to V ⟶ P is accountable for PHR to V e above messages show that P is accountable for a PHR. e details of the patient's accountability are explained as follows. First, P must prove that the request to use his/her personal health record has come from the HCP. Second, P needs to prove that he/she gives the authorization to use his/ her personal health records to the HCP. Finally, P also needs to prove that his/her personal health records are sent to C by the HCP as requested.
Information consumer's accountability: C CanProve (HCP authorized PHR(HCP, C)) to V ∧ C CanProve (P authorized PHR(P, C)) to V ∧ ⟶ C is accountable for PHR to V From the above statements, C is accountable for a PHR if C can prove that HCP, on behalf of P, allows C to use P's health records and, also, C is allowed to use P's health records via HCP.

Accountability Protocol.
Based on the accountability model introduced in Section 3.1, electronic healthcare records need a protocol that allows access to P's health records with traceability and confidentiality. In designing the protocol that is correct and complete, the accountability aspects consisting of, as mentioned in [24], accountability confidentiality, integrity, authorization, authentication, and nonrepudiation need to be considered. e existing protocol in [16] is secure and complete and can protect P's health records but to improve our proposed protocol to consuming fewer resources than the protocol proposed in [16]. So, we decide to propose such an accountability protocol that is based on both symmetric and asymmetric operations. e mechanism of the protocol will be discussed in detail in the following sections, and the notations used to describe it are summarized in Table 1.

e Session Keys' Generation and Update.
Session keys are one of the core components employed in our protocol. Basically, the session keys need to be generated and shared between two communicating entities. erefore, before starting the protocol, it is necessary to create and update the session keys between involved parties. is section will describe how this process works.

In
Step 1, C sends information, including the identities of C (C ID ) and HCP (HCP ID ), the nonce n 1 doubly encrypted with the C's private key and the HCP's public key, respectively, and the hash value of C ID , HCP ID , and n 1 , to HCP. e double encryption is to ensure the mutual authentication between C and HCP, and the hash value is to ensure message integrity.

C HCP P
Step 1 Request_PHR (C,HCP) Step 4 PHR_Sends (HCP,C) Step 5 PHR_Sends (HCP,P) Step 2 Request_PHR (HCP,P) Step 3 Response (P,HCP) In Step 2, after receiving the message in Step 1, HCP will decrypt {{n 1 } Pri-C } Pub-HCP to obtain n 1 so that it can validate the hash value h(C ID , HCP ID , n 1 ). Moreover, after integrity of the message has been confirmed, HCP will generate a nonce n 2 and, then, send information, composed of n 2 , EXPT C-HCP (expiry date and time of the session key), and the hash value of h(C ID , HCP ID , n 1 , n 2 ), to C. In contrast, if integrity is disconfirmed, HCP will terminate the connection with C.
In Step 3, after receiving the message from HCP, C will check the correctness of the hash value h(C ID , HCP ID , n 1 , n 2 ). If the hash value is invalid, C will decline communication. Otherwise, C sends the encrypted message {EXPT C-HCP }SK C-HCP to HCP. Note that SK C-HCP denotes the hash value of C ID , HCP ID , n 1 , n 2 , and EXPT C-HCP that is the shared session key of C and HCP.
(ii) C and P: Step 1: C ⟶ P: C ID , P ID , {{n 1 } Pri-C } Pub-P , h(C ID , P ID , n 1 )s Step 2: P ⟶ C: n 2 , EXPT C-P , h(C ID , P ID , n 1 , n 2 ) Step 3: C ⟶ P: {EXPT C-P }SK C-P , where, SK C-P � h(C ID , P ID , n 1 , n 2 , EXPT C-P ) In Step 1, C sends information, including the identities of C (C ID ) and P (P ID ), the nonce n 1 doubly encrypted with the C's private key and the P's public key, respectively, and the hash value of C ID , P ID , and n 1 , to P. e double encryption is to ensure the mutual authentication between C and P, and the last hash value is to ensure message integrity.
In Step 2, after receiving the message in Step 1, P will decrypt {{n 1 } Pri-C } Pub-P to obtain n 1 so that it can validate the hash value h(C ID , P ID , n 1 ). Moreover, after integrity of the message has been confirmed, P will generate a nonce n 2 and, then, send information, composed of n 2 , EXPT C-P (expiry date and time of the session key), and the hash value of h(C ID , P ID , n 1 , n 2 ), to C. In contrast, if integrity is disconfirmed, P will terminate the connection with C.

In
Step 3, after receiving the message from P, C will check the correctness of the hash value h(C ID , P ID , n 1 , n 2 ). If the hash value is invalid, C will decline communication. Otherwise, C will send the encrypted message {EXPT C-P }SK C-P to P. Note that SK C-P denotes the hash value of C ID , P ID , n 1 , n 2 , and EXPT C-P that is the shared session key of C and P.

In
Step 1, HCP sends information, including the identities of HCP (HCP ID ) and P (P ID ), the nonce n 1 doubly encrypted with the HCP's private key and the P's public key, respectively, and the hash value of HCP ID , P ID , and n 1 , to P. e double encryption is to ensure the mutual authentication between HCP and P, and the last hash value is to ensure message integrity.
In Step 2, after receiving the message in Step 1, P will decrypt {{n 1 } Pri-HCP } Pub-P to obtain n 1 so that it can validate the hash value h(HCP ID , P ID , n 1 ). Moreover, after integrity of the message has been confirmed, P will generate a nonce n 2 and, then, send information, composed of n 2 , EXPT HCP-P (expiry date and time of the session key), and the hash value of h(HCP ID , P ID , n 1 , n 2 ), to HCP. In contrast, if integrity is disconfirmed, P will terminate the connection with HCP.
In Step 3, after receiving the message from P, HCP will check the correctness of the hash value h(HCP ID , P ID , n 1 , n 2 ). If the hash value is invalid, HCP will decline communication.
Otherwise, HCP will send the encrypted message {EXPT HCP-P } SK HCP-P to P. Note that SK HCP-P denotes the hash value of HCP ID , P ID , n 1 , n 2 , and EXPT HCP-P that is the shared session key of HCP and P. e Proposed Protocol. e proposed protocol designed based on the proposed model is explained in Section 3.1. e proposed protocol will be used in the case that whenever C (a hospital, patient, insurance company, or technical lab) needs to use P's health records, a request is sent to the HCP for authorization. When the HCP receives the request from C, the identity of C is checked. If correct, the HCP will forward a request to P; if not, the HCP sends a notification back to C, and the transaction will end. When P receives a request for authorization from an HCP, he/she decides whether to accept or reject this request. P will then notify the HCP of this decision. In the event of acceptance, HCP will send the message of confirmation and request information to C and also to P for confirmation what information is sent to C. If rejected, the HCP will send a denial of the request to C, and the transaction will end. e proposed protocol handled all security properties with cryptographic techniques, especially for confidentiality, integrity, and authentication. For the confidentiality of the message, we use the public key of the receiver to ensure that only who has the private key can read the message. e integrity of the message can be satisfied by using a hash function. However, for authentication of the message, we use an asymmetric key with a symmetric key to ensure that the sender and the receiver can be identified. e details of the proposed protocol can be explained as follows.
is message consists of the following data: (i) {h(ReqPHR, C ID , P ID , HCP ID , T 1 )} Pri-C : the data package (ReqPHR, C ID , P ID , HCP ID , T 1 ) is hashed and, then, encrypted by C's private key. is is to ensure that C is the creator of the message and to validate the message integrity. (ii) h({h(ReqPHR, C ID , P ID , HCP ID , T 1 )} Pri-C , SK C-HCP ): these data are considered as a message authentication code between C and HCP. ey can also ensure the integrity of the transmitted data.
these data are considered as a message authentication code between C and P. Due to the inclusion of the session key SK C-P , they can ensure that the originator and the receiver of the message are C and P, respectively.
Step 2: HCP ⟶ P: ReqPHR, C ID , P ID , HCP ID , T 1 , {h(ReqPHR, C ID , P ID , HCP ID , T 1 )} Pri-C , h(h({h(ReqPHR, C ID , P ID , HCP ID , T 1 )} Pri-C , SK C-P ), SK HCP-P ) From Step 1, after receiving the message from C, HCP will compute the hash value from the plaintext ReqPHR, C ID , P ID , HCP ID , and T 1 and, then, compare it with the received hash value h(ReqPHR, C ID , P ID , HCP ID , T 1 ). If both hash values are not equivalent, HCP will terminate the session.
Otherwise, HCP will proceed to Step 2, where it will forward the plaintext message as well as the two hash values, {h(ReqPHR, C ID , P ID , HCP ID , T 1 )} Pri-C , and h(h({h(ReqPHR, C ID , P ID , HCP ID , T 1 )} Pri-C , SK C-P ), SK HCP-P ), to P. e first hash value is used to authenticate C as the message generator and the second to mutually authenticate the sender (HCP) and the receiver (P).
Step 3: P ⟶ HCP: Allow, T 2 , {h(Allow, C ID , P ID , Step 2, after receiving the message from HCP, P will compute the hash value from ReqPHR, C ID , P ID , HCP ID , T 1 , and session key of SK C-P and SK P-HCP and, then, compare it with h({h(ReqPHR, C ID , P ID , HCP ID , T 1 )} Pri-C , SK C-P , SK P-HCP ). If they are a mismatch, P will send NotAllow a message and reject this session. e step to reject the session is described in Step 3 of the reject session. Otherwise, P will decide whether to give consent to use his/her personal health records or not and send the message to HCP as in Step 3. e message includes the following: SK P-HCP ): P will send this message to HCP to inform HCP that P allows C to use the personal health record as requested. Also, due to the use of the private key of P in encrypting the hash value, the message ensures that P is its originator. (ii) h({h(Allow, C ID , P ID , HCP ID , T 1 , T 2 )} Pri-P , SK C-P ): P also sends the hash value of {h(Allow, C ID , P ID , HCP ID , T 1 , T 2 )} Pri-P encrypted with SK C-P . The purpose of this message is to ensure the integrity of the message and to ensure that P is the sender, and HCP is the receiver.
Step 4: HCP ⟶ C: Allow, T 2 , {Allow, C ID , P ID , HCP ID , T 1 , T 2 , PHR}SK C-HCP , {h(Allow, C ID , P ID , HCP ID , T 1 , T 2 , PHR)} Pri-HCP After receiving consent from P (via Allow message) in Step 3, HCP will proceed to Step 4, where PHR is confidentially sent to C. More specifically, the following are included in the sent message: (i) {Allow, C ID , P ID , HCP ID , T 1 , T 2 , PHR}SK C-HCP : this message is the encryption of the data, consisting of Allow, C ID , P ID , HCP ID , T 1 , T 2 , and PHR, using the session key SK C-HCP to ensure that C is the only person who can decrypt the message and read the data.
(ii) {h(Allow, C ID , P ID , HCP ID , T 1 , T 2 , PHR)} Pri-HCP : this message is the encryption of the hash value using the HCP's private key in order to authenticate HCP as the creator of the message.
In the event that the message in Step 2 is incorrect or P is an inconvenience to allow C to use his/her PHR, he/ she will send the notification message to HCP that P is not allowed to use his/her PHR and terminate this Security and Communication Networks 5 communication. e message on Step 3 and Step 4 is described as follows: Step 3: P ⟶ HCP: NotAllow, T 2 , {NotAllow, C ID , P ID , HCP ID , T 1 , T2} Pri-P , h({NotAllow, C ID , P ID , HCP ID , T 1 , T2} Pri-P , SK P-HCP ), h({NotAllow, C ID , P ID , HCP ID , T 1 , T2} Pri-P , SK C-P ) From Step 2, after receiving the message from HCP, P will compute a hash value from ReqPHR, C ID , P ID , HCP ID , T 1 , and session key of SK C-P , SK P-HCP and compare with h({h(ReqPHR, C ID , P ID , HCP ID , T 1 )} Pri-C , SK C-P , SK P-HCP ) that is received from HCP. If P found that the comparison is incorrect, P will send the following message to HCP and terminate the session.
(i) h({NotAllow, C ID , P ID , HCP ID , T 1 , T2} Pri-P , SK P-HCP ): P will send this message to HCP to inform HCP that P does not allow C to use his/her personal health record as requested. Besides, due to the use of the private key of P in encrypting the hash value, the message ensures that P is its originator, while the session key SK P-HCP is to ensure that P is the sender, and HCP is the receiver of the message. (ii) h({NotAllow, C ID , P ID , HCP ID , T 1 , T2} Pri-P , SK C-P ): P also sends the hash value of {h(NotAllow, C ID , P ID , HCP ID , T 1 , T 2 )} Pri-P encrypted with session key SK C-P to HCP. e purpose of this message is to ensure the integrity of the message and to ensure that P is the sender, and C is the receiver and notify HCP that P does not allow C to use his/her personal health records. When HCP received the message from P, HCP will forward the message to C. is can be sure that HCP cannot see the message. is is because the session key SK C-P is shared only between P and C.
Step 4: HCP ⟶ C: NotAllow, T 2 , {NotAllow, C ID , P ID , HCP ID , T 1 , T2} Pri-P , h({NotAllow, C ID , P ID , HCP ID , T 1 , T2} Pri-P , SK C-P ) After receiving dissent from P (via NotAllow message) in Step 3, HCP will send the following message to C: (i) {NotAllow, C ID , P ID , HCP ID , T 1 , T 2 } Pri-P : this message is the encryption of the data, consisting of NotAllow, C ID , P ID , HCP ID , T 1 , and T 2 , using P's private key to ensure that P is the originator of the message. (ii) h({NotAllow, C ID , P ID , HCP ID , T 1 , T 2 } Pri-P , SK C-P ): this message will send NotAllow, C ID , P ID , HCP ID , T 1 , T 2 encrypt with P's private key and session key SK C-P to ensure that P is the creator of the message, and C is the only person who can open the message.
Step 5: HCP ⟶ P: Allow, T 2 , {Allow, C ID , P ID , HCP ID , T 1 , T 2 , PHR}SK P-HCP , {h(Allow, C ID , P ID , HCP ID , T 1 , T 2 , PHR)} Pri-HCP After receiving consent from P (via Allow message) in Step 3, HCP will proceed to Step 5, where PHR is confidentially sent to P to confirm that P's health records are sent to C. More specifically, the following are included in the sent message: (i) {Allow, C ID , P ID , HCP ID , T 1 , T 2 , PHR}SK P-HCP : this message is the encryption of the data, consisting of Allow, C ID , P ID , HCP ID , T 1 , T 2 , and PHR, using session key SK P-HCP to ensure that P is the only person who can decrypt the message and read the data. (ii) {h(Allow, C ID , P ID , HCP ID , T 1 , T 2 , PHR)} Pri-HCP : this message is the encryption of the hash value using the HCP's private key to authenticate HCP as the creator of the message.
If any dispute arises, the originating party may need to resolve it. In this case, the party can send the transaction to the third party to investigate the problem. e third party may be a court, lawyer, or trusted company. For example, in case that C needs to prove that HCP has already been granted to provide P health records to C, C needs to send the message, in Step 4, to the third party, while HCP needs to send the message, in Step 2 and Step 3, to the third party to prove that P has permitted his/her P health records to HCP. After the third party receives all implicated evidence, they will consider the evidence and notify the result to the involved parties. On the contrary, if P needs to prove that P did not give any consent to HCP and C, P needs to send a transaction message to the third party to prove that HCP or C violates P's health records.

Security Analysis and Performance Analysis
To analyze the security of the proposed protocol, we address the security concerns of patients: the confidentiality and the integrity of PHRs, authentication, authorization, and nonrepudiation of the transactions between the parties involved. An analysis of the proposed protocol is given in the following.

Security Analysis.
e proposed protocol uses asymmetric encryption to ensure that the involved party cannot deny their action. e advantages of using asymmetric encryption are that there is no need to exchange keys, message authentication and nonrepudiation (in which the user cannot deny sending a message) are ensured, and tampering can be detected if the message is altered by an intruder or hacker. is assumes that the private key of each party is not compromised, and the message was successfully sent to the involved party. e details of security analysis are given as follows: (c) Mutual authentication: this is a two-way authentication, i.e., the information in a message can authenticate both originator and receiver. e session key shared between two parties is a mechanism for the mutual authentication. In our protocol, we employ three session keys SK C-HCP , SK C-P , and SK P-HCP . Consider the following message: Step 1: C ⟶ HCP: ReqPHR, C ID , P ID , HCP ID , T 1 ,

{h(ReqPHR, C ID , P ID , HCP ID , T 1 )} Pri-C , h({h(ReqPHR, C ID , P ID , HCP ID , T 1 )} Pri-C , SK C-HCP ), h({h(ReqPHR, C ID , P ID , HCP ID , T 1 )} Pri-C , SK C-P )
In the proposed protocol, it can be seen that the originator and the receiver of any message can be identified and authenticated. C and HCP share the session key SK C-HCP , C, and P shares the secret key SK C-P . It can be seen that C cannot deny that C is the originator of the message. is is because C possesses the shared key SK C-HCP and SK C-P that indicates C is the only one who can create this message. So, this can infer that C is the originator of this message because both SK C-HCP and SK C-P are known only by C. It can be seen that our proposed protocol satisfies all necessary properties. Moreover, the proposed protocol can prevent the replay attack by using a fresh timestamp [25] that can be used only once and manin-the-middle attack. By using asymmetric cryptography to authenticate transmission and the secret key shared between the sender and the receiver, an attacker cannot impersonate a relevant party.
is is proved using the Scyther verification tool [26], and the results of the proposed protocol are shown in Figures 2 and 3. Table 2 shows the security comparison of the proposed protocol and existing protocols.

Security Proof.
In this section, we use the traditional and well-known authentication approach known as BAN logic [27], the Scyther verification tool [26], and AVISPA [28] to prove the soundness and security of the proposed protocol.

Authentication Proof Based on BAN Logic. BAN logic
is an authentication proof of a protocol for both symmetric and asymmetric encryption algorithms. BAN logic is proposed to verify the security protocol in [27,[29][30][31][32][33][34][35]. e details of the formalization of this logic can be found in [27]. In this section, we will describe only an encryption algorithm as used in the proposed protocol. e notations used in BAN logic are given in Table 3.
BAN logic rules: R1: message meaning rule: R2: nonce verification rule: P believes fresh(X), P believes Q said X P believes Q believes X . (2) R3: juristic rule: P believes Q controls X, P believes Q believes X P believes X .

Security and Communication Networks
P believes fresh(X) P believes fresh(X, Y) .
R5: decryption rule: R6: belief rule:  Encryption keys P believes X P believes X or is entitled to believe X P sees X P can read and repeat the message containing X P said X P has said X (P believes X) P controls X P has jurisdiction over X Fresh (X) Formula X is fresh ⟶ K P Public key Private key X { } K Formula X is encrypted by the public key Formula X is encrypted by the private key (X) K e hash value of X using K as a key

Security and Communication Networks
P believes(X), P believes Y P believes(X, Y) .

HCP from
Step 5 Due to the limited space, the details of this proof will explain only G1 and G2 to prove that HCP and C are interacting with each other. at is, C sends a request to HCP, and HCP sends back the required P health records to C (with consent from P). However, we can provide some guidelines to prove G1 and G2 of our protocol as follows: G1: HCP believes {h(C ID , P ID , T1)} ⟶

HCP
(1) C sees PHR, T 1 Pri-HCP (2) 1, R1: C believes PHR, T 1 Pri-HCP (3) 2, P: C believes PHR, T 1 3, C believes {PHR, T 1 } Pri-HCP As shown above, C believes that HCP ID , C ID , P ID ,{{PHR, HCP is sent from HCP. us, C believes that P health records are sent from HCP. It can be inferred that goal G2 is successfully proven. us, it can be concluded that all parties have satisfied secure mutual authentication.

Authentication Proof Based on Scyther Verification.
ere are many tools for formal verification, as shown in the survey in [36], but the most popular for verification are ProVerif, Scyther, and the AVISPA project. Each of these tools has certain advantages and disadvantages, and the reader can find more information in [36]. e advantage of the Scyther verification tool [26] is its graphical user interface for verification, falsification, and analysis of the cryptographic protocol. We, therefore, used the Scyther verification tool to analyze our proposed protocol. As shown in Figures 2 and 3, the proposed protocol is verified as allowing no attacks. More information about authentication claims such as Alive, Weakagree, Niagree, and Nisynch can be found in [26,37,38].

Authentication Proof Based on AVISPA.
e AVISPA tool is a well-known tool in which many researchers [39][40][41][42] used to verify protocol falsification and specific goal defined in high-level protocol specification language (HLPSL) to prove the security protocol, which also allows us to indicate Security and Communication Networks the protocol's security properties to be verified. e on-thefly model checker (OMFC) back-end can be employed for efficient checking falsification of protocols and proving the correctness of the protocol. However, constraint-logic-based attack searcher (ATSE) back-end is used to find attacks to the protocol, and attack trace generation is used to find attack of our proposed protocol. e result of the proposed protocol simulation of OFMC is shown in Figure 4, and ATSE is shown in Figure 5. Figure 6 shows attack trace generation and that our proposed protocol is safe, and Figure 7 shows the HLPSL code specific goal for authentication and goal for secrecy are specified in the goal section. e output shows that the proposed protocol is safe as the specified goals. AVISPA is described more in detail in [28,43].

Performance Analysis.
In this section, our proposed protocol is evaluated since this protocol employs asymmetric and symmetric encryption and may require a greater computation, communication cost, energy consumption, and time consumption. e communication and computational cost are evaluated to show that our proposed protocol can run in any environment, either on a personal computer or a mobile phone. Meanwhile, energy and time consumption are also appraised.

Cryptographic Operations' Cost.
e cryptographic operations' cost is compared between our proposed protocol and existing protocols [9, 11-16, 20, 21]. e definitions of the cryptographic operations used are presented in Table 4. e security functions used for authentication in these protocols are calculated as follows:

Energy Consumption.
e energy consumption comparison is a comparison of the proposed protocol with the other in [9, 11-16, 20, 21]. e total bits of the transmitted message are also calculated using the size specified in Table 4. e number of messages exchanged in each protocol is 8, 6, 6, 14, 5, 10, 23, 7, and 6, respectively. Table 5 and Figure 10 show the proposed protocol and the other protocols in terms of energy consumption comparison. e comparison shows that the proposed protocol consumes less energy than [9, 12-16, 20, 21]. However, the proposed protocol consumes more energy than [11]. However, the protocol given in [11] still lacks some essential security properties. Table 6 and Figure 11 show time consumption comparisons between the proposed protocol and other protocols defined in [9, 11-16, 20, 21]. e comparisons are visible that the proposed protocol is consuming more time than [11]. However, notwithstanding this, the proposed protocol consumes less time than [9, 11-16, 20, 21], and our protocol fully complies with all required security properties.

Accountability Analysis
In this section, we investigate the proposed protocol regarding accountability properties. We also provide some guidance to prove the accountability of our proposed protocol. According to the model specified in Section 3.1, it can be seen that our protocol satisfies the accountability properties for all relevant parties: HCP, C, and P. In this, the logic of accountability analysis is derived and is adapted from Wang et al. and ammarat and Kurutach [33,34].

Formulae
(i) W believes ɸ: W believes that the statement ɸ is true. (ii) W sees X: some party has sent the message X to W, and W is able to read X. (iii) W has X: W possesses the message X. W can send X to other parties or use it for further processing. (iv) W says X: W has sent the message X.

Mashima and
Ahamad [3] Hou and Yeh [5] Al Alkeem et al. [7] Lo et al. [8] Ibrahim et al. [9] Hu et al. [15] Blobel et al. [16] Gajanayake et al. [27] Techapanupreeda and Chokngamwong [28] Our protocol  e HCP and C believe that they possess personal health records of P, where W denotes HCP and C. Note that C has PHR because P is authorized to use his/her PHR via the request that C sends through HCP.

Personal Health Record Authorizations
A9: every involved party believes that he/she can prove to the verifier that if the HCP has sent the message containing P's health records, C has authorization to use PHR from P.
W believes W CanProve (C says (C ID , PHR, T 1 ) ⟶ HCP authorized PHR(HCP, PHR, T 1 )) to V: each party believes that he/she can prove to V that if C has sent the message containing HCP ID , P ID , and the timestamp of the transaction, C has the authorization to requite to use PHR from HCP.
W believes W CanProve (P says (P ID , PHR, T 1 ) ⟶ HCP authorized PHR(HCP, P, PHR, T 1 )) to V: each party believes that he/she can prove to V that if HCP has sent the message containing HCP ID , P ID , PHR, and the timestamp T 1 , HCP has the authorization to use PHR from P.
W believes W CanProve (P says (P ID , PHR, T 1 ) ⟶ C authorized PHR(C, P, PHR, T 1 )) to V: each party believes that he/she can prove to V that if P has sent the message containing C ID , P ID , PHR, and the timestamp T 1 , C has the authorization to use PHR from P.

Conclusions
In this paper, we use a BAN logic, Scyther tool, and AVISPA verification tool to prove the completeness and the soundness of the protocol. e results show that the proposed accountability model and accountability protocol achieve our goals in terms of accountability. Firstly, we ensure that the actions of each party can be traced throughout the movement of data. Secondly, we can identify and trace the user, data source, and transactions between parties. Finally, the model and protocol meet the requirements of all crucial securities, that is, confidentiality, authorization, integrity, mutual-authentication, and nonrepudiation. e advantage of our proposed protocol is safe and robust from attack. Moreover, it is having the accountability security property to ensure that the involved party will be confident in using electronic health records and having dispute resolution to resolve any argument that may arise in the future.
Data Availability e datasets generated during and/or analyzed during the current study are available from the corresponding author on reasonable request.