[BACK]
Computer Systems Science & Engineering
DOI:10.32604/csse.2023.029356
images
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.

images

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.

images

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. 36.

images

images

images

images

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

images

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.

images

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.

images

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.

images

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.

images

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.

images

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)usingUserclientsPWUandrandomnonceNSend: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:

AIDUIDUρ

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:UserclientsidentityIDU{Compute:ρH(IDe||y)H(PWU||N)usingIDe,H(PWU||N)andePMCsyAIDUIDUρ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)AIDUIDUH(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 :

BUH(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:ePMCsidentityIDeGet:H(IDe||y)AIDUIDUH(PWU||N)Select:BioUsuchasface,fingerprintetc.Compute:BUH(BioU||AIDU||x)usingBioU,AIDUandUserclientsxGenerate: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:UserclientsanonymousidentityAIDUDecrypt: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:ePMCsidentityIDeDecrypt: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.

images

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:UserclientsanonymousidentityAIDUandtimestampvalidation|TUTU|ΔTSearch:AIDUtogetH(PWU||N)AIDUGet:H(PWU||N)AIDUCompute:ρH(IDe||y)H(PWU||N)AIDUusingIDe,H(PWU||N)AIDUandePMCsyEncrypt: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:

BUH(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,BU,σ} , 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 identityIDe and timestamp validation|TeTe|ΔTDecrypt :DPRU{EPUe{ρ}usingPRU}P1=DPRe{C1}Input:Bio{Compute :BUH(BioUAIDUx)using BioU,AIDuandUserclients xσBUρ using biometric authentication value BU and authentication challenge value ρCompare :σ?=σGenerate : Digital signature EPRU{AIDU,BU}with AIDU,BU using PRUSigU=EPRU{AIDu,BU}Encrypt:EPUU{SigUBUσ} with SigU,BU,σ using PUeC2=EPUe{SigU,BU,σ}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 clients anonymous identityAIDUand timestamp validation|TUTU|ΔTDecrypt :DPRe{EPUe{SigU,BU,σ}}usingPReP2=DPRe{C2}Verify:AIDU,BUSigU usingPUUCompute :ρBUusing biometric authentication valueBUandauthentication 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:ePMCsidentityIDeandtimestampvalidation|TeTe|Δ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.

images

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,DataAIDU} , obtained by encrypting the authentication token, Auth.Token{AIDU} , the electronic signature value, SigU , and data, DataAIDU , 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,DataAIDUusingPUeC1=EPUe{Auth.Token{AIDU},SigU,DataAIDU}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(DataAIDU) , for data DataAIDU of plain-text P1 , stores the received data DataAIDU , and terminates the data transfer phase.

{Check:Userclientstimestampvalidation|TUTU|Δ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(DataAIDU)} , for the data, DataAIDU , and sends C3=EPUU{Auth.Token{AIDU},Sige,DataAIDU} , obtained by encrypting the authentication token, Auth.Token{AIDU} , the electronic signature value, Sige , and data, DataAIDU , with the user client’s public key, its identifier, IDe , and its time-stamp value, Te , to the user client.

{Check:Userclienttimestampvalidation|TUTU|ΔTDecrypt:DPRe{EPUe{Auth.Token{AIDU}}}usingPReP2=DPRe{C2}Verify:Auth.Token{AIDU}Search:AIDUtogetDataAIDUGet:DataAIDUGenerate:DigitalsignatureEPRe{H(DataAIDU)}withDataAIDUusingPReSig=EPRe{H(DataAIDU)}Encrypt:EPUU{Auth.Token{AIDU},Sige,DataAIDU}withAuth.Token{AIDU},Sige,DataAIDUusingPUUC3=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(DataAIDU) , 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(DataAIDU) and H(DataAIDU) , for the data, DataAIDU , of the plain text, P3 . It then obtains the received data, DataAIDU , and terminates the data transfer phase.

{Check:ePMCsidentityIDeandtimestampvalidation|TeTe|ΔTDecrypt:DPRU{EPUU{Auth.Token{AIDU},Sige,DataAIDU}}usingPRUP3=DPRU{C3}Compare:Auth.Token{AIDU}?=Auth.Token{AIDU}Verify:H(DataAIDU)SigeusingPUeCompare:H(DataAIDU)?=H(DataAIDU)Get:DataAIDU

4  Security Analysis of the Proposed Scheme

In this section, a security analysis is performed to respond to the analyzed security threats of the e-prescription system.

4.1 Information Sniffing Prevention

Exchanged information can be leaked through data-packet sniffing during the authentication and data-transfer phases. To prevent this, the proposed scheme applies public key encryption using {PUEntity,PREntity} for data exchanged between entities. Thus, only valid entities can perform data encryption/decryption. Moreover, the information that can be obtained by attackers is < Auth.Request,AIDU,IDe,TX,CX > from the authentication process, and < TX,CX,Data.Request,IDe > from the data-sharing process. As AIDU is an anonymous identifier, attackers cannot identify the user client, even if they obtain the ID. Furthermore, additional information can be neither used nor identified, even if it is leaked from the e-prescription system. Thus, data leakage is prevented.

4.2 Information Falsification Prevention

Data can be falsified by attackers during authentication and data-transfer phases or as a result of errors during data communication. This presents reliability problems for the generated data collected and processed by the e-prescription system. During authentication, attackers can obtain the client’s anonymous identifier, AIDU . Using this, they can falsify data {DataAIDU} for sent data {DataAIDU} . Then, the ePMC performs integrity H(DataAIDU)?=H(DataAIDU) verification based on the signature value, SigU=EPRU{H(DataAIDU)} , for the data received from an authenticated user. If these data are falsified, this equation is not completed, and the data falsification threat is prevented.

4.3 Entity Spoofing Prevention

When data are generated, collected, and processed from unauthorized entities, the reliability problem of the e-prescription system is exacerbated, and violations occur. To prevent this, the proposed scheme performs mutual authentication during registration and authentication phases. In particular, Fast IDentity Online (FIDO) authentication is applied to prevent threats in network and physical environments, such as when agents steal a clinician’s computer to issue illegal e-prescriptions.

Consequently, the biometric authentication element, BUH(BioU||AIDU||x) , generated based on the biometric information, BioU , selected during the registration phase cannot be generated, even if the attacker obtains the user client’s BioU,AIDU , as the secret value, x , cannot be known. Hence, even if the anonymous identifier, AIDX , and identifier, IDX , of an entity are obtained by sniffing authentications, the entity is spoofed when C2=EPUe{SigU,BU,σ} is sent, the encrypted message is decrypted by the ePMC, and mutual authentication is performed by comparing ρBUσ and ρ?=ρ through the biometric authentication element. Thus, threats are prevented.

4.4 Repudiation Prevention

A user client who uses the e-prescription system may repudiate e-prescription data reception. Consequently, authentication and data-transfer phases are carried out using the digital signature value, SigU=EPRU{AIDU,BU} or SigU=EPRU{H(DataAIDU)} , and repudiation attacks can be prevented using the signer’s private key, PRX .

4.5 Prevention of Information Reuse

Attackers can cause availability violations in authentication and data processing using retransmission attacks on data exchanged between entities during authentication or data-transfer phases. Attackers can sniff information containing an Auth.Request message requesting authentication by a user client or information containing a Data.Request message. Then, when the attacker tries to access the data process used for e-prescriptions by reusing the information in the authentication or data-transfer process, the ePMC can prevent reuse attacks by performing |TXTX|ΔT for the time stamp, TX , which is the data validation element included in each message, making the attack invalid.

4.6 Privacy Invasion Prevention

The ripple effect is high when data are leaked from the e-prescription system because it uses sensitive data. Furthermore, when FIDO is used, the biometric information is replicated in the user client’s smart devices. Hence, privacy invation can occur if the user client’s biometric information leaks during authentication. Therefore, the user client’s anonymous identifier, AIDUIDUρ , is used during the authentication phase to ensure anonymity, even if it is sniffed by an attacker. Thus, privacy invasion can be prevented, even if the biometric authentication element, BU , for biometric information BioU is leaked. Hence, the actual biometric information, BioU , cannot be known.

5  Conclusions

This study proposed an authentication and data-sharing scheme for agents using a centralized data management center for an e-prescription system and verified its potential security capability. The innovative capability provided by this study improves the security of the growing e-prescription system in the medical industry. The security of medical services has been long-researched [10], but most studies viewed data flow in scope that was too large. Hence, detailed response measures to potential security threats were insufficient. Moreover, with the application of many new technologies, the surface area of attack has become larger, and the attack paths have become more diversified. Thus, a more advanced response to security threats is needed. Moreover, in countries with advanced medical welfare programs, such as Australia and Sweden, related information used in medical information management systems is transmitted and managed through centralized data management centers operated by the state. The innovations provided by this tudy will improve the security and efficiency of these systems over legacy medical service institutions. The security of medical services can be secured by preventing illegal access and leakage of medical information via proper authentication and data-sharing capabilities. Furthermore, the safety and security provided by e-prescription system services can be enhanced by constructing a centralized data management-centric environment and acquiring security techniques based on the proposals of this study. This study is expected to contribute to the security of IoBE worldwide by considering multi-industry linkages.

Funding Statement: This work was supported by the National Research Foundation of Korea (NRF) grant funded by the Korea government (MSIT; No. 2021R1A2C2011391).

Conflicts of Interest: The authors declare that they have no conflicts of interest to report regarding the present study.

References

 1.  V. S. Naresh, S. S. Pericherla, P. S. R. Murt and S. Reddi, “Internet of Things in healthcare: Architecture, applications, challenges, and solutions,” Computer Systems Science and Engineering, vol. 35, no. 6, pp. 411–421, 2020. [Google Scholar]

 2.  H. Su, X. Yuan, Y. Tang, R. Tian, E. Sun et al., “A learning-based power control scheme for edge-based eHealth IoT systems,” KSII Transactions on Internet and Information Systems, vol. 15, no. 12, pp. 4385–4399, 2021. [Google Scholar]

 3.  M. Lee, J. Jang-Jaccard and J. Kwak, “Novel architecture of security orchestration, automation and response in internet of blended environment,” Computers, Materials & Continua, 2022. http://dx.doi.org/10.32604/cmc.2022.028495. [Google Scholar]

 4.  Q. A. Bui, W. B. Lee, J. S. Lee, H. L. Wu and J. Y. Liu, “Biometric-based key management for satisfying patient’s control over health information in the HIPAA regulations,” KSII Transactions on Internet and Information Systems, vol. 14, no. 1, pp. 437–454, 2020. [Google Scholar]

 5.  M. Samadbeik, M. Ahmadi, F. Sadoughi and A. Garavand, “A comparative review of electronic prescription systems: Lessons learned from developed countries,” Journal of Research in Pharmacy Practice, vol. 6, no. 1, pp. 3–11, 2017. [Google Scholar]

 6.  N. Noorbakhsh-Sabet, R. Zand, Y. Zhang and V. Abedi, “Artificial intelligence transforms the future of health care,” The American Journal of Medicine, vol. 132, no. 7, pp. 795–801, 2019. [Google Scholar]

 7.  D. Kim and J. Kwak, “A Framework for preventing illegitimate e-prescribing practices,” in Advances in Computer Science and Ubiquitous Computing:CSA-CUTE 17, Singapore: Springer, pp. 648–653, 2018. [Google Scholar]

 8.  D. Kim and J. Kwak, “The framework of 3P-based secure ehealth-information system,” in Proc. IEEE Int. Conf. on Platform Technology and Service (PlatCon), Jeju, Republic of Korea, pp. 1–6, 2018. [Google Scholar]

 9.  D. Kim and J. Kwak, “A study on secure information flow control in centralized ehealth-information system,” in Proc. 12th Asia Pacific Int. Conf. on Information Science and Technology (APIC-IST), Chiang Mai, Thailand, pp. 120–122, 2017. [Google Scholar]

10. X. Liu, Y. Li., J. Qu and Y. Ding, “A lightweight pseudonym authentication and key agreement protocol for multi-medical server architecture in TMIS,” KSII Transaction on Internet and Information Systems, vol. 11, no. 2, pp. 924–944, 2017. [Google Scholar]

images This work is licensed under a Creative Commons Attribution 4.0 International License, which permits unrestricted use, distribution, and reproduction in any medium, provided the original work is properly cited.