Privacy Preserving EHR System Using Attribute-basedInfrastructure

Shivaramakrishnan Narayan, Martin Gagné and Reihaneh Safavi-NainiDepartment of Computer Science

University of Calgary, Alberta, Canada{snarayan,mgagne,rei}@ucalgary.ca

ABSTRACTSecure management of Electronic Health Records (EHR) ina distributed computing environment such as cloud comput-ing where computing resources including storage is providedby a third party service provider is a challenging task. In thispaper, we explore techniques which guarantees security andprivacy of medical data stored in the cloud. We show hownew primitives in attribute-based cryptography can be usedto construct a secure and privacy-preserving EHR systemthat enables patients to share their data among healthcareproviders in a flexible, dynamic and scalable manner.

Categories and Subject DescriptorsE.3 [Data Encryption]: Public Key Cryptosystem

General TermsAlgorithms, Design, Security

KeywordsCloud Computing, Attribute-based Cryptography, PEKS,Electronic Health Record System, Ciphertext Policy, Pri-vacy

1. INTRODUCTIONAn electronic health record is a collection of patients’

health related information to allow efficient, consistent anduniversal sharing of health information. Because of the sen-sitivity of health related information, providing secure stor-age and access to EHR is the main challenge in today’s EHRsystems. Patients’ privacy has been recognized in law, andprivacy law such as the health insurance portability and ac-countability act (HIPAA) [1] privacy and security rules, andpersonal information protection and electronic documentsact for health data [2] are aimed at ensuring sufficient careis given to handling such data.

An increasingly popular approach in managing health dataputs users at the centre of such systems and allows users

Permission to make digital or hard copies of all or part of this work forpersonal or classroom use is granted without fee provided that copies arenot made or distributed for profit or commercial advantage and that copiesbear this notice and the full citation on the first page. To copy otherwise, torepublish, to post on servers or to redistribute to lists, requires prior specificpermission and/or a fee.CCSW’10, October 8, 2010, Chicago, Illinois, USA.Copyright 2010 ACM 978-1-4503-0089-6/10/10...$10.00.

to store and manage access to their own health informa-tion. Patient-centric EHR systems enable patients to selec-tively give access to their health data to healthcare providersand other. Following the electronic health record system ofSzolovits et al. [15], numerous patient-centric EHR such asIndivo [12], Google Health [8] and Microsoft Healthvault [13]have been proposed.

Cloud computing makes on-demand computing resourcesa reality and provides the required computing infrastructurefor storage of EHR. However, a cloud environment intro-duces an even greater risk to security and privacy of sen-sitive data. Data stored in cloud may reside on computersthat are located in dispersed geographic locations and canbe seen by many in transit and in their stored form.

In this paper, we consider a secure design for a patient-centric EHR management system where data is saved in astorage provided by a cloud provider. We assume the cloudprovides a reliable storage for data but the stored data canbe seen (and copied) by the cloud provider. This means thatit is the responsibility of the user to provide mechanisms thatensure security and privacy of their information. Users storetheir data in encrypted form in the cloud and grant accessto portion of the data in accordance with the requesters’identity information. The storage provider will not be ableto see data, or associated metadata, therefore confidential-ity and privacy of data will be guaranteed. The scheme pre-sented can also be applied to other general security-sensitivedatabase applications.

1.1 Our proposalUsers of the system are patients and healthcare providers

(e.g. doctors, laboratories, pharmacist).We require the EHR system to guarantee:- confidentiality of health data in storage and transit.

By confidentiality we mean the cloud provider or anadversary will not be able to read patients’ files.

- privacy of data. By privacy, we mean that the cloudprovider will not be able to infer information about thefile’s content other than what is revealed through thefile size, attributes, the identity of the requester, andthe sequence of operations on the EHR.

