XML Security based Access Control for Healthcare Information inMobile Environment

Dasun Weerasinghe, Kalid Elmufti∗, M Rajarajan and Veselin RakocevicMobile Networks Research Group

School of Engineering and Mathematical SciencesCity University,

Northampton Square, London, EC1V 0HB, UK.abbp075@city.ac.uk

Abstract

Mobile and wireless devices have penetrated the healthcare sector due to their increased functionality, low cost,high reliability and easy-to-use nature. However, in suchhealth care applications the privacy and security of thetransmitted information must be preserved. Also differ-ent personal involved in the healthcare industrymust havedifferent access privileges to the patient information. Inthis paper we present a protocol that will share the infor-mation securely to the intended recipient using the XMLencryption and XML signature technologies.

1. Introduction

This paper proposes a protocol for XML based se-curity between a patient and the health services thatbuilds upon a mobile communication environment. Theproposed schema allows health services to provide atrusted and secure environment for healthcare informa-tion and medication management over the mobile de-vices. Patient is able to send the healthcare data overthe mobile device to the healthcare service, healthcareservice process and manipulate those data over differ-ent stakeholders in the system and finally deliver thephysical or digital medications to the patient.

Mobile healthcare will be an attractive solution forthe already overstretched and under budgeted healthsector since it reduces current paper based work, de-creases waiting list for appointments, enhances health-care services with faster and more reliable methods,and speeds up administrative functionalities. However

∗ This work was supported by sponsorship funding from CityUniversity, London

the use of mobile communication in healthcare has a se-rious security risk due to the fact that any modification,exposal to unauthorized access or loss of the health-care data may even put human life at a risk. There-fore confidentiality, authentication, integrity and non-repudiation in healthcare data are essential for mobilehealthcare. Meanwhile healthcare service defines differ-ent user levels such as doctor, nurse, laboratory, phar-macy and administrator and each level should have ac-cess different access control to healthcare data in thesystem.

Mobile Web services together with XML-based secu-rity present a proved framework for enterprise-level ar-chitectural schemes [8] but still there are no XML secu-rity based mobile communication models for healthcareservices. Implementation of the XML Security modelwill improve the quality, reliability and security of thehealth services. In this paper we present an XML en-cryption and signature based mobile web services en-vironment for health care application.

2. Technical Overview

XML is an extensible markup language specified byW3C (World Wide Web Consortium) [4]. It has be-come very popular quickly in data transmission be-cause of its flexibility and the platform-independency.As the XML becomes the most popular data transmis-sion media over the internet, a greater importance isplaced on security technology for the data in XML for-mat [9]. Confidentiality, integrity, authentication andnon-repudiation are some of the security threats asso-ciated with XML data transmission.

1-4244-1086-X/07/$25.00 ©2007 IEEE

2.1. XML Encryption

XML Encryption is an encryption technology thatprovides end-to-end security for applications that re-quire secure transmission of XML data. It solves thesecurity problems such as confidentiality, integrity andauthentication. Further to this XML Encryption pro-vides advanced features [5] such as

• Partial encryption; encrypts XML data withinspecific tags

• Multiple encryption; encrypts XML data multipletimes using different keys

• Complex encryption; encrypt particular portion ofthe XML tags according to the designation of therecipient

Example of XML Encryption is shown in the Ap-pendix A: let us assume, XML document containspatient’s blood pressure reading and it has to be en-crypted before transmission over the Internet. En-crypted <BloodPressure> element structures withthe <EncryptedData> element and it has child ele-ments such as the <EncryptionMethod> element; con-tains information about encryption algorithm, the<KeyInfo> element; contains information about thedecryption key, and the <CipherData> element; con-tains the cipher data.

2.2. XML Signature

XML Signature is an electronic signature technologywhich is defined to be used in XML data transmission.XML Signature specification [6] defines electronic sig-nature formats using XML, the creation of electronicsignature and rules for the verification process. It solvessecurity problems such as authentication, integrity andnon-repudiation. Further to this XML Signature pro-vides advanced benefits such as

