Computer Systems Science & Engineering DOI:10.32604/csse.2023.029356
Article

Secure e-Prescription Management System: Mitigating Blended Threat in IoBE

Deukhun Kim1, Heejin Kim2 and Jin Kwak3,*

1ISAA Lab., Institute for Information and Communication, Ajou University, Suwon, 16499, Korea
2Korea Orphan & Essential Drug Center (KOEDC), Seoul, 04523, Korea
3Department of Cyber Security, Ajou University, Suwon, 16499, Korea
*Corresponding Author: Jin Kwak. Email: security@ajou.ac.kr
Received: 01 March 2022; Accepted: 06 April 2022

Abstract: New information and communication technologies (ICT) are being applied in various industries to upgrade the value of the major service items. Moreover, data collection, storage, processing, and security applications have led to the creation of an interrelated ICT environment in which one industry can directly influence the other. This is called the “internet of blended environments” (IoBE), as it is an interrelated data environment based on internet-of-things collection activities. In this environment, security incidents may increase as size and interconnectivity of attackable operations grow. Consequently, preemptive responses to combined security threats are needed to securely utilize IoBE across industries. For example, the medical industry has more stringent information protection measures than other industries. Consequently, it has become a major target of attackers, as more clinician–patient interactions occur over the internet owing to COVID-19. Therefore, this study aims to acquire security for IoBE while focusing on the medical industry. Among the various types of medical ICT services, this study analyzes data flow and potential security threats from the e-prescription lifecycle perspective, which is highly utilized, strongly data-centric, and has numerous security issues. Based on our analysis, we propose a secure authentication and data-sharing scheme.

Keywords: Authentication scheme; blended threat; e-prescription; internet of blended environments

1  Introduction

With the continuous development of information and communication technologies (ICTs), new internet of things (IoT) devices, cloud-based storage and operations, big data and business intelligence services, mobile applications, and artificial intelligence (AI) models are continuously emerging. Notably, these technologies are being utilized in a more interrelated, blended manner than ever and have enabled data convergence among the formerly segregated industrial fields [1,2]. This new environment is called the “internet of blended environment” (IoBE), and it adds layers of complexity to security risks as the interconnectivity of attackable data-dependent operations grow [3]. Thus, new types of security threats are being identified. Therefore, studies to create a secure IoBE must be urgently conducted.

From the several complex security risks that spread across the IoBE, the current study focuses on the medical industry, which regularly creates, manipulates, and stores sensitive patient data. Hence, the medical industry has the largest damage potential and has become a major target of the attackers, as an increasing number of clinician–patient interactions are taking place over the internet owing to COVID-19 restrictions [4].

Among the plethora of data-heavy medical services, the current study focuses on the e-prescription system, which is heavily targeted by cybercriminals [5,6], and incident rates are continuously increasing. For example, in one incident, approximately 700 million patient and prescription records were compromised, and at least 400 million were confirmed as sold. In another incident, approximately 78 million prescription records were illegally harvested and sold to pharmacies as contact information.

Therefore, this study analyzes various security threats affecting the generation, collection, and processing of e-prescription data to provide a sharing and authentication scheme to improve IoBE security.

The rest of this paper is organized as follows. Section 2 provides an overview of the e-prescription system and analyzes the security risks that may occur in the analyzed environment. Section 3 proposes a secure sharing and authentication scheme for the e-prescription system. Section 4 verifies the proposed authentication and data-sharing technology, and Section 5 presents our conclusions.

2  Related Works

2.1 E-Prescription System

The e-prescription system allows clinicians and patients to avoid handling paper prescriptions and dealing with clinician-to-pharmacy coordination and printing. In the legacy prescription process, patients receive a paper prescription after diagnosis and obtain medications and equipment at a separate dispensary. However, paper prescriptions face counterfeiting, forgery, and loss/theft risks. To overcome these problems, e-prescription methods that electronically manage prescriptions have recently received great attention. With the ubiquity and lowering costs of ICT and the rapid utilization of smart devices, the construction of e-prescription systems is accelerating. However, with fast growth comes great risk, as the medical information handled on such networks is among the most sensitive in all e-commerce. See the examples in Tab. 1. When medical information is leaked, patient privacy is violated, and they encounter added personal risks. Hence, focusing on the e-prescription aspect, potent and quickly available security measures are needed.