The centrepiece of our design is the use of attribute-basedencryption (ABE) [14]. An ABE system is a public keyencryption system in which each user’s key is labeled witha set of attributes and the ciphertext is associated with anaccess policy. The secret key of a user (the key is attachedwith an attribute set) can decrypt a particular ciphertextonly if the attribute set of the user’s key satisfies the ac-cess policy associated with the ciphertext. Such an ABE is

47

known as ciphertext-policy ABE (cp-ABE) [5]. Recently,the use of attribute-based cryptography to provide securecloud storage was also considered in [9].

The solution we propose is based on the following assump-tions:

- There is a trusted authority (TA) who generates keysfor users of the system. There is also a public directorythat is used by the TA to publish the system publicvalues (such as public keys) and parameters that areneeded for cryptographic operations.

- A user is associated with (i) a unique identifier (ID),and (ii) a set of attributes (ω).Each user has a public key and a private key. Theprivate key is generated and issued by the TA afterverifying the user’s attributes.

- The health record database is hosted on a cloud stor-age. The cloud server is trusted for performing the re-quested operation but should not be able to do otherunspecified operations such as reading patients’ data.Therefore the health information on the storage mustbe kept in secured form.

An EHR can be seen as a directory of files stored in sub-folders. We assume an electronic health record has the fol-lowing structure:

- (i) patients’ health data in the form of files (in en-crypted form), (ii) a table consisting of entries corre-sponding to the files.

- an entry for a file X in the table contains the following:

(a) Meta data describing the file and its location, allin encrypted form. This data contains the follow-ing information and is encrypted using the broad-cast ciphertext-policy attribute-based encryption.

i. file description outlining the file content;

ii. a random locator-tag that is used as a labelfor the file. This label is the file name usedby the cloud server to find locate the file.

iii. a symmetric key used to encrypt the healthdata.

(b) an access policy in plain text form, which specifieswho can decrypt the encrypted data of both theentry and file. The access policy is not encrypted.

(c) a search-index (SI) for keywords within the en-crypted file used for keyword search. The search-index is the encryption of the keyword.

A user that satisfies the access policy of a file, can decryptthe meta data entry associated with the file, find the locationof the file and also a key to decrypt the file. The user submitsthe locator tag to the system to obtain the encrypted file anduses the key to decrypt it.

The system allows the users to share their health datawith healthcare providers selectively by encrypting the datausing the attributes of the healthcare providers. Note thatthe actual data is encrypted using efficient symmetric keycryptography, and the attribute-based encryption is used formaking the symmetric keys accessible to authorized users.We use a variation of ABE known as broadcast ciphertext-policy attribute-based encryption (bABE). A bABE systemhas the same functionality as ABE in making a plaintextaccessible to users that satisfy the policy attached to theciphertext, together with the added functionality of user re-vocation: that is users’ keys can be revoked. The EHR

system works as follows:- Store File: A patient storing a new file with locator-taglocF would perform Store〈F 〉. The file stored on the serverhas two parts: (〈F 〉, 〈EntryF 〉), where

〈F 〉 := EncK(DataF),

〈EntryF 〉 := (bABE((DescF , K, locF ), A0), A0, SI),

where A0 is an access policy that only allows the patient todecrypt the file.- Set Access: A patient granting access to 〈F 〉 to a health-care provider UB performs Grant〈F, UB〉. This creates anew policy A1 which grants access to UB in addition to theexisting rules in the current policy of F , and updates theentry of F to:

〈EntryF 〉 := (bABE((DescF , K, locF ), A1), A1, SI).

Note that this can be done without re-encrypting the wholeciphertext.- Revoke Access: A patient removing the access of thehealthcare provider UB to the encrypted file F would per-form Revoke〈UB , F 〉. This creates a new policy A

′

1 whichdoes not allow access to UB , but maintains all other rules ofthe current policy, and updates the entry of F to:

〈EntryF 〉 := (bABE((DescF , K, locF ), A′

1), A′

1, SI).

- Delegate: A healthcare provider UB with attribute set ωB