• Partial Signature; allows only data contained inspecific tags to be signed in the XML document

• Multiple signature; enables multiple electronic sig-natures to be included in the XML document

Example of XML Signature is shown in AppendixB: Let us assume patient’s blood pressure count hasto be signed before the transmission. XML signatureis a document structured with the <Signature> ele-ment as the root element of the signature. It consistsof child elements such as <SignedInfo> element; con-tains reference to the algorithm used for the XML sig-nature creation and to the location of signed XML datathat is stored, <SignatureValue> element; contains the

signature value, and the <KeyInfo> element that con-tains the public key certification information for signa-ture verification. The <SignedInfo> element may con-tain multiple <Reference> and it enables any numberof XML data segments to be signed.

XML 1.0 specification has the flexibility to repre-sent equivalent contents in multiple XML formats suchas attribute occurrence sequence, blank character han-dling, etc [4]. The same XML document can be repre-sented in different formats and then those are differentin byte representation. XML signature is a technologybased on hash calculation that applies to byte represen-tations of data. Therefore the flexibility of the XML 1.0specification could raise critical problems in electronicsignatures. To overcome this problem before the XMLdata is signed or verified, it is converted to a Canoni-cal form that complies with the Canonical XML speci-fication to ensure that the problem of format variationscan be solved in order to allow the use of XML signa-ture [2]. When signed XML data is added to a child el-ement of another XML document and converted in ac-cordance with the Canonical XML specification, thenaming space of the added XML data changes becauseof canonicalization. This will lead to failure in XML sig-nature verification when signed XML data is embed-ded in a SOAP message. To avoid this problem, theexclusive XML Canonicalization was established as aspecification that is based on Canonical XML and ex-cludes naming space and other contexts for the targetof canonicalization [3].

2.3. XML Key management specification

The XML Key Management Specification (XKMS)provides an interface between XML applications and aPublic Key Infrastructure (PKI) and also it specifiesprotocols for distributing and registering public keys[7]. This specification eliminates the complex PKI ap-plication logic implementation at the client side and al-locates trust processing decisions in to separate trustprocessors. XML Key Information Service Specifica-tion (X-KISS) and the XML Key Registration ServiceSpecification (X-KRSS) are two major subparts of theXKMS [1].

X-KISS defines protocols to eliminate full or par-tial key information processing associated with XMLsignature and XML encryption at the client end. Theclient verifies the digital signature by passing the corre-sponding key information to the trusted server and theserver responds with the validity of the signed data. X-KRSS defines protocols to support the registration ofa public key and additional data at the trusted server.Key pair may be generated at the client end or by the

trusted server. This specification further defines auto-matic PKI renewal process without the client’s inter-action, revoke key binding, private key recovery whenan end user lost their private key and roaming when anend user required to use the private key in another de-vice.

3. Mobile Healthcare Architecture

The Mobile Healthcare architecture has four mainactors; the Patient, the Mobile Operator, the Health-care Operator and the Service Provider. The patientis assumed to access the services via a bandwidth-constrained Mobile Station, comprising the mobile de-vice and service-enabling SIM card connected to aGPRS or UMTS mobile network. The Healthcare Op-erator is assumed to require the maximum number ofpatients for the available services, and the maximumnumber of available services for the participating pa-tients. Service Providers and Patients should be capa-ble of dynamically and asynchronously entering andleaving the system. The services should be available topatients from various and disparate trust domains andcapable of being setup using Over The Air (OTA) tech-niques. The Mobile Operator interacts with the systemusing the standard and internationally agreed proto-cols. Healthcare Service is a service provider who is at-tached to the Healthcare Operator and it defines dif-ferent levels of stakeholders such as doctors, nurses,administrators, pharmacists and labs. Healthcare Ser-vice defines different access control levels to each stake-holder for accessing the healthcare information and weassume Healthcare Service as a trusted entity.

Patient Healthcare Operator / IdP

Mobile Operator

Doctor