2.2 Security Threats in the E-Prescription System

In this section, e-prescription system security risks are presented and analyzed [7]. Agents that participate in e-prescription processes consist of patients, clinicians, pharmacists, and e-prescription management center (ePMC) agents who manage cloud-based services. The security threats and mitigation requirements of e-prescription activities per agent are summarized in Tab. 2. Furthermore, the roles of each are explained as follows:

•   Patients: Patients engage clinicians to receive diagnoses and treatment options via an e-prescription, and they receive medications and equipment from pharmacists accordingly. A patient may request changes to their prescription options using the e-prescription system after full authentication.

•   Clinicians: Clinicians fully authenticate their identity on the e-prescription system to provide patients with medical services and prescriptions.

•   Pharmacists: Pharmacists fully authenticate their identity on the e-prescription system to dispense drugs according to the corresponding prescription.

•   ePMC agents: ePMC agents fully authenticate their identity on the e-prescription system so that patients, doctors, and pharmacists can perform their roles. ePMC agents also manage the storage, modification, deletion, and recovery of e-prescriptions, and they generate unique codes and verify validity periods, availability, and other authentication activities.

2.2.1 Analysis of the E-Prescription Issuance Process

The e-prescription issuance process is detailed next so that the phases of security threats in Tab. 2 can be further analyzed [8,9].

❑ Entire process for issuing e-prescription

Step 1: Patient authenticates and receives treatment from clinician.

Step 2: Clinician sends e-prescription to ePMC agent.

Step 3: ePMC agent generates an e-prescription code.

Step 4: ePMC agent stores/manages e-prescription and code.

Step 5: ePMC agent sends e-prescription code to patient.

Step 6: Patient presents the e-prescription code to pharmacist.

Step 7: Pharmacist sends e-Prescription code to ePMC agent for verification.

Step 8: ePMC agent verifies the e-prescription code.

Step 9: ePMC agent sends e-prescription authorization to pharmacist.

Step 10: Pharmacist dispenses prescribed medications or equipment.

Step 11: Pharmacist sends e-prescription processing results to ePMC agent.

Step 12: ePMC agent updates the e-prescription processing result.

❑ Patient-to-hospital process for issuing e-prescription

Step 1: Patient requests treatment from a clinician.

Step 2: Clinician requests patient authentication.

Step 3: Patient authenticates to prove their identity.

Step 4: Clinician treats patient.

Step 5: Clinician requests ePMC agent issuance of e-prescription.

Step 6: ePMC agent requests clinician authentication.

Step 7: Clinician authenticates to prove their identity.

Step 8: ePMC agent issues e-prescription.

Steps 9~11: ePMC agent manages e-prescription code/stores and manages e-prescription and code/sends e-prescription code. See entire process for issuing e-prescription.

❑ Patient-to-pharmacy process for issuing e-prescription

Step 1~2: Patient presents e-prescription code/requests inquiry of e-prescription code. This is identical to the corresponding process for issuing e-prescription.

Step 3: ePMC agent requests authentication of pharmacist.

Step 4: Pharmacist authenticates to prove their identity.

Steps 5~9: Pharmacist sends e-prescription code/sends e-prescription/provides prepared medicines or equipment/sends e-prescription processing result; ePMC agent updates e-prescription processing result. This is identical to the corresponding process for issuing e-prescription.

❑ Patient-to-ePMC process for issuing e-prescription

Step 1: Patient requests e-prescription inquiry of ePMC agent.

Step 2: ePMC agent requests authentication of patient.

Step 3: Patient authenticates to prove identity.

Step 4: ePMC agent examines patient’s e-prescription.

Step 5: ePMC agent provides the content the of e-prescription to the patient.

Step 6: ePMC agent takes necessary action (modification, deletion, or recovery).

Step 7: ePMC agent updates the e-prescription processing result.

2.2.2 Detailed Analysis of Security Threats for E-Prescription Issuance Process

In the e-prescription issuance process analyzed in Section 2.2.1, security threats exist in the process of sending and receiving information (e.g., issuances, transfers, and inquiries). The risk areas are expanded in Tabs. 3–6.