can create a private key for a subset ωC ⊆ ωB for healthcareprovider UC using Delegate〈ωB , ωC〉. This creates a privatekey for ωC .- Keyword Search: A patient can provide searchability oftheir records for a search term to a healthcare provider, byproviding them with a search key. The healthcare providerUB will then be able to search the EHR of UA for a keywordw. The search is performed by the cloud provider on theencrypted data such that the cloud provider learns nothingabout w.

The EHR system provides the following functionalities:Adding User-access: The system allows a patient to addhealth care providers attributes to provide access to the pa-tient’s health data.Revoking User-access: The system allows a patient torevoke a health care provider’s access to the patient’s healthdata without having to re-encrypt the data.Access Delegation: The system provides health care providersthe ability to delegate access by generating the private keyfor any subset of attributes they hold.Keyword Search: The system allows the health care providersto search a patient’s record based on a keyword such that thecloud server learns nothing about the keyword. The serverreturns the entries that match the query.

In addition, the EHR must provide security and privacyto the users, meaning:Security: The system guarantees the confidentiality of healthdata even if the data server is compromised. Data is alwaysin encrypted form and only users who are authorized by thepatient can decrypt the EHR data.Privacy: The system ensures that the cloud server will notlearn anything about the file content from the ciphertextsor the keyword searches, other than what is leaked by thesize of the files and inferences based on the identity andattributes of the requester.

48

1.2 Related WorkThe concept of patient-centered health information sys-

tems was initially introduced by Szolovits et al., in 1994[15]. In their work, the authors proposed an individual-based health information system which integrates all health-related information about an individual. Following theirwork, a patient-centric health record management systemnamed Indivo [12] was proposed. This web-based systemenables a patient to assemble, maintain and manage a se-cure copy of his or her medical record. The security of thehealth record is based on policies set by the users, and usingencryption where the data is encrypted such that only thetrusted Indivo server which has access to the private keys candecrypt the data before sending it to the users. Recently, Mi-crosoft [13] and Google [8] introduced their patient-centricweb-based electronic health record system. These systemsallow patients to maintain a copy of their health record, ac-cess the health data whenever needed, and share the datawith other users based on the access policies set by the pa-tient.

Many EHR systems use cryptographic protocols to pro-vide security and privacy. In [7], Hu at al. proposed the useof public key infrastructure (PKI) for privacy and securityof EHR. They use PKI for mutual authentication and dis-tribution of health data, and use of symmetric encryptionto preserve the confidentiality of the health data. However,in their system, the trust and security management is del-egated to the medical provider much like in a paper-basedEHR. In [16] Yu and Chekhanovoskiy presented a patient-centric medical content protection system based on the useof tamper resistant hardware and cryptographic protocolsfor authentication and encryption of the health data. Thedrawback of their system is the use of dedicated hardwaredevice for EHR content protection by the users, further theauthors do not provide the security analysis of the proposedsolution. In [10], a cryptographic key management approachto provide security and privacy of EHR was proposed. Thesolution was based on smartcard technology which requiresthe users of the EHR system to have a dedicated smartcard.

Recently, Benaloh et al. proposed an EHR using patient-controlled encryption [4]. Their work is closest to ours.They use hierarchical identity-based encryption (HIBE) andsearchable encryption to construct a privacy-preserving EHRsystem. The Benaloh et al., EHR system provides the advan-tage of implementing the EHR system over any third partystorage device (such as cloud storage). The drawbacks oftheir proposed solution however are the need to create andmanage multiple keys by patients and healthcare providers,the absence of an efficient user revocation mechanism, theneed for an external key escrow agent, and the need for pa-tients to verify the healthcare provider’s credentials.

In our system, the key management problem is solved byusing users’ attributes to encrypt the data. As a result, ev-ery user has only one private key corresponding to their at-tribute set which is used to decrypt the entry which in turnprovides access to the encrypted files. The credentials ofhealthcare providers are verified only by the trusted author-ity when keys are generated, and the TA can also be used asan escrow agent in emergencies. We use a more secure andmore flexible protocol to provide the keyword search func-tionality. Finally, the use of broadcast ABE allows patientto revoke access to healthcare providers.