Nurse

Administrator

Pharmacy

Lab

Insurance Service

Private Medical

Center

Healthcare Service

Stakeholders

Service Providers

Figure 1. Mobile Healthcare Architecture

3.1. Protocol

The protocol addresses the authentication, dataintegrity, confidentiality and data access control forhealthcare information in the mobile healthcare envi-ronment. The communication is based on the SimpleObject Access Protocol (SOAP) and the messages arewritten in the XML format.

HO = Healthcare OperatorIdP = Identity Provider

NAF = Network Application FunctionPatient = Patient with a Mobile DeviceIMPI = IP Multimedia Private Identity

3.1.1. Authentication Phase

1. The patient requests to access the health servicesfrom the HO / IdP attaching his/her IMPI num-ber with the request.

2. If the patient has not been authenticated at thisstage, the HO / IdP sends a request to the patientto initiate the Bootstrapping Procedure (BSP).

3. The patient initiates the BSP at the BSF and ob-tains the B-TID which is a string of base 64 ran-dom data and the BSF server domain name. TheBSF also generates and sends the key material(Ks) for the secure communication between theHO / IdP and the patient.

4. The patient starts the login procedure by forward-ing the B-TID to the HO / IdP.

5. The HO / IdP sends the B-TID to the BSF andobtains the relevant Ks belongs to the B-TID.

6. The HO/ IdP generates a random number andsends that to the patient. The random number isused to challenges the patients ownership to theKs.

7. Once the patient receives the random number, theChallenge Response is generated and sent to theHO / IdP. The Challenge Response is a functionof the random number and the Ks.

8. If the Challenge Response is successful HO / IdPgenerates and sends the User Token (UT) to thepatient, unless it repeats step 6. The content ofthe UT is encrypted from the Ks.

3.1.2. Service Access to Healthcare Service

1. Once the UT is received, patient can access serviceproviders who are registered under the HealthcareOperator. The patient requests the access to a ser-vice provider (SP) from the HO / IdP attachingthe SP identity (SPID) and the UT with the re-quest.

2. The patient receives the Service Provider User To-ken (SPUT) and the temporary session key (tsK)as the response and the response message is en-crypted using the Ks. The SPUT is concatenatedwith SPID, tsK, time stamp (TS) and the patientsidentification at HO / IdP. This token is digitallysigned by the HO / IdP and encrypted using thepublic key of the SP.

3. The patient sends the SPUT to the SP and initi-ates the service.

4. If the SPUT is extracted successfully by the SP, itconfirms to the patient unless a failure message issent and the patient should request a new SPUTfrom the HO / IdP.

5. After obtaining the successful confirmation, pa-tient sends the service request to the SP alongwith the required data. The data is embedded tothe message in the XML format and the messageis encrypted using the tsK.

3.1.3. Service Access to Healthcare ServiceThe Healthcare Service (HS) maintains a single XML

document for each patient’s request and it contains re-quests and information for many stakeholders. The in-formation access control levels should be maintainedfor the data in the XML document since the same doc-ument is transferred between different user levels con-catenating all the information. XML document con-tains separate XML elements for different user levelsand each XML element is encrypted using the user’spublic key. However the information in certain XMLelements may be referred by more than one user levelin the system. Therefore advanced XML Encryptionfeatures such as partial encryption and multiple en-cryption are used to implement the information ac-cess control. During the XML document manipulationstakeholders may append information to the documentand that information should be authenticated using theXML Signature of the stakeholder. The HS generatesseparate key pairs for each user in the system, savesa copy in the HS and installs it in the user’s applica-tion device. It also provides an XML Key Managementservice to process the key information related with theXML Signature and the XML Encryption.

1. The patient initiates the access with the HS andsends the service request XML. The request mes-sage is encrypted using tsK between the HS andthe patient. The service request XML is concate-nated with the request type, the request receivingparty, the patients information and the health in-formation. Let us assume the patient requests amedication from a doctor by sending the health

