Efficient and Secure Communication Architecture For E-Health System

International Journal of Emerging Trends & Technology in Computer Science (IJETTCS)
Web Site: www.ijettcs.org Email: editor@ijettcs.org, editorijettcs@gmail.com 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 patients 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 patients 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 patients 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 cant prevent the unauthorized access of patients health information. To overcome this drawback, Yu et al. [4] again proposed an Electronic Health Record (EHR) content protection system using Page 93

smart card and PMR in 2007 by using high density smart cards for patients, health care provider and support personnel. The patients smart card is used to encrypt patients EHR and to enforce rule- based access control to a patients EHR and a personalized media recorder (PMR) is used to interface between the patients and healthcare providers 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 entitys 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 entitys 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 CAs 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 users 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

RA: It is a registration authority which is responsible for the registration of users/actors such as patients, hospitals and is responsible for storing patients 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) Patients 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 patients diseases symptoms, and the doctor treats the patient with the help of the patients 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 patients PHI data. Use case 2.4: The doctor uploads the patients 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 patients treatment use case is decomposed into four use cases which is given in figure 3 and briefly demonstrated below.
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
Volume 2, Issue 4 July August 2013

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; the patients identity and a nonce NRA and then concatenates them as X= MSP||NRA. Now it encrypts X using the patients 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
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.
Patient validates RAs 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 RAs 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 patients 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 <Zp*, >. Now the stepwise negotiation of SK and UT are given in figure 6 and illustrated as follows: Page 96
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 patients certificate and retrieves the valid public key of the patient. It also verifies the patients 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

using SK and then sends the encrypted messages along with its identity and patients identity to RA. Step 4: RA Patien t: 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 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. patients 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 patients 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.
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 hospitals 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 patients identity from its database, uses it to decrypt the encrypted message and gets R1 and DS. It then decrypts the signed message using the patients 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 HSPs master secret MSHSP and then sends the encrypted message along with its identity and patients 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
Page 97

Figure 7 Service UT negotiation 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 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 patients 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 hospitals 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
Figure 8 Treatment procedure 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: DOC Patient: Treatment form, CADOC After receiving request, the doctor checks the availability of the patients 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 doctors public key and then sends the encrypted message to the doctor. For integrity purposes and to keep patients 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 patients 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 patients 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 patients identity to RA. Step 5: RA DOC: IDP, ESK (IDP||PHI) After receiving the retrieve request, RA retrieves SK based on the patients identity from its database, uses it to Page 98
Hospital concatenates the patients 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 patients 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

decrypt the message, gets the identity of HSP and patient, verifies these identities and if the verification passes, RA retrieves the patients previous PHI data from its database, encrypts the patients identity and PHI data using SK and then sends the encrypted message and the patients identity to the doctor. Step 6: DOC Patient: ESK (SERVUT||Service Response), EPR (h(Service response))
DOC
Step2: DOC RA: CADOC, EPR (h(X))

DOC
IDDOC,
IDP,
ESK (PHI),
Doctor encrypts the PHI data using SK and sends the encrypted PHI along with his identity and certificate, patients 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 patients PHI data corresponding to the patients identity in its database.
Doctor decrypts the encrypted message using the SK received in step 3 and gets the patients 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 patients 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 doctors 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 patients 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.
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 NRA in message 2. Then the patient does the following Concatenates NRA with known IDP, NP, and IDRA; Calculates the hash digest of it as H = h (IDP || IDRA || NP || NRA); 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 MSP in message 2. Then there is no effect on calculation of hash digests and the comparison passes. Now the patient uses MSP 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
Figure 9 PHI data upload procedure Step1:DOC Patient: ESK (SERVUT|| PHI), EPRDOC (h(X) Doctor concatenates SERVUT with the patients 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

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 patients 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 patients 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 patients 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 patients PHI data after encrypting using the session key SK, so no one can see it. He also sends the signed copy of the patients 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 patients 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

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.
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. 18. [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. 1118. [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. 644654. [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
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. 4 No. of encrypt ion/ decrypt ion 6 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 748+1728+748 =3224 bytes Units of time requir ed 11651 .0
Registr ation
Session key & UT generat ion Service UT generat ion Treatm ent PHI upload
22
23302 .0
11651 .0
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.
12
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
Page 101

Efficient and Secure Communication Architecture For E-Health System

Загружено:

Сведения о документе

Оригинальное название

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

Efficient and Secure Communication Architecture For E-Health System

Загружено:

Авторское право:

Доступные форматы

International Journal of Emerging Trends & Technology in Computer Science (IJETTCS)