2. PRELIMINARIES

2.1 Health Record StructureA patient’s health record is composed of various health

data pertaining to different areas such as dentistry, cardi-ology, dermatology, mental health, physical data summary,etc. The data in each area can be of different types such as aSOAP (subjective, objective, assessment, and plan) note fora medical condition, consultation report, lab reports such asx-ray, ultrasound and blood test, discharge summaries, andoperative reports. Contrary to [4], where the access policieswere determined by the nature of the data contained in thefiles, we set our access policies based on the attributes of theusers who are allowed access.

A patient may want to share his record to a doctor butmay not want to allow others (e.g. pharmacist) to read anymore information than strictly necessary. Therefore, we pro-pose a system in which a patient can grant access to specificportions of his health data. Initially, the patient’s data isencrypted with access to patient only. Granting user accessto the already encrypted data would involve addition of therelevant attributes to the ciphertext. For example, if a pa-tient wants a pharmacist to access his medical prescription,the patient adds the type-identifier pharmacy, and pharma-cist attributes such as pharmacy-id and pharmacy-locationto the medical prescription ciphertext.

2.2 User AttributesThe user/subject attributes consists of type-identifier (e.g.

patient, doctor, pharmacy), and attributes that defines theidentity and characteristics of the subject such as name, ID,location, specialization, etc. In the proposed EHR system,the patient decides on who can access his health data andthereby determines the attribute set under which the re-source is encrypted.

2.3 Access PoliciesThe access policies for our system consist of monotone

boolean formulas on the attributes – that is, boolean for-mulas that use only the logical ‘or’ and logical ‘and’ gates.For example, the policy ‘doctor ∧ ID1234’ states that onlya user who possess the attributes doctor and ID1234 is al-lowed access. Since our system assumes the existence of atrusted key generator who verifies the user attributes beforeissuing private keys, the patient can ensure that his file canbe accessed by user 1234 only if he is a doctor by setting theaccess policy above.

2.4 Attribute-based CryptographyAttribute-based encryption (ABE) was introduced in 2005

by Sahai and Waters as an extension of their work calledfuzzy identity-based encryption [14]. Attribute-based sys-tems allow security functionalities to be provided based on‘attributes’ of users and objects, and not their individualidentities (though, individual identities can still be used asone of the attributes).

Our EHR system uses an adaptive chosen ciphertext (CCA-2) secure broadcast ciphertext-policy attribute-based encryp-tion [3]. This scheme is secure in so called selective attributemodel; but recent developments in ABE [11] indicate thatadaptively secure broadcast schemes will soon be available.Broadcast ciphertext-policy attribute-based encryption en-ables us to achieve direct revocation of user access to a data

49

without having to re-encrypt the data or refreshing the sys-tem parameters. A patient allows access to the data byadding the subject’s type-identifier, subject-ID and othernecessary subject attributes, based on the required access-policy the patient seeks. The ciphertext contains an indexset consisting of the unique subject-ID and if the subject-IDof the receiver is not in the index set he cannot decrypt thedata although he holds other attributes.

A broadcast ciphertext-policy attribute-based encryptionscheme consists of four algorithms namely Setup, Extract,Encrypt and Decrypt, and an optional algorithm Delegate.bABE-Setup(1λ): Given a security parameter 1λ, the al-gorithm outputs the system public key params and mastersecret key msk. The global system parameters params is aset of public information.bABE-Ext(params, msk, ω, ID): Given an attribute setω, user-index ID, public key params, and the master keymsk as input, the algorithm outputs the private key skID,ω

corresponding to ω.bABE-Enc(params,M, S, A): Given a message M , publickey params, user-index set S and an access structure A, theencrypt algorithm produces the ciphertext C containing theencrypted message.bABE-Dec(params,C, skID,ωr): The decrypt algorithmtakes as input the ciphertext C and the private key skID,ωr