The e-prescription system security threats (Fig. 1) are shown in Tab. 3.

Figure 1: Entire process for issuing e-prescription

In Step 1, the exchange of patient authentication information is threatened by sniffing, falsification, spoofing, reuse, and repudiation attacks, and invasion of privacy is possible due to the leakage of sensitive information.

In Step 2, the exchange of clinician authentication information and the issuance of e-prescriptions are threatened by sniffing, falsification, spoofing, reuse, and repudiation attacks, and invasion of privacy is possible.

In Step 5, the issuance of a unique e-prescription code issued by the ePMC agent is threatened by sniffing, falsification, reuse, and repudiation. In this case, spoofing and invasion of privacy are not considered, as the ePMC agent is a trusted agent, and the unique e-prescription code does not contain sensitive information.

In Step 7, the exchange of pharmacist authentication information and e-prescription code requests is threatened by sniffing, falsification, spoofing, reuse, and repudiation attacks.

In Step 9, the exchange of e-prescription information is threatened by sniffing, falsification, reuse, and repudiation attacks, and invasion of privacy is possible. Spoofing is not considered in this case, as the ePMC agent is a trusted agent.

In Step 11, the exchange of e-prescription processing results is threatened by sniffing, falsification, and spoofing attacks.

The security threats of the patient-to-clinician e-prescription issuance exchange in Fig. 2 are detailed in Tab. 4. The authsentication threats of Steps 3 and 7 are identical to those of Steps 1 and 2 in Tab. 3. The e-prescription issuance security threats in Step 8 are identical to those of Step 2 in Tab. 3. The e-prescription code transmission threats of Step 11 are identical to those of Step 5 in Tab. 3.

Figure 2: Patient-to-hospital process for issuing e-prescription

The security threats of the patient-to-pharmacist e-prescription issuance process in Fig. 3 are detailed in Tab. 5. The e-prescription code threats in Steps 2 and 4 are identical to those of Step 7 in Tab. 3. However, Step 2 is not considered as it does not have a privacy invasion risk. The e-prescription transmission threats in Step 6 are identical to those of Step 9 in Tab. 3. The e-prescription processing result exchange threats in Step 8 are identical to those of Step 11 in Tab. 3.

Figure 3: Patient-to-pharmacy process for issuing e-prescription

The security threats of the patient-to-ePMC agent e-prescription issuance process in Fig. 4 are detailed in Tab. 6. The patient authentication threats in Step 3 are identical to those of Step 1 in Tab. 3. The e-prescription issuance process of Step 5 is identical to those of Step 9 in Tab. 3, which can occur when the e-prescription is transmitted. In Step 6, threats of sniffing, falsification, spoofing, reuse, and repudiation attacks for patient requests to the ePMC agent also exist.

Figure 4: Patient-to-ePMC process for issuing e-prescription

From this mapping, the proposed protection scheme can now be illustrated.

3  Proposed Scheme

In this section, a more secure e-prescription management scheme is proposed according to the issuance requirements of each entity (agent). The entities participating in the e-prescription system consist of patients, clinicians, pharmacists, and ePMC agents. They are set as entities, depending on the similarity of the authentication and e-prescription-related processing behaviors of the analyzed processes. The scheme is executed by the ePMC agent, who manages the overall e-prescription process. There are three subprocesses: registration phase, authentication phase, and data transfer phase. Tab. 7 shows the notations used.

3.1 Registration Phase

Fig. 5 shows the registration phase proposed to perform authentication between entities comprising the e-prescription issuance and processing, and the process is described below.

Figure 5: Registration phase in our scheme

Step 1. [User client sends < IDU,H(PWU||N) > to ePMC]

The user client inputs IDU and PWU and generates a random nonce N using PRNG(⋅) . Hence, H(PWU||N) is computed. The user client then sends their identifier, IDU , and H(PWU||N) to the ePMC and requests registration.

