International Journal of Emerging Trends & Technology in Computer Science (IJETTCS) Web Site: www.ijettcs.org Email:
[email protected],
[email protected] Volume 2, Issue 4, July – August 2013 ISSN 2278-6856
Efficient and Secure Communication Architecture for E-Health System Sangram Ray1, Urbi Chatterjee2 and G.P. Biswas3 1,2,3
Department of Computer Science and Engineering, Indian School of Mines, Dhanbad, Dhanbad-826004, India
Abstract: Efficient and secure communication architecture for e-health system is proposed in this paper to support online treatment of patients by medical specialists working in any hospital registered to RA (registration authority). The proposed architecture comprises three actors and two use cases, where the actors like patients and hospitals register themselves to RA and doctors registers themselves at different hospitals through the registration use case, and all registered patients get their treatment through the patients’ treatment use case. In our proposed treatment procedure, initially a patient communicates RA for registration and receives a unique master secret. Later on, this master secret is used to negotiate a session key between the RA, patient and registered hospital and finally the session key in turn is used to negotiate a user token for treatment. A service user token is also generated by the hospital according to the disease syndromes and after which a selected doctor starts the treatment. After completion of treatment, the doctor generates the patient’s PHI (protected health information) data and uploads the same to RA. A digital public-key certificate based authentication protocol for registration phase and symmetric encryption/decryption based protocols have been proposed for secure communication of the proposed e-health system. The in-depth security and performance analysis of the proposed communication architecture shows that the system is efficient and well secured.
Keywords: E-health communication; Protected Health Information (PHI), Public-key certificate, Registration Authority (RA)
1. INTRODUCTION E-health is used in the health sector for digitally transmitting, storing and retrieving of patients’ medical data to take specialized care to upgrade the quality of life significantly. Introducing wireless mobile communication, we can further improve the e-health care system in terms of cost, time, ease of information exchange and treatment. To facilitate correct diagnosis, proper treatment, and privacy and security of the sharing of medical information between patients and doctors, a mobile based e-health care system is needed with special attention such as efficient e-health architecture, proper security etc for its implementation. For security issues, the data confidentiality, integrity, authenticity, non repudiation, access control among its different components and entities must be considered. Volume 2, Issue 4 July – August 2013
Although a number of increasing solutions [1]-[5] have been made to implement e-health care system in secure way, none of them are feasible and well secured. In 2004, Marty et al. [1] proposed an e-health care system based on the concept of BAN (Body Area Network) linked via mobile telephony with a hospital or a health care system in which BAN is attached to a patient’s body and connected to a concentrator to collect the user data. All the collected data are then sent to the e-health care server, which is connected to the end user application of the hospital or the health care centre for monitoring the patient, through mobile telecommunication system. Finally, they have discussed different kind of threats that may hamper the integrity, confidentiality, authenticity and the system performance of the proposed architecture and showed some basic security services to be fulfilled before minimally usable as e-health care system. However, the major drawback of this scheme is that it has not defined how the system is implemented in different communication layers. Later on, Elmufti et al. [2] proposed a similar architecture to provide privacy in mobile and web-based e-health system in 2006. Initially, all users of this system are registered to a mobile operator and establish security credentials with it. Then a user requests the healthcare authentication server (HAS) to get a user token for accessing different health care services. The different service providers are also registered to HAS. To authenticate a user, HAS verifies the user security credentials from the mobile operator and if he is validated, HAS generates a user token for the user to have access to any of the services. Thus, they have introduced a single sign on system based on GAA (Generic Authentication Architecture) to authenticate the user and to generate key material. However, this scheme has a single point failure at HAS and the security issues are not well defined. In 2006, Yu et al. [3] proposed a wireless mobile multimedia solution system for healthcare based on radio frequency identification tags (RFIDs) and pocket PCs where a patient’s information is directly accessible from a pocket PC which replaces the traditional hardcopy folders and also reduces clinical human errors such as incorrect drug administration and improves productivity of physicians and medical staffs. The major drawback of this scheme is that it can’t prevent the unauthorized access of patient’s health information. To overcome this drawback, Yu et al. [4] again proposed an Electronic Health Record (EHR) content protection system using Page 93
International Journal of Emerging Trends & Technology in Computer Science (IJETTCS) Web Site: www.ijettcs.org Email:
[email protected],
[email protected] Volume 2, Issue 4, July – August 2013 ISSN 2278-6856 smart card and PMR in 2007 by using high density smart cards for patients, health care provider and support personnel. The patient’s smart card is used to encrypt patient’s EHR and to enforce rule- based access control to a patient’s EHR and a personalized media recorder (PMR) is used to interface between the patient’s and healthcare provider’s smart cards and to store protected EHR transactions. The major drawback of this scheme is that this scheme contains the disadvantages of smartcard base system such as the impossibility to authenticate the presenter of the smart card and also this scheme is only concerned about the EHR management, not about the integration of the whole healthcare system. Finally, in 2008, Chan et al. [5] proposed multi agent architecture for mobile health monitoring to assist in the doctor-topatient interaction spanning multiple remote locations and hospitals. They have discussed current scenario of chronic illness management using episode-based healthcare and presented the network infrastructure for a multi-agent mobile e-health system. This system is typically useful for patients who do not have life threatening illness and require monitoring via a mobile system that encompasses intelligent capabilities to detect abnormalities, provide temporary advice and send urgent alerts to medical staff in emergency. However, it faces the security threats during communication due to use of mobile infrastructure. In this paper, to remove the difficulties of existing schemes [1]-[5] and establish a secure and efficient ehealthcare system, we have integrated the whole ehealthcare management process into a system that takes care of patients at home and hospitals, provides online diagnosis of a disease by specialist doctors at a preferred hospital and proper treatment with tracking the previous medical data/EHR of patients. We have considered the concepts presented in [2] as basic steps and instead of considering the telephone operator as a third-party security, we incorporated a transparent actor-wise independent security system that uses the conventional PKI and public-key certificate. As a result, this makes the system more secure and generalized e-health system and does not require any additional infrastructure for its implementation. The main contributions of this paper are designing of required use cases, e-health architecture and the secure implementation of different activities or phases using existing PKI and public-key certificate. In addition, we introduced RA as a single-point registration authority that uniquely registers all the actors including patients, doctors, and hospitals, helps patients for their treatment with appropriate doctors, and storing and protecting PHI data for future references. Thus, if the proposed architecture is incorporated with any of the health monitoring and EHR maintaining schemes discussed in [1]-[5], it can bring a huge change in the field of healthcare and help to upgrade the human life up to some extent. The rest of the paper is organized as follows. Section 2 introduces the public key certificate and CA (certificate Volume 2, Issue 4 July – August 2013
authority) for easy understanding of certificate generation, issuance and verification. The proposed ehealth architecture with UML use case diagram is introduced in section 3 and its detail implementation with different security protocols are given in section 4. The indepth security and performance analysis of the proposed e-health system along with its additional advantages are given in section 5 and 6 respectively. Finally, section 7 concludes the paper.
2. PUBLIC K EY CERTIFICATE AND CA The proposed system is supported by existing PKI (public key infrastructure) where each entity must posses a digital certificate issued by a Certificate Authority (CA) [6], [7]. A CA is a federal or state organization that binds an entity’s public key with its identity and issues a digital certificate with prior authentication. It maintains a directory that contains all the entities identity and the corresponding public keys. After receiving a request for a certificate from an entity, a CA first verifies the entity’s identification and issues a public key certificate that contains all the information of the entity, its public key and a signature of the CA. The signed value contains the hash digest of all fields, encrypted with the CA’s private key. Note that a CA has a well known public key that cannot be forged, so any user can use the public key of the CA to verify other user’s certificate. For the sake of clarity, an overall mechanism of certificate issuance is given in figure 1. However, it is not possible to have just one CA issuing all certificates for all users. So, the responsibility for creating, storing, issuing and revoking certificates is distributed among several CAs followed by several trust models such as hierarchical model, mesh model [6], [7] etc.
Figure 1 Mechanism of issuing a certificate by CA
3. PROPOSED ARCHITECTURE In this section, a use case diagram of the proposed ehealth system is described to represent the different ways to be used by the users. It consists of four actors as follows: PATIENT: It represents a patient with a public key certificate issued and signed by CA. Page 94
International Journal of Emerging Trends & Technology in Computer Science (IJETTCS) Web Site: www.ijettcs.org Email:
[email protected],
[email protected] Volume 2, Issue 4, July – August 2013 ISSN 2278-6856 RA: It is a registration authority which is responsible for the registration of users/actors such as patients, hospitals and is responsible for storing patient’s PHI (protected health information) data. A user gets treatment only from those hospitals which are registered to the RA. HSP: It is a hospital which provides medical services to the patients. DOC: It represents a doctor who may register at different hospitals. After registration, he treats patients, gives medical advices and generates the patients’ PHI data. The proposed system has two basic use cases –1) Registration and (2) Patient’s treatment. The registration use case signifies the registration of the patients, hospitals, doctors and the patients’ treatment use case signifies the treatment procedure provided to the patients by the system. Since all four actors of the system are involved in both use cases, the proposed two use cases are described separately to illustrate the system clearly. The generalization of Registration use case diagram is given in figure 2 and briefly demonstrated below.
Figure 3 Illustration of treatment use case Use case 2.1: Initially, a patient requests to RA for treatment at a particular hospital. The RA then generates a session key and a user token among the patient, hospital and itself. Use case 2.2: A patient sends his/her disease symptoms to the hospital, and on receiving, the hospital decides the service type necessary and accordingly generates a service ID. Use case 2.3: Hospital informs the doctors about the patient’s diseases symptoms, and the doctor treats the patient with the help of the patient’s previous medical reports (if any) retrieved from the RA. The doctor may interact with the patient for several times during treatment and finally generates the patient’s PHI data. Use case 2.4: The doctor uploads the patient’s newly generated PHI data to RA and sends a copy to the patient. Now the complete proposed e-health system with different components and their interconnectivity are shown in the figure 4, which gives a clear view of the system architecture and the communication between entities.
Figure 2 Registration use case Use case 1.1: Patients are registered to RA with prior mutual authentication using their public key certificates and negotiate a unique master secret key between a patient and RA. Use case 1.2: Hospitals are registered to the RA and a unique master secret key is negotiated by each hospital with RA. Use case 1.3: Doctors are generally associated to different hospitals and accordingly, they are registered to the different hospitals, and a unique master secret key is negotiated by each doctor during registration. Since a doctor may do practice at different hospitals, so it is necessary to negotiate a session key with the concerned hospital during treatment session and the same is deleted after completion of the treatment process. Thus, the session key, which is generated using the master secret key, remains active during each session. The patient’s treatment use case is decomposed into four use cases which is given in figure 3 and briefly demonstrated below.
Volume 2, Issue 4 July – August 2013
Figure 4 Proposed e-health communication architecture
4. PROPOSED E-HEALTH SCHEME In this section, the detail description of different phases presented in section 3 is described. Each phase is implemented in secure manner and for this, it is assumed that all actors must have a public key certificate signed by a CA. The different abbreviations used are given below. IDP identity of patient; IDDOC identity of doctor; IDHSP identity of hospital; IDRA identity of RA; CAP public key certificate of patient; CADOC public key certificate of doctor; CAHSP public key certificate of hospital; CARA public key certificate of RA; NP nonce of patient; NHSP nonce of hospital; Page 95
International Journal of Emerging Trends & Technology in Computer Science (IJETTCS) Web Site: www.ijettcs.org Email:
[email protected],
[email protected] Volume 2, Issue 4, July – August 2013 ISSN 2278-6856 NRA h(_) E D MSP MSHSP (PRP, PUP) (PRDOC, PUDOC) (PRHSP, PUHSP) (PRRA, PURA)
nonce of RA; a secure one-way hash function (ex. SHA1, MD5); encryption algorithm; decryption algorithm; master secret negotiated between patient and RA; master secret negotiated between hospital and RA; private-public key pair of patient; private-public key pair of patient; private-public key pair of hospital; private-public key pair of RA;
4.1 Registration A common registration phase consisting of user authentication and master secret key negotiation is proposed such that all users follow the same registration procedure. The reason of keeping authentication in the registration phase is that only valid and genuine participants can register in the system. The negotiated master secret key is used for generation of different session keys for their secure implementation. The registration procedure for a patient to RA is given in figure 5, and the same is followed by different hospitals and doctors to register at RA and hospital respectively.
Figure 5 Registration procedure Step1: Patient → RA: IDP, CAP, NP A patient initially sends his registration request with his identity, public key certificate and a nonce to RA. Step2: RA → Patient:
E PU P (X), E PRRA (h(Y)), CARA
After receiving the request, RA validates the patient’s certificate and retrieves the valid public key of the patient. It also verifies the patient’s identity and checks the validity period of the certificate available in the timestamp of the certificate. If all information are verified, then RA randomly generates a unique master secret MSP corresponding to Volume 2, Issue 4 July – August 2013
the patient’s identity and a nonce NRA and then concatenates them as X= MSP||NRA. Now it encrypts X using the patient’s public key and sends it to the patient in message 2. For integrity and authentication purposes, RA generates Y=IDP||IDRA||NP||NRA, signs on it and then sends the signed message along with its public key certificate to the patient in message 2. Step3: Patient → RA: EMS (Z) P
Patient validates RA’s certificate, retrieves its public key and validates also the timestamp. Now he decrypts the encrypted X using his private key and correctly obtains the unique master secret MSP and the challenge NRA. To verify the integrity of the message and authenticate RA, the patient decrypts the signed message using RA’s public key and gets h(Y) = h(IDP||IDRA||NP||NRA) = H (say). Now he generates Y′ = IDP||IDRA||NP||NRA, calculates the hash digest H′ = h(Y′) and compares H′ = H ? If it fails, terminates the phase and requests to resend; otherwise, calculates Z =NRA -1, encrypts Z using MSP and then sends the encrypted message to RA in message 3. Step 4: RA → Patient: Yes/No After receiving, RA decrypts the message using MSP of the patient and gets Z =NRA -1. Now it calculates its own NRA -1 = Z′ (say) and compares Z =Z′ ? If it fails, terminates the phase and requests to resend; otherwise, it becomes sure that the mutual authentication with the patient is completed and MSP is securely negotiated and then sends an acknowledgement to the patient in message 4. Note that, this unique master secret MSP will be used later as the security association in next phases. 4.2 Treatment procedure In this phase a combined session key (SK) is negotiated between the patient, RA and a hospital (HSP) and it will be used as the security association in next phases. After secure negotiation of SK, RA generates a user token (UT) and sends it to both the patient and the hospital. The patient then sends a treatment request to the hospital and on receiving, the hospital generates a service user token (SERVUT) and sends it to both the patient and doctors. On the basis of SERVUT, any doctor selected by the patient starts treatment and finally generates and uploads the patient’s PHI data to RA and a copy of the same is sent to the patient. The total treatment procedure is divided into several sub phases which are discussed below. 4.2.1 Session key and user token negotiation The secure negotiation of combined session key (SK) and user token (UT) between the patient, RA and a HSP is established based on the well known group DiffieHellman technique [8, 9] in which two public numbers p and g are chosen by the entities, where p is a large prime number and g is a generator of order p-1 in the group . Now the stepwise negotiation of SK and UT are given in figure 6 and illustrated as follows: Page 96
International Journal of Emerging Trends & Technology in Computer Science (IJETTCS) Web Site: www.ijettcs.org Email:
[email protected],
[email protected] Volume 2, Issue 4, July – August 2013 ISSN 2278-6856 using SK and then sends the encrypted messages along with its identity and patient’s identity to RA. Step 4: RA → Patient: IDHSP, IDP, EMS (P3), ESK (NHSP -1) P RA decrypts the message using MSHSP, gets R2 and P2, calculates P3=R2y mod p and the session key SK=P2 y mod p =R1zy mod p =gxyz mod p, uses SK to decrypt the encrypted nonce and gets NHSP. Now it encrypts P3 using MSP, calculates NHSP -1, encrypts it using SK and then sends the encrypted messages to the patient along with the identities of patient and hospital. Step 5: Patient → HSP: ESK (NHSP -2) Patient decrypts and gets P3 using MSP, calculates the session key SK=P3x mod p=R2yx mod p =gxyz mod p and then uses it to decrypt and get NHSP -1. Now he calculates NHSP -2, encrypts it using SK and then sends the encrypted message to HSP to validate whether all three of them have possessed the same session key. Figure 6 Session key and user token negotiation Step 1: Patient → RA: IDP, IDHSP, EMS (R1||DS), P
E PRP (h(Y)) Patient randomly selects x (0 ≤ x ≤ p-1), calculates R1 = gx mod p, concatenates it with his disease symptoms (DS), encrypts the concatenated message using his master secret key and then sends the encrypted message to RA along with his identity and the hospital’s identity where he want to do treatment. For integrity purposes, he calculates Y = IDUSR|| IDHSP || DS, signs on it using his private key and sends the signed message to RA in message 1. Step 2: RA → HSP: IDP, IDRA, EMS HSP (R1||P1) After receiving, RA retrieves the MSP of the corresponding patient’s identity from its database, uses it to decrypt the encrypted message and gets R1 and DS. It then decrypts the signed message using the patient’s public key and gets the h (Y) = h (IDUSR|| IDHSP || DS) = H (say). Now it calculates hash digest of received identities and DS as H′ =h (IDUSR|| IDHSP || DS) and compare H′ = H ? If the comparison fails, it terminates the process and requests to resend; otherwise, calculates P1=R1y mod p where y (0 ≤ y ≤ p-1) is a random number, concatenates it with R1, encrypts the concatenated message using the HSP’s master secret MSHSP and then sends the encrypted message along with its identity and patient’s identity to the hospital. Step 3: HSP →RA: IDHSP, IDP, EMS HSP (R2||P2 ), ESK (NHSP) The hospital decrypts the message using its master secret and gets R1 and P1, calculates R2=gz mod p, P2=R1z mod p and session key SK =P1z mod p =R1yz mod p =gxyz mod p. Now it concatenates R2 with P2, encrypts the concatenated message using MSHSP, generates a nonce NHSP, encrypts it Volume 2, Issue 4 July – August 2013
Step 6: HSP → RA: Yes/ No Hospital decrypts the message using his SK and gets NHSP -2. Now it calculates its own NHSP -2 =(NHSP -1)-1and compares it with the received NHSP -2. If both match, then it is assured that all three of them have possessed the same session key and then sends an acknowledgement to RA; otherwise terminates the execution. Step 7: RA → Patient: ESK (UT) RA receives the acknowledgement of negotiation of session key and then generates the user token as UT = EPRRA (h(X||T)) where X =h(Y) received in message 1 and T is a timestamp for the validity of UT, and generates Z =UT||IDP||DS||T. Now it encrypts UT using SK and sends the encrypted message to the patient. After receiving, patient decrypts the message using SK and gets the user token UT which will be used to avail any service from the particular hospital within the time period specified in T. Step 8: RA →HSP: ESK (Z) RA encrypts Z using SK and sends it to hospital. After receiving, hospital decrypts the message using SK and gets Z =UT||IDP||DS||T i.e. patient’s user token, identity, disease symptoms and the validity period of user token and then save these in its directory. 4.2.2 Service UT negotiation In this phase, the hospital selects the service identity (SERVID), uses it to generate a service UT (SERVUT) and negotiates it with the patient and the list of specialized doctors based on patient’s disease syndromes. Later, this SERVUT is used to authenticate the patient for treatment to any doctor until the time stamp expires. The details step-wise negotiation procedure is given in figure 7 and illustrated below.
Page 97
International Journal of Emerging Trends & Technology in Computer Science (IJETTCS) Web Site: www.ijettcs.org Email:
[email protected],
[email protected] Volume 2, Issue 4, July – August 2013 ISSN 2278-6856
Figure 7 Service UT negotiation
Figure 8 Treatment procedure
Step 1: Patient → HSP: IDP, ESK (UT||DS) Patient concatenates his user token and disease symptoms, encrypts the concatenated message using the session key SK and then sends it and his identity as a treatment request to the hospital.
Step 1: Patient → DOC: IDP, IDDOC, Treatment request Patient sends his treatment request to the selected doctor with the identities of doctor and patient.
Step 2: HSP → Patient: ESK (IDHSP||SERVUT||LOD) After receiving the request, the hospital retrieves the corresponding SK and UT from its own database based on the patient’s identity, decrypts the message using SK, gets UT and DS, and compares the received UT with the stored UT. If both match, generates SERVID= (IDP || IDHSP || DS || Sl. No.), where Sl. No. is the serial number of the patient and then creates SERVUT by signing (SERVID||T) using its private key i.e. SERVUT= EPRHSP (h(SERVID||T)) where T is the timestamp in UT. Now the hospital selects the list of specialized doctors’ (LOD) identity (IDDOC) based on DS, concatenates it with SERVUT and hospital’s identity, encrypts the concatenated message using SK and then sends the encrypted message to the patient. After receiving, the patient decrypts the message using SK and gets the service UT and a list of specialized doctors, who are available in the hospital at that time, from which he may choose anyone for treatment. Step 3:
HSP → DOC: ESK (IDP||SERVUT||DS) DOC
Hospital concatenates the patient’s identity, SERVUT and disease symptoms, encrypts it using the session key SKDOC which is prior negotiated between the doctor and hospital, and then sends the encrypted message to all the doctors who are selected in LOD to inform them about the patient and his disease symptoms. After receiving, the doctor decrypts the message using his session key SKDOC and gets the patient’s identity, SERVUT and disease symptoms. 4.2.3 Treatment In this phase, patient selects a doctor from LOD of his own choice, sends him a treatment request and follows the treatment procedure discussed below and shown in figure 8. Volume 2, Issue 4 July – August 2013
Step 2: DOC → Patient: Treatment form, CADOC After receiving request, the doctor checks the availability of the patient’s identity, SERVUT and disease symptoms from hospital in step 3 of section 4.2.2. If so, he sends a treatment form and his public key certificate to the patient. Step 3: Patient → DOC: EPU DOC (SERVUT || filled up form ||SK), ESK (h(filled up form)) Patient fills up the treatment form, concatenates it with the SERVUT and session key SK, encrypts the concatenated message using the doctor’s public key and then sends the encrypted message to the doctor. For integrity purposes and to keep patient’s medical information undisclosed, the patient calculates the hash digest of the filled up form, encrypts it using SK and then sends the encrypted message to the doctor in message 3. Note that, the filled up form which contains patient’s sensitive medical information is securely transmitted and kept purely confidential between the patient and the doctor. Step 4: DOC → RA: IDDOC, IDP, ESK (IDHSP||IDP) Doctor decrypts the first part of the message using his private key, gets SERVUT, filled up form and SK, calculates the hash digest of the filled up form as H=h(filled up form), decrypts the second part of the message using SK, gets the hash digest h(filled up form)= H′ (say) and then verifies H′ = H ? If the verification passes, he starts treatment and retrieves patient’s previous PHI data (if any) from RA. To do this, he concatenates the identities of patient and HSP, encrypts the concatenated message using SK, and then sends the encrypted message along with his identity and the patient’s identity to RA. Step 5: RA→ DOC: IDP, ESK (IDP||PHI) After receiving the retrieve request, RA retrieves SK based on the patient’s identity from its database, uses it to Page 98
International Journal of Emerging Trends & Technology in Computer Science (IJETTCS) Web Site: www.ijettcs.org Email:
[email protected],
[email protected] Volume 2, Issue 4, July – August 2013 ISSN 2278-6856 decrypt the message, gets the identity of HSP and patient, verifies these identities and if the verification passes, RA retrieves the patient’s previous PHI data from its database, encrypts the patient’s identity and PHI data using SK and then sends the encrypted message and the patient’s identity to the doctor. Step 6: DOC→ Patient: ESK (SERVUT||Service Response), EPR (h(Service response)) DOC
Doctor decrypts the encrypted message using the SK received in step 3 and gets the patient’s identity and PHI data. Now he generates a Service response i.e. his capability to treat the patient by analyzing the DS, the information provided in the treatment form and the patient’s previous PHI data, concatenates SERVUT with Service response, encrypts the concatenated message using SK and sends the encrypted message along with a signed copy of the Service response to patient. After receiving, patient decrypts the encrypted message using SK, gets the Service response of the doctor and then verifies the doctor’s signature to check the integrity of Service response. If it is positive, treatment is started; otherwise, patient selects any other doctor from LOD and follows step 1 to step 6. Note that, during this treatment period the doctor may asked for medical tests to the patient and the patients performs the same and encrypts the medical test reports using SK and then sends to the doctor. This is may be followed several times until the doctor comes to a final decision after which the treatment session is completed. 4.2.4 Diagnosis report upload After completion of the treatment procedure, doctor generates the patient’s PHI data, sends it to the patient and uploads the same to RA. The detail PHI data upload procedure is given in figure 9 and illustrated below.
Figure 9 PHI data upload procedure Step1:DOC → Patient: ESK (SERVUT|| PHI), EPRDOC (h(X) Doctor concatenates SERVUT with the patient’s PHI data, encrypts the concatenated message using SK and then sends the encrypted message to the patient. He also generates X=IDP||IDDOC||IDHSP||PHI, signs on it and then sends the signed message to the patient for integrity purposes. After receiving, Patient decrypts the encrypted PHI data using SK, gets his newly generated PHI data and then verifies the signature. If the verification passes, he stores the PHI data in his external device. Volume 2, Issue 4 July – August 2013
Step2: DOC → RA: CADOC, EPR (h(X))
IDDOC,
IDP,
ESK (PHI),
DOC
Doctor encrypts the PHI data using SK and sends the encrypted PHI along with his identity and certificate, patient’s identity and the signed X to upload PHI at RA. After receiving, RA decrypts the message using SK, gets PHI and verifies the signature. If it passes, RA stores the patient’s PHI data corresponding to the patient’s identity in its database.
5. SECURITY ANALYSIS In this section, the phase-wise security aspects of the proposed system are analyzed. We have assumed that both the CA and the RA are trusted parties and their system is very hard to compromise. In registration phase, the main objective is to securely generate and send a unique master secret for individual patient. The encryption/decryption and digital signature are used to ensure that any intruder cannot modify any part of the message and if so, then the modification will be detected by verifying the signature. Thus the integrity and the confidentiality of the message have been preserved. Let us consider that an intruder has changed the encrypted message that contains the master secret. If so, then the patient gets a different value after decryption and below two cases may happen. Firstly, suppose the NRA has been changed to N′RA in message 2. Then the patient does the following – Concatenates N′RA with known IDP, NP, and IDRA; Calculates the hash digest of it as H′ = h (IDP || IDRA || NP || N′RA); Decrypts the signed message using the public key of RA; Gets the hash digest h (IDP || IDRA || NP || NRA)= H (say); Compares H′ = H ? It is clear that the comparison fails due to the changes made in NRA which leads to detect the attack and discard the message. Secondly, suppose the master secret MSP has been changed to MS′P in message 2. Then there is no effect on calculation of hash digests and the comparison passes. Now the patient uses MS′P to encrypt the NRA-1and sends the encrypted message to RA as message 3. After receiving, RA decrypts the received message using MSP and compares the decrypted value with its own generated NRA-1. If the comparison fails, the change of MSP is detected by RA and it sends a negative reply to the patient in message 4. Thus the registration phase of our scheme is secure enough as no one can access and alter the MSP. In session key and user token negotiation phase, we have implemented group Diffie-Hellman protocol [9], [10] to generate the session key between the patient, RA and HSP and later on this session key is securely Page 99
International Journal of Emerging Trends & Technology in Computer Science (IJETTCS) Web Site: www.ijettcs.org Email:
[email protected],
[email protected] Volume 2, Issue 4, July – August 2013 ISSN 2278-6856 distributed among them. Several cryptographic steps are taken to make it secure such as – i) Since DH technique is vulnerable to the man-in-themiddle attack [10], we have encrypted the R1 using MS to make it inaccessible to any intruder. ii) It may happen that the patient denies later that he has sent the treatment request, so it is mandatory to send a signature of the patient along with the request to support non repudiation. Now the RA can easily verify the signature as it possesses the certificate of all registered patients. iii) In the subsequent messages, all the values required for generating the session key are encrypted using MSP, so no third party can access the original values. If these are changed at any time by an intruder, then SK becomes different for patient, RA and HSP and is detected in the validation phase in which the patient encrypts Np-2 using SK and compares it with the received value from RA and HSP. If the comparison fails, then the patient is sure that the SK is compromised. iv) RA generates the UT by concatenating a timestamp with patient’s signed value. Hence the patient cannot demand for treatment service if the timestamp expires. In service selection and SRVUT negotiation phase, the main objective is to negotiate a unique service UT for a specific patient in a specific HSP and for a specific disease. This restricts the patient to access more than one HSP at a time using the same SRVUT. In this regard, a specific service ID SERVID= (IDP || IDHSP || DS || Sl No) is generated and signed by the RA along with a timestamp which makes the SRVUT secure. In treatment phase, the main concern is to keep the patient’s PHI data undisclosed except the patient and the doctor. To make it secret and unchangeable, the patient sends a service request message which has two parts - the first part is the concatenation of SERVUT, filled up form and SK which is encrypted using the public key of the doctor, and the second part contains the hash digest of the filled up form encrypted using SK. After receiving this service request message, the doctor initially decrypts the first part using his private key PRDOC and gets the SERVUT, filled up form and SK. Later on, he calculates a hash digest of the filled up form, decrypts the second part of the message using SK and compares the decrypted value with the newly generated hash digest. If it passes, then the doctor accepts the service request message; otherwise, discards it and sends a negative response to the patient. In diagnosis report upload phase, the patient’s PHI data is uploaded to RA which is an essential part of the completion of the treatment procedure and the upload procedure should be authorized by the respective doctor. To do this, the doctor sends the patient’s PHI data after encrypting using the session key SK, so no one can see it. He also sends the signed copy of the patient’s PHI data Volume 2, Issue 4 July – August 2013
along with the identities of patient and the HSP to support data integrity. Thus, all the communication phases of our proposed ehealthcare architecture are well secured from relevant cryptographic attacks.
6. PERFORMANCE ANALYSIS In this section, a performance analysis of the proposed ehealth care system has been made with respect to the size of total message exchanged and units of time requires for encryption/decryption of the messages. To analyze the system, the following considerations are made. For encryption/ decryption, we have used the RSA cryptosystem and DH technique where – The size of p and q are at least 512 bits, The size of n is 1024 bits. The time complexity [11], [12] of this system is O(log2(log2p-1)(log2q-1))3+1. The message size of the highest number having 512 bits is 2512-1. Hence the units of time required for encryption [11], [12] is – [(log2(log2 ((2512 -1)-1) (log2 ((2512-1)-1))3+1] ≈ [(log2(log2 ((2512)-1) (log2 ((2512)-1))3+1] ≈ 5825.5 units of time The predefined size of some messages is considered as follows: ID: 320 bytes Digital certificate: 1024 bytes Master secret: 124 bytes Nonce (N): 32 bytes Disease syndrome (DS): 300 bytes Time stamp (TS): 50 bytes LOD: 1280 bytes Treatment Request: 50 bytes Service Request/Response: 1 KB Treatment Form: 1 KB Filled Up Treatment Form: 2 KB PHI: 2 KB Now the calculation procedure of the total size of messages exchanged in the registration phase is shown below. In the patient’s registration request message – IDP = 320 bytes CAP = 1024 bytes NP = 32 bytes Then the total size of the first message is equal to – (320+1024+32) bytes = 1376 bytes In the response message 2 Size of concatenation of MSP (124 bytes) and NRA (32 bytes) is 124+32 bytes = 156 bytes The second part, an encryption of a hash value, is 1024 bits = 128 bytes The third part is CARA= 1024 bytes Therefore, the total size of the second message is (156+156+1024) = 1308 bytes. Finally, the size of the verification message is 124 bytes. Page 100
International Journal of Emerging Trends & Technology in Computer Science (IJETTCS) Web Site: www.ijettcs.org Email:
[email protected],
[email protected] Volume 2, Issue 4, July – August 2013 ISSN 2278-6856 So, the total size of the message passed in the registration phase is – 1376+1408+128+0.125 bytes = 2912.125 bytes In this manner, message sizes of rest of the exchanged messages of different phases are calculated and given in table 1 which shows the efficiency of the proposed system.
7. CONCLUSION In this paper, we have introduced efficient and secure communication architecture for e-health care system. We have described how a digital public-key-certificate based authentication has been developed to validate and register the users with the negotiation of a unique master secret. A symmetric session key based encryption/decryption technique has been implemented which has less processing cost comparing public-key encryption/decryption technique. The security analysis and the processing costs of all proposed protocols are presented in this paper, which shows satisfactory performance. However, it may be noted that the processing costs may be further reduced if the ECC-based implementation of the proposed e-health system is considered, which may be taken as our future research direction. Table 1: Performance analysis of the proposed system Phase
No. of Ms g.
Registr ation
4
No. of encrypt ion/ decrypt ion 6
Session key & UT generat ion Service UT generat ion Treatm ent
9
22
3
8
6
12
PHI upload
2
8
Size of total message exchanged (bytes) 1376+1408+12 8+ 0.125=2912.12 5 1196+896+102 4+896+128 +0.125+128+7 94=5062.125
Units of time requir ed 11651 .0
23302 .0
748+1728+748 =3224 bytes
11651 .0
690+2048+230 4+960+2368+1 152=9522 2304+3840=61 44
23302 .0 23302 .0
References [1] Ramon Martí, Jaime Delgad and, Xavier Perramon, Security Specification and Implementation for Mobile eHealth Services, Proc. of IEEE International Conference
Volume 2, Issue 4 July – August 2013
on e-Technology, e-Commerce and e-Service, 2004, pp. 241-248. [2] Kalid Elmufti, Dasun Weerasinghe, M Rajarajan, Veselin Rakocevic and Sanowar Khan, Privacy in Mobile Web Services e-Health, Proc. of 1st International Conference on Pervasive Computing Technologies for Healthcare, Innsbruck, 2006. [3] W. D. Yu, P. Ray and T. Motoc, A RFID technology based wireless mobile multimedia system in healthcare, Proc. of The 8th International Conference on e-Health Networking, Applications and Services, HEALTHCOM (2006), pp. 1–8. [4] W. D. Yu and M. A. Chekhanovskiy, An electronic health record content protection system using smartcard and PMR, in Proc. of The 9th International Conference on eHealth Networking, Application and Services (2007), pp. 11–18. [5] V. Chan, P. Ray and N. Parameswaran, Mobile e-Health monitoring: an agent-based approach, IET Communication 2(2) (2008), pp. 223-230. [6] J. Weise, Public Key Infrastructure Overview, Sun PSSM Global Security Practice, Sun Blue Prints™, Online August 2001. [7] NIST, Introduction to Public Key Technology and the Federal PKI Infrastructure, National Institute of Standards and Technology (2011). [8] W. Diffe and M. Hellman, New directions in cryptology, IEEE Transaction on Information Theory 22 (1976), pp. 644–654. [9] W. Stallings, Cryptography and Network Security: Principles and Practices, (4th Edition, Prentice Hall, 2009), pp. 420-430. [10] M. Friedl, N. Provos and W. Simpson, Diffie-Hellman Group Exchange for the Secure Shell (SSH) Transport Layer Protocol, IETF, march, 2006. http://www.ietf.org/rfc/rfc4419.txt [11] N. Challa and J. Pradhan, Performance Analysis of Public key Cryptographic Systems RSA and NTRU, International Journal of Computer Science and Network Security, vol. 7, No.8, 2007, pp. 87-96. [12] A. K. Mohapatra, N. Gupta and N. Prakash, Step-wise calculation of Performance and Complexity Analysis of Safer with RSA Algorithm. www.funalive.com/neha/documents/RSA_VS_SAFER.pdf
CORRESPONDING AUTHOR Sangram Ray has obtained B.Sc (Hons.) degree in Mathematics from University of Burdwan, West Bengal, India in 2005, and M.Sc in Mathematics and Computing and M.Tech. in Computer Application from Indian School of Mines, Dhanbad, India in 2007 and 2009 respectively. Currently he is a Senior Research Fellow in the Department of Computer Science and Engineering, Indian School of Mines, Dhanbad, India and pursuing Ph.D. in Computer Science and Engineering in the same university. His main research interests include Cryptography, Network/Information Security and Computer Networks.
Page 101