for the receiver attribute set ωr. It decrypts the encryptedmessage if ωr ∈ A and ID ∈ S, if successful it returns themessage M , else returns ⊥.bABE-Del(params, skx,y, (x′, y′)): The delegate algorithmtakes as input a private key skx,y and a new set (x′, y′). Itoutputs the private key skx′,y′ for any y′ ⊆ y and for anyx′ ∈ U , where U is the user-index universe.Advantages: A CCA-2 secure broadcast ciphertext-policyencryption ensures both confidentiality of the health data.This property follows directly from the security propertyof the encryption scheme. The broadcast ciphertext-policyattribute-based encryption also provides direct revocationcapability which in turn provides the user revocation func-tionality of the proposed EHR system. The delegate algo-rithm of the encryption scheme is used to provide the accessdelegation functionality.

2.5 Keyword Search over Encrypted DataWe provide the keyword search functionality using a prim-

itive called Secure Channel Free Public-Key Encryption withKeyword Search (PEKS) [6]. This scheme enables usersto perform private searches for matching keywords over en-crypted data without revealing the keywords or partial matchesto the server.

A PEKS consists of the following algorithms:PEKS-KGP (1λ): Given a security parameter 1λ, the algo-rithm outputs the system common parameter cp.PEKS-KGS(cp): Taking a common parameter cp as in-put, this algorithm generates a private and public key pair(skS , pkS) of the server.PEKS-KGR(cp): Taking a common parameter cp as in-put, this algorithm generates a private and public key pair(skR, pkR) of the receiver.PEKS(cp, pkS , pkR, w): Taking a common parameter cp, aserver’s public key pkS , a receiver’s public key pkR and akeyword w as input, this algorithm returns a ScfPEKS ci-phertext Sw which is a searchable encryption of w.PEKS-Td(cp, skR, w): Given a common parameter cp, re-

ceiver’s secret key skR and a keyword w, the algorithm com-putes a trapdoor Tw for w.PEKS-Test(cp, Sw, Tw, skS): The Test algorithm takes asinput a common parameter cp, ciphertext Sw, trapdoor Tω′ ,and server’s secret key skS . It outputs 1 if successful, else itoutputs 0.Advantages: The PEKS provides the keyword search func-tionality of the EHR system such that the server does notlearn anything about the keyword on which the search isperformed. This is because the server performs the Testfunction which takes as input the common parameter, ci-phertext, trapdoor and server’s secret key, none of thesereveal any information about the keyword.

3. BUILDING A PATIENT-CENTRIC EHRSYSTEM

In this section we outline the algorithms needed to con-struct a patient-centric EHR (PEHR) system satisfying theproperties mentioned in Section 1.

We use a CCA2-secure broadcast attribute-based encryp-tion to maintain the confidentiality of the health records.The key idea is to allow a patient encrypt his medical recordsunder the health care provider’s attributes such that onlythose who satisfy the access policy set by the patient areable to decrypt the encrypted records. The authenticity ofhealth care providers are verified by a trusted key genera-tion authority who upon successful verification of attributesissues them the private key. We assume that all the usersof the system trust the key generation authority. A user isallowed to delegate access to others by issuing a private keyfor a subset of the user’s attributes. Further, each user hasa user-index which is used to provide direct revocation ofuser access to an encrypted data. The encryption scheme ofour PEHR system consists of algorithms:PEHR-KG(1λ): Run bABE-Setup(1λ) to obtain the sys-tem public parameter params and the master secret msk

which is kept secret by the trusted key generation authority.PEHR-Ext(ω, ID): Run bABE-Ext(params, msk, ω, ID)and output the private key skID,ω.EncK(M): Perform a symmetric encryption of M using thekey K.bABE(M, A): Run bABE-Enc(params,M, S, A), and out-put the resulting ciphertext C.DecskID,ω

