Professional Documents
Culture Documents
Efficient and Secure Communication Architecture For E-Health System
Efficient and Secure Communication Architecture For E-Health System
Web Site: www.ijettcs.org Email: editor@ijettcs.org, editorijettcs@gmail.com Volume 2, Issue 4, July August 2013 ISSN 2278-6856
Department of Computer Science and Engineering, Indian School of Mines, Dhanbad, Dhanbad-826004, India
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
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
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.
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:
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
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
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
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
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
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
Page 101