information. So the HS receives the message con-taining the request type as medication and the re-ceiving party as the doctor. Then the HS identi-fies that the health information is for the doctorbut the patients information should be sent to thehealthcare administrator. Since the HS manipu-lates the same XML document to all the user lev-els, both parties are looking into the same XMLdocument but the health information should notbe visible to the administrator to protect the pa-tients privacy as well as the administrative infor-mation should not be visible to the doctor. There-fore the XML element that contains health infor-mation in the document is encrypted using thedoctors public key and the administrative informa-tion is encrypted using the administrators publickey. Before the encryption both XML elements aredigitally signed by the HS private key for the au-thentication and finally it is forwarded to the doc-tor for the medication process.

2. Once doctor receives the XML document, he/shedecrypts the XML data elements which are en-crypted using his/her public key and verifies theXML signature for the authentication. Howeverthe doctor is unable to access the administrativeinformation that is concatenated in the same XMLdocument.

3. Let us assume doctor requires some laboratory re-sults based on the health information. He/she ap-pends a new XML element to the document thatincludes the health data readings of the patient.The new XML element should only be extractedby the laboratory. Therefore the doctor signs theXML element for the authentication and encryptsit using the public key of the lab.

4. Once the XML document is received by the lab, itdecrypts the XML element using the private keyof the lab and verifies the sender from the signa-ture. The laboratory results are embedded to theXML document, signed by the private key of thelab and then encrypted using the doctors publickey.

5. The doctor receives the XML document, decryptsthe XML data element that was appended by thelab, verifies the labs XML signature and extractsthe laboratory results. Then the doctor embedsnew XML elements to the document such as listedbelow and each XML element includes instructionsand information to a specific user levels.(a) An XML element to the nurse is signed by

the doctor and it is encrypted using the pub-lic key of the nurse.

(b) An XML element to the pharmacy is signedby the doctor and it is using the public keyof the pharmacy.

(c) An XML element to the patient is signed bythe doctor and it is encrypted using the HSpublic key.

Once all the XML elements are appended success-fully the document is forwarded to the nurse.

6. The nurse is allowed to view only the XML el-ements that are encrypted using his/her publickey. The XML signature of the element is veri-fied for the authentication of the message. Nursemay include new XML message elements in to theXML document for different users signing each ele-ment separately using his/her own private key andencrypted using public keys of the respective re-ceivers. If the message is for the patient then it isencrypted using the HS public key.

7. Once the XML document is received by the phar-macy it decrypts the XML messages that are ap-pended by the doctor and the nurse about med-ications and also it may append an XML messageto the administrator applying the digital signatureand also encrypting the message.

8. The XML document is finally received by the ad-ministrator of the HS. Administrator extracts thepatients information that was appended by the HSand the other XML elements that are encryptedusing the administrators public key.

9. Administrator embeds invoicing and other admin-istrative information of the patient into the XMLdocument, signs it using his/her private key andencrypts using the HS public key. Then the XMLdocument is sent to the HS.

10. Once the document is received by the HS it de-crypts all the XML messages that are encryptedusing its own public key and verifies the senderswith XML signatures. These messages containmedication information to the patient; thereforethe HS appends all the decrypted XML data el-ements into the messages, encrypts the completemessage using the tsK and sends it to the patient.

11. Once the patient receives the message, he/she de-crypts it using the tsK and views the medicationinformation in the XML document. Each XML el-ement consists the XML signature of the sender.Therefore patient can verify signatures using theXML key management feature in the HS.

The same XML document is utilized to send in-formation to the Insurance Providers, Private Medical

Centres and other service providers who are interestedon the patient’s health situation. The HS appends in-formation required for those parties in to the XML doc-ument, signs the information using HS private key andencrypts it using the receiver’s public key. As an exam-ple, patient may send the same XML document to theInsurance provider to claim the medical insurance. In-surance provider will only be able to retrieve the in-voice data from the document but not the patient’shealth information.

4. Conclusion