(C): Run bABE-Dec(params,C, skID,ω), andoutput the resulting message M .DecK(): Perform a symmetric decryption using the key K.Delegate(x′, y′): Run bABE-Del(params, skx,y, (x′, y′))and return the secret key skx′,y′ .

3.1 Adding SearchabilityTo provide keyword search within a health record, we

combine the attribute-based broadcast encryption with asearchable encryption scheme. For this, we propose the useof secure channel-free public key encryption with keywordsearch [6]. The main idea is when a medical document is up-loaded, each keyword pertaining to the uploaded documentis encrypted using the PEKS scheme, and the encryptedkeyword known as search-index is stored in the entry cor-responding to the encrypted document. The owner of thedecryption key can generate a trapdoor key for a particularkeyword which will allow the server to test whether a partic-ular search-index is a match without knowing the keyword.

50

In our system, the patient generates and issues a public en-cryption key and private decryption key to the health careproviders, thus enabling the health care providers to gener-ate the trapdoor key. The searchable encryption scheme isas follows:Srch-KGen(1λ): Run bABE-Setup(1λ) to obtain thecommon parameter cp. Let msk be the master secret ofthe system known only to the trusted key generation au-thority.Srch-SGen(): Run PEKS-KGS(cp) to obtain the publicand private key pair (pkS , skS) of the server. This is runby the trusted key generator who creates the key pair usingthe common parameter and the master secret key msk. Thepublic key of the server pkS is added to the search commonparameter cp which is made public to all users.Srch-RGen(): Run PEKS-KGR(cp) to generate a privateand public key pair (skR, pkR) of the receiver. This is doneby the patients who generate and issue the key pair to thehealth care providers. The health care providers can searchfor keywords if the search-index is produced using the publickey pkR issued by the patient.Srch-IGen(pkR, w): Run PEKS(cp, pkS , pkR, w) and out-put a PEKS ciphertext Sw which is a search index for thekeyword w.Srch-Td(skR, w): Run PEKS-Td(cp, skR, w) and outputa trapdoor Tw for the keyword w.Search(Tw): Run PEKS-Test(cp, S, Tw, skS) and output1 if successful, else output 0.

3.2 AnalysisThe proposed scheme has the following advantages com-

pared to the Benaloh et. al, scheme of [4].Efficient Key Management. Benaloh et. al’s scheme

requires the patient to send a large number of keys to health-care providers. In our scheme, the decryption of the medicaldata relies on the private key of the health care providers.Here, the patients encrypt the data under the attributes ofthe health care providers, thus the patients need not gener-ate and issue keys unlike in [4] thus reducing the communi-cation cost.

Further, each time a health provider accesses a patient’srecord, the health provider needs to fetch the subkey whichinvolves decrypt operation in order to decrypt the entriesand the encrypted file. In our scheme, access to a patient’srecord does not require the health care provider to fetch asubkey.

Our scheme has a slightly higher computational cost forthe patients due to re-encryption of records when updatingaccess policies, but this is largely offset by the reduction incommunication.

Direct Revocation. In our scheme a patient can revokethe access of a health care provider without having to refreshthe public parameter or re-encrypt the health data. This isachieved using the ID of the health care provider whoseaccess needs to be revoked. Direct revocation of access isnot addressed in [4].

Key Escrow. In [4], the patients have to set up an ex-ternal key escrow service or informally share the keys to thefamily in order to be able to access the health record in caseof emergency. Our scheme naturally supports key escrowdue to the presence of a trusted key generation authoritywho is able to generate private keys to access a patient’shealth record in case of emergency. A downside of this ap-

proach is that the trusted key generator has the capabilityto access all encrypted files.

Usability. Benaloh et. al’s scheme requires the patientsto verify the health provider credentials before issuing thekeys. In our scheme, the private keys are issued by a trustedkey generator who verifies the health provider attributes be-fore issuing the private key.