{Input:UseragentinputtoIDU,PWUGenerate:RandomnonceNusingPRNG(⋅)Compute:H(PWU||N)usingUserclient′sPWUandrandomnonceNSend:IDU,H(PWU||N)

Step 2. [ePMC checks IDU and sends < IDe,AIDU > to User client]

The ePMC checks the identifier IDU of the user client and computes ρ , which is used as the authentication challenge value using the received H(PWU||N) , their own identifier IDe , and a secret value, y , as follows:

ρ←H(IDe||y)⊕H(PWU||N)

Then, the AIDU , an anonymous identifier of the user client, is computed using the computed ρ , as follows:

AIDU←IDU⊕ρ

Afterward, the ePMC stores the H(PWU||N)AIDU obtained by indexing the H(PWU||N) received from the user client and the authentication challenge value, ρ , and sends their identifier, IDe , and an anonymous identifier, AIDU , to the user client.

{Check:Userclient′sidentityIDU{Compute:ρ←H(IDe||y)⊕H(PWU||N)usingIDe,H(PWU||N)andePMC′syAIDU←IDU⊕ρusingiIDUandauthenticationchallengevalueρStore:H(PWU||N)AIDU,ρSend:IDe,AIDU

Step 3. [User client checks IDe and sends < AIDU,C1 > to ePMC ]

The user client checks the ePMC’s identifier, IDe , and obtains H(IDe||y)′ by calculating the following equation using the received anonymous identifier, AIDU , their identifier, IDU , and H(PWU||N) :

H(IDe||y)′←AIDU⊕IDU⊕H(PWU||N)

Then, the user client selects their biometric information, BioU (e.g., fingerprint or face scan). Then, to prevent the leakage of biometric information during authentication, BU , which is used as the biometric authentication value, is calculated as follows using the user’s anonymous identifier, AIDU , and secret value, x :

BU←H(BioU||AIDU||x)

Then, the user client generates their public key pair {PUU,PRU} , stores their anonymous identifier, AIDU , received from the ePMC and their private key, PRU . They then send C1=EPUe{AIDU,BU,PUU,H(IDe||y)′} , which was obtained by encrypting the anonymous identifier, AIDU , the biometric authentication value, BU , and the public key, PUU , to obtain H(IDe||y)′ using the ePMC’s public key, PUe , and the anonymous identifier AIDU to the ePMC.

{Check:ePMC′sidentityIDeGet:H(IDe||y)′←AIDU⊕IDU⊕H(PWU||N)Select:BioUsuchasface,fingerprintetc.Compute:BU←H(BioU||AIDU||x)usingBioU,AIDUandUserclient′sxGenerate:Publickeypair{PUU,PRU}Store:PRU,AIDUEncrypt:EPUe{AIDU,BU,PUU,H(IDe||y′)}withAIDU,BU,PUU,H(IDe||y′)usingPUeC1=EPUe{AIDU,BU,PUU,H(IDe||y)′}Send:AIDU,C1

Step 4. [ePMC checks AIDU,P1 and sends < IDe,C2 > to User client ]

The ePMC checks the anonymous identifier, AIDU , of the user client and obtains the plain text, P1 , by performing DPRe{EPUe{AIDU,BU,PUU,H(IDe||y)′}} , which decrypts the received encrypted message, C1 , using the user’s private key, PRe . The ePMC verifies this by comparing H(IDe||y)′ to the existing value, H(IDe||y) , and computes σ , which is used as another authentication challenge based on the received biometric authentication value, BU , and the authentication challenge value, ρ , as follows:

σ←BU⊕ρ.

Afterward, the ePMC stores the public key, PUU , received from the user client and sends C2=EPUU{σ} , obtained by encrypting the authentication challenge value, σ , with the user client’s public key, PUU , and its identifier, IDe , to the user client.

{Check:Userclient′sanonymousidentityAIDUDecrypt:DPRe{EPUe{AIDU,BU,PUU,H(IDe||y)′}}usingPReP1=DPRe{C1}Compare:H(IDe||y)′?=H(IDe||y)Compute:σ←BU⊕ρusingbiometricauthenticationvalueBUandauthenticationchallengevalueρStore:PUUEncrypt:EPUU{σ}withauthenticationchallengevalueσusingPUUC2=EPUU{σ}Send:IDe,C2

Step 5. [User client checks IDe,P2 and the end of registration phase]

The user client checks the ePMC’s identifier, IDe , and obtains the σ of the plain text, P2 , by performing DPRU{EPUU{σ}} , which decrypts the received encrypted message, C222 , using their private key, PRU . Then, the user client stores the authentication challenge value, σ , and completes the registration phase.

{Check:ePMC′sidentityIDeDecrypt:DPRU{EPUU{σ}}usingPRUP2=DPRU{C2}.Store:σ

3.2 Authentication Phase

Fig. 6 shows the authentication phase proposed to perform authentication between entities comprising the issuance and processing of e-prescriptions, and the process is described below.

Figure 6: Authentication phase in our scheme

Step 1. [User client sends < Auth.Request,AIDU,TU > to ePMC ]

To request authentication, the user client sends their anonymous identifier, AIDU, their time-stamp value, TU , and their request message, Auth.Request , to the ePMC.

{Request:UserclientAuth.RequesttoePMCSend:AIDU,TU

Step 2. [ePMC checks AIDU,TU and sends < IDe,Te,C1 > to User client ]

The ePMC checks the validity of the user client’s anonymous identifier, AIDU , and their time-stamp value, TU , and searches AIDU to obtain the H(PWU||N)′AIDU stored in Step 2 of the registration phase. Using this, the ePMC computes the authentication challenge value, ρ′ , as follows:

ρ′←H(IDe||y)⊕H(PWU||N)′AIDU.

Afterward, the ePMC sends C1=EPUU{ρ′} , obtained by encrypting the computed authentication challenge value, ρ′ , with the public key of the user client, IDe , and the time-stamp value, Te , to the user client.

{Check:Userclient′sanonymousidentityAIDUandtimestampvalidation|TU′−TU|≤ΔTSearch:AIDUtogetH(PWU||N)′AIDUGet:H(PWU||N)′AIDUCompute:ρ′←H(IDe||y)⊕H(PWU||N)′AIDUusingIDe,H(PWU||N)′AIDUandePMC′syEncrypt:EPUU{ρ′}withρ′usingPUUC1=EPUU{ρ′}Send:IDe,Te,C1

Step 3. [User client checks IDe,Te,P1 and sends < AIDU,TU,C2 > to ePMC]

The user client checks the validity of the ePMC’s identifier, IDe , and the time-stamp value, TU , and obtains the authentication challenge value, ρ′ , of the plain text, P1 , by performing DPRU{EPUU{ρ′}} , which decodes the encrypted message, C1 , with their private key, PRU . Afterward, the user client inputs the biometric information selected during the registration phase to compute the biometric authentication value, BU′ , using the anonymous identifier, AIDU , and secret value, x , as follows:

BU′←H(BioU′||AIDU||x)

Furthermore, the user client computes another authentication challenge value, σ′ , using the computed BU′ and the authentication challenge value, ρ′ , obtained by decrypting, as follows:

σ′←BU′⊕ρ′

After comparing and verifying the computed σ′ and the authentication challenge value, σ , stored in Step 5 of the registration phase, the user client generates the electronic signature value, SigU=EPRU{AIDU,BU′} , for the anonymous identifier, AIDU , and the biometric authentication value, BU′ , using their private key, PRU . Afterward, the user client sends C2=EPUe{SigU,B′U,σ′} , obtained by encypting their electronic signature value, SigU , biometric authentication value, BU′ , and authentication challenge value, σ′ , with the ePMC’s public key, their anonymous identifier AIDU , and their time-stamp value, TU , to the ePMC.

{Check:ePMC′ identity IDe and timestamp validation|Te′−Te|≤ΔTDecrypt :DPRU{EPUe{ρ′}using PRU}P1=DPRe{C1}Input:Bio′{Compute :B′U←H(Bio′U‖AIDU‖x)using BioU′,AIDu and Userclient′s xσ′←B′U⊕ρ′ using biometric authentication value B′U and authentication challenge value ρ′Compare :σ′?=σ′Generate : Digital signature EPRU{AIDU,B′U}with AIDU,B′U using PRUSigU=EPRU{AIDu,B′U}Encrypt:EPUU{SigUB′Uσ′} with SigU,B′U,σ′ using PUeC2=EPUe{SigU,B′U,σ′}Send:AIDU,TU,C2

Step 4. [ePMC checks AIDU,TU,P2 and sends < IDe,Te,C3 > to User client ]

The ePMC checks the validity of the user client’s anonymous identifier, AIDU , and time-stamp, TU , and obtains the plain text, P2 , by performing DPRe{EPUe{SigU,BU′,σ′}} , which decrypts the received encrypted message, C2 , with their private key, PRe . Afterward, the ePMC verifies the anonymous identifier, AIDU , of the electronic signature value, SigU , and the biometric authentication value ,BU′ , using their public key, PUU , and computes another authentication challenge value, ρ″ , using the received biometric authentication value, BU′ , and authentication challenge value, σ′ , as follows:

ρ″←BU′⊕σ′ .

The ePMC then compares and verifies the computed ρ″ with the authentication challenge value, ρ′ , computed in Step 2 of the authentication phase. Then, it generates the authentication token, Auth.Token{AIDU} , for the anonymous identifier, AIDU . Afterward, the ePMC sends C3=EPUU{Auth.Token{AIDU}} , obtained by encrypting the generated authentication token, Auth.Token{AIDU} , with the public key of the user client, its identifier, IDe , and its time-stamp value, Te , to the user client.

{Check:User client′s anonymous identity AIDUand timestamp validation|TU′−TU|≤ΔTDecrypt :DPRe{EPUe{SigU,BU′,σ′}}using PReP2=DPRe{C2}Verify:AIDU,BU′←SigU using PUUCompute :ρ″←BU′⊕using biometric authentication value BU′ and authentication challenge value σ′Compare :ρ″?=ρ′Encrypt:EPUU{Auth.Token{AIDU}} with AIDU using PUUC3=EPUU {Auth:Token{AIDU}}Send:IDe,Te,C3

Step 5. [User client checks IDe,Te,P3 and the end of authentication phase ]

The user client checks the validity of the ePMC’s identifier, IDe , and its time-stamp value, Te , to obtain the authentication token, Auth.Token{AIDU , of the plain text, P3 , by performing DPRU{EPUU{Auth.Token{AIDU}}} , which decrypts the received encrypted message, C3 , with its private key, PRU . Then, the user client terminates the authentication phase.

{Check:ePMC′sidentityIDeandtimestampvalidation|Te′−Te|≤ΔTDecrypt:DPRU{EPUU{Auth.Token{AIDU}}}usingPRUP3=DPRU{C3}Get:Auth.Token{AIDU}

3.3 Data-Transfer Phase

Fig. 7 shows the data transfer phase proposed to perform data storage and request among entities comprising the issuance and processing of e-prescriptions, and the process is described below.

Figure 7: Data transfer phase in our scheme

3.3.1 Data Transfer Process to Store Data (Step to Store Data)

Step 1. [User client sends < TU,C1 > to ePMC ]

To store data at the ePMC, the user client generates the electronic signature value, SigU=EPRU{H(DataAIDU)} , for data DataAIDU . Then, the user client sends C1=EPUe{Auth.Token{AIDU},SigU,DataAID′U} , obtained by encrypting the authentication token, Auth.Token{AIDU} , the electronic signature value, SigU , and data, DataAID′U , which were obtained during the authentication phase using the ePMC’s public key and the time-stamp value, TU , to the ePMC.

{Generate:DigitalsignatureEPRU{H(DataAIDU)}withDataAIDUusingPRUSigU=EPRU{H(DataAIDU)}Encrypt:EPUe{Auth.Token{AIDU},SigU,DataAIDU′}withAuth.Token{AIDU},SigU,DataAIDU′usingPUeC1=EPUe{Auth.Token{AIDU},SigU,Data′AIDU}Send:TU,C1

Step 2. [ePMC checks TU,P1 , store DataAIDU′ and the end of data transfer phase ]

The ePMC checks the validity of the user client’s time stamp value, TU , and obtains the authentication token, Auth.Token{AIDU} , and electronic signature value, SigU , of the plain text, P1 , by performing DPRe{EPUe{Auth.Token{AIDU},SigU,DataAIDU′}} , which decrypts the received encrypted message, C1 , with its private key. Afterward, the ePMC verifies the hash value of the electronic signature value, SigU , and the authentication token, Auth.Token{AIDU} , generated during the authentication phase using the user client’s public key, PUU . At this point, the ePMC compares and verifies the hash value, H(DataAIDU) , and the hash value, H(DataAID′U) , for data DataAIDU′ of plain-text P1 , stores the received data DataAID′U , and terminates the data transfer phase.

{Check:Userclient′stimestampvalidation|TU′−TU|≤ΔTDecrypt:DPRe{EPUe{Auth.Token{AIDU},SigU,DataAIDU′}}usingPReP1=DPRe{C1}Verify:Auth.Token{AIDU}andH(DataAIDU)←SigUusingPUUCompare:H(DataAIDU′)?=H(DataAIDU)Store:DataAIDU′

3.3.2 Data Transfer Process to Request Data (Step to Request Data)

Step 1. [User client sends < Data.Request,TU,C2 > to ePMC ]

To request data, the user client sends C2=EPUe{Auth.Token{AIDU}} , obtained by encrypting the authentication token, Auth.Token{AIDU} , with the ePMC’s public key, time-stamp value, TU , and data request message, Data.Request to ePMC.

{Request:UserclientData.RequesttoePMCSend:TU,C2

Step 2. [ePMC checks TU,P2 and sends < IDe,Te,C3 > to User client ]

The ePMC checks the validity of the user client’s time-stamp value, TU , obtains and verifies the authentication token, Auth.Token{AIDU} , of the plain text, P2 , by performing DPRe{EPUe{Auth.Token{AIDU}} , which decrypts the received encrypted message, C2 , with its private key, PRe , and then obtains the stored data, DataAIDU′ , by searching AIDU .

Afterward, the ePMC generates the electronic signature value, Sige=EPRe{H(DataAID′U)} , for the data, DataAID′U , and sends C3=EPUU{Auth.Token{AIDU}′,Sige,DataAID′′U} , obtained by encrypting the authentication token, Auth.Token{AIDU}′ , the electronic signature value, Sige , and data, DataAID″U , with the user client’s public key, its identifier, IDe , and its time-stamp value, Te , to the user client.

{Check:Userclient′timestampvalidation|TU′−TU|≤ΔTDecrypt:DPRe{EPUe{Auth.Token{AIDU}}}usingPReP2=DPRe{C2}Verify:Auth.Token{AIDU}Search:AIDUtogetDataAIDU′Get:DataAIDU′Generate:DigitalsignatureEPRe{H(DataAIDU′)}withDataAIDU′usingPReSig=EPRe{H(DataAIDU′)}Encrypt:EPUU{Auth.Token{AIDU}′,Sige,DataAIDU″}withAuth.Token{AIDU}′,Sige,DataAIDU″usingPUUC3=EPUU{Auth.Token{AIDU}′,Sige,DataAIDU″}Send:IDe,Te,C3

Step 3. [User client checks IDe,Te,P3 , get DataAIDU″ and the end of data transfer phase ]

The user client checks the validity of the ePMC identifier, IDe , and the time-stamp value, Te , and obtains the authentication token, Auth.Token{AIDU}′ , and the electronic signature value, Sige , of the plain text, P3 , by performing DPRU{EPUU{Auth.Token{AIDU}′,Sige,DataAIDU″}} , which decrypts the received encrypted message, C3 , using their private key, PRU . The user client then compares and verifies the obtained authentication token, Auth.Token{AIDU}′ , and the existing authentication token, Auth.Token{AIDU} , and verifies the hash value, H(DataAID′U) , of the electronic signature value, Sige , using the ePMC’s public key, PUe . At this point, the user client compares and verifies the hash values, H(DataAID′U) and H(DataAID″U) , for the data, DataAIDU″ , of the plain text, P3 . It then obtains the received data, DataAID″U , and terminates the data transfer phase.

{Check:ePMC′sidentityIDeandtimestampvalidation|Te′−Te|≤ΔTDecrypt:DPRU{EPUU{Auth.Token{AIDU}′,Sige,Data″AIDU}}usingPRUP3=DPRU{C3}Compare:Auth.Token{AIDU}′?=Auth.Token{AIDU}Verify:H(Data′AIDU)←SigeusingPUeCompare:H(Data″AIDU)?=H(Data′AIDU)Get:DataAIDU″