As the number of ageing population increases thereis an increasing pressure on the national and interna-tional heath care communities to find alternative healthcare solutions to keep the quality of life of these peo-ple at the same levels as before. Due to the increasingusage of mobile handsets by all ages and the function-ality and additional features that are available in to-day’s handsets has made the delivery of health caredata possible using the mobile technology. However, asthe health care data is sensitive it has to be protectedagainst hackers and intruders. In this paper the authorshave shown that by using the XML cryptographic tech-nologies and role based authorization the electronic pa-tient data can be secure and protected against the ma-licious users.

References

[1] XML Key Management Specification (XKMS).Technical report, W3C, March 2001.http://www.w3.org/TR/xkms/.

[2] Canonical XML Version 1.0. Technical report, W3C,March 2002. http://www.w3.org/TR/xml-c14n/.

[3] Exclusive XML Canonicalization Version 1.0. Technicalreport, W3C, July 2002. htttp://www.w3.org/TR/xml-exc-c14n/.

[4] Extensible Markup Language (XML) 1.0 (Third Edi-tion). Technical report, W3C, February 2002. W3C Rec-ommendation.

[5] XML Encryption Syntax and Processing.Technical report, W3C, December 2002.http://www.w3.org/TR/xmlenc-core/.

[6] XML-Signature Syntax and Processing.Technical report, W3C, February 2002.http://www.w3.org/TR/xmldsig-core/.

[7] Phillip M, Hallam-Baker, and Warwick Ford. XML KeyManagement Specification (XKMS). VeriSign Inc.

[8] John A. MacDonald, Kalid Elmufti, and Dasun Weeras-inghe. A Web Services Shopping Mall for Mobile Users.July 2006. The 4th IEEE European Conference on WebServices, Submitted.

[9] Koji Miyauchi. XML Signature/Encrption - the Basis ofWeb Services Security. NEC Journal of Advanced Tech-nology, Vol.2, No.1, Winter 2005.

A. XML Encryption

XML Data to be encrypted

<?xml version="1.0" encoding="utf-8"?><HealthInfo>

<Name>Ian Daneal</Name><Bloodpressure>132</Bloodpressure>

</HealthInfo>

Encrypted XML Data

<?xml version="1.0" encoding="utf-8"?> <HealthInfo><Name>Ian Denley</Name><EncryptedData

Type="http://www.w3.org/2001/04/xmlenc#Element"xmlns:xenc="http://www.w3.org/2001/04/xmlenc#"><EncryptionMethod

Algorithm="http://www.w3.org/2001/04/xmlenc#tripledes-cbc"/><ds:KeyInfo xmlns:ds="http://www.w3.org/2000/09/xmldsig#">

<ds:KeyName>Ian Denley</ds:KeyName></ds:KeyInfo><CipherData>

<CipherValue>DEADBEEF</CipherValue></CipherData>

</EncryptedData></HealthInfo>

B. XML Signature

<?xml version="1.0" encoding="utf-8"?> <HealthInfo> <Name>IanDenley</Name> <Bloodpressureid="bloodpreesureReading">132</Bloodpressure> </HealthInfo><Signature xmlns="http://www.w3.org/2000/09/xmldsig#">

<SignedInfo><CanonicalizationMethod

Algorithm="http://www.w3.org/TR/2001/REC-xml-c14n-20010315"/><SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#dsa-sha1"/><Reference URI="#bloodpreesureReading">

<Transforms><TransformAlgorithm="http://www.w3.org/TR/2001/REC-xml-c14n-20010315"/>

</Transforms><DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/><DigestValue>j6lwx3rvEPO0vKtMup4NbeVu8nk=</DigestValue>

</Reference></SignedInfo><SignatureValue>MC0CFFrVLtRlk=...</SignatureValue><KeyInfo>

<KeyValue><DSAKeyValue>

<P>dsr23DS32fd</P><Q>jkd55ss65</Q><G>hdf87aaHF</G><Y>dfa4Jsw83</Y>

</DSAKeyValue></KeyValue>

</KeyInfo></Signature>