4. PRIVACY PRESERVING EHR IN PRAC-TICE

We now describe the interactions between, a doctor, apatient, and the health record database which stores thepatient’s health record.

Setup: The user (both patient and doctor) connects tothe web server and generates an account username and pass-word which will be used to authenticate the user to the serverfor logging in to the system. Once a user has registered forthe service, he downloads a client application which will runlocally on his machine. Once this client application is in-stalled, the user requests the private key corresponding tohis attribute set from the trusted authority.

A patient then sets up his health record by importing themedical data, encrypting each file with a different symmet-ric key and storing the encrypted files in the cloud storage.Along with each encrypted file, the patient uploads a cor-responding entry consisting of encrypted meta-data, accesspolicy and search-index.

Note that at the end of every session, both on the patient’sand doctor’s end, the client application clears all the data -keys and decrypted materials - used during the session.

Initiating a Contact: Prior to a medical appointment,both the patient and the doctor need to exchange their user-name. To view the patient’s record, the doctor sends a re-quest for access to the health data of the patient. The re-quest message is sent to the patient by encrypting it underthe patient’s public key which is downloaded by the clientapplication given the patient’s username.

The patient provides access to his health data by retriev-ing the entries corresponding to the requested files. He thenupdates the policy of the entries thereby enabling the doc-tor to access the corresponding files. Finally the patientsends an encrypted message to the doctor confirming thatthe access has been granted.

Accessing Health Record: After being granted accessby the patient, the doctor makes an access request to theserver on the patient’s record. First, the doctor’s client soft-ware retrieves the encrypted entries and decrypts them usingthe doctor’s private key to access the file information andlocator tags. The doctor then sends the locator tags of thecorresponding files he wants to access to the server, whichthen returns the encrypted files. This encrypted file is de-crypted at the client side and is available for reading.

Post Appointment: Update Health Record: If thedoctor wants to update files or upload new data, the doc-tor sends to the patient the authenticated medical data fileencrypted under the public key of the patient. In case ofa fresh upload, the patient decrypts the message containingthe authenticated medical data and creates a new encryptedfile and a corresponding entry such that only the patient andthe doctor are given access. For an update, the patient en-crypts the file with a new key and updates the correspondingentry while preserving the existing access policy.

51

5. EHR SECURITYOur proposal ensures the confidentiality of health data

by the means of using strong encryption primitive. In thiscase, we use adaptive chosen ciphertext secure broadcastciphertext-policy attribute-based encryption and public-keysearchable encryption. This implies if the health recorddatabase is compromised the adversary learns nothing aboutthe health data contained in the server without the relevantprivate keys. Since the system requires a trusted authorityto issue the keys, the security of the system relies on thetrust and reliability of the authority.

The security of the keys are handled by the direct revo-cation capability of the system. If a patient believes thata health provider is not trustworthy the user can directlyrevoke the access instead of refreshing the system public pa-rameters. Since updated files are encrypted using new keys,a revoked provider having access to locator-tag and previ-ous key cannot read the new file. Further, to ensure thedata written is authenticated, we assume that the healthproviders use attribute-based signing of the data.

The security of the proposed system is based on the fol-lowing assumptions:⋄ The trusted authority only issues the private key on thesuccessful verification of user attributes.⋄ The private key is communicated to the users over a securelink such as SSL thereby preventing eavesdropper to learnanything about the key.⋄ After each session, the client application deletes all thedata used during this session. This ensures an adversarycannot retrieve any data from the machine’s temporary stor-age location.⋄ Trusted authority overrides the access to a patient’s recordonly during the case of emergency.

6. CONCLUSION AND FUTURE WORKAttribute-based cryptographic primitives provides flexible

policies which can be used to build secure infrastructure fordesigning privacy preserving electronic health record sys-tem. In this paper, we presented a proposal which com-bines attribute-based cryptography and public-key encryp-tion with keyword search to provide privacy preserving elec-tronic health record management system.

We plan to develop a prototype of the proposed EHR sys-tem using Indivo [12], an open source software developed forpatient-centric health record management. We also intendto extend our proposed solution to support multiple author-ities to reduce the trust requirement in the key generators.

7. ACKNOWLEDGEMENTSThis research was funded in part by Alberta Innovates -

Technology Futures, Alberta, Canada. The authors wouldlike to thank the reviewers of ACM CCSW 2010 for provid-ing helpful comments and suggestions.

8. REFERENCES[1] Health insurance portability and accountability act of

1996. U.S. Government Printing Office, 1996.

[2] Recommendations for the interpretation andapplication of the personal information protection andelectronic documents act (s.c.2000, c.5) in the healthresearch context. Technical report, CanadianInstitutes of Health Research, November 2001.

[3] N. Attrapadung and H. Imai. Conjunctive broadcastand attribute-based encryption. In Pairing ’09: The3rd International Conference on Pairing-BasedCryptography, volume 5671 of Lecture Notes inComputer Science, pages 248–265. Springer-Verlag,2009.

[4] J. Benaloh, M. Chase, E. Horvitz, and K. Lauter.Patient controlled encryption: Ensuring privacy inmedical health records. In ACM CCSW 2009, 2009.

[5] J. Bethencourt, A. Sahai, and B. Waters.Ciphertext-policy attribute-based encryption. In IEEESymposium on Security and Privacy, 2007, SP ’07,pages 321–334. IEEE Xplore, 2007.

[6] L. Fang, W. Susilo, C. Ge, and J. Wang. A securechannel free public key encryption with keywordsearch scheme without random oracle. In CANS ’09:Proceedings of the 8th International Conference onCryptology and Network Security, pages 248–258.Springer-Verlag, 2009.

[7] J. Hu, H. Chen, and T. Hou. A hybrid public keyinfrastructure solution (HPKI) for HIPAAprivacy/security regulations. Computer Standards andInterfaces, 32(5-6):274–280, 2009.

[8] Google Inc. Google health. https://www.google.com/health/, 2009.

[9] S. Kamara and K. Lauter. Cryptographic cloudstorage. In Financial Cryptography: Workshop onReal-Life Cryptographic Protocols and Standardization- 2010, volume 6052 of Lecture Notes in ComputerScience. Springer-Verlag, 2010.

[10] W. B. lee and C. D. Lee. A cryptographic keymanagement solution for HIPAA privacy/securityregulations. IEEE Transactions on InformationTechnology in Biomedicine, 12:34–41, 2008.

[11] A. Lewko, T. Okamoto, A. Sahai, K. Takashima, andB. Waters. Fully secure functional encryption:Attribute-based encryption and (hierarchical) innerproduct encryption. In Advances inCryptology-EUROCRYPT 2010, volume 6110 ofLecture Notes in Computer Science, pages 62–91.Springer-Verlag, 2010.

[12] K. Mandl, W. Simons, W. Crawford, and J. Abbett.Indivo: a personally controlled health record forhealth information exchange and communication.BMC Medical Informatics and Decision Making,7(1):25, 2007.

[13] Microsoft. Microsoft healthvault. http://www.healthvault.com/personal/ websites-overview.html,2009.

[14] A. Sahai and B. Waters. Fuzzy identity-basedencryption. In Advances in Cryptology-EUROCRYPT2005, volume 3494 of Lecture Notes in ComputerScience, pages 457–473. Springer Berlin/Heidelberg,2005.

[15] P. Szolovits, J. Doyle, W. J. Long, I. Kohane, andS. G. Pauker. Guardian angel: Patient-centered healthinformation systems. Technical report, 1994.

[16] W. D. Yu and M. A. Chekhanovskiy. An electronichealth record content protection system usingsmartcard and PMR. In 9th International Conferenceon e-Health Networking, Application and Services,2007, pages 11–18. IEEE Xplore, 2007.

52