2012 Fourth International Conference on Intelligent Networking and Collaborative Systems
Implementing a Personal Health Record Cloud Platform Using Ciphertext-Policy Attribute-Based Encryption Changji Wang, Xuan Liu, Wentao Li School of Information Science and Technology Guangdong Province Information Security Key Laboratory Sun Yat-sen University, Guangzhou 510275, China Email:
[email protected] their health knowledge. At the same time, PHR systems help clinicians make better treatment decisions by providing more continuous data. PHR systems can also benefit the public health sector by providing health monitoring, outbreak monitoring, empowerment, linking to services, and research. PHR systems can give consumers the potential to play a large role in protecting and promoting the public’s health [1]. Cloud computing is one of the most challenging technological models, which enables convenient, on-demand network access to a shared pool of configurable computing resources (e.g., networks, servers, storage, applications, and services) that can be rapidly provisioned and released with minimal management effort or service provider interaction [2]. According to a report from Gartner [3], there is an acceleration of adoption of cloud computing among enterprises. Gartner predicted that worldwide cloud service revenues would reach 148.8 billion USD by 2014, with large part from the healthcare cloud computing market. National and regional healthcare authorities as well as healthcare service providers have shown great interests, and are already taking first steps towards the deployment of cloud computing. Cloud computing can help healthcare providers focus more on increasing quality of delivered healthcare instead of managing their IT. This is especially important for smaller hospitals, community care and physician practices. Cloud computing simplifies information sharing among various healthcare institutions involved in the care process. Moving the infrastructure and sensitive patient data from hospitals to the cloud can pose severe security and privacy risks. Some information in a PHR is considered private and sensitive. To preserve patients from social embarrassment, prejudice or unfair job opportunities, information such as fertility, emotional and psychological disorders, sexual behaviors or physical abuse etc. should be highly protected. In traditional access control system, sensitive data is often protected by the trusted storage servers whose job it is to mediate access to data. However, users may be unwilling to trust third party cloud storage servers with sensitive data in cloud storage paradigm. To assure the patients’ control over access to their own PHRs, it is a promising method to encrypt the PHRs before outsourcing. Recent proposals on enforcing
Abstract—It is the current trend for healthcare authorities as well as healthcare service providers to deploy cloud computing platform. In this paper, we describe our work on designing and implementing a patient-centric, personal health record cloud platform based on open-source Indivo X system. We adopt ciphertext-policy attribute-based encryption to provide privacy protection and fine-grained access control. Keywords-Personal Health Record; Electronic Medical Record; Access Control; Ciphertext-Policy Attribute-Based Encryption; Indivo X.
I. I NTRODUCTION It is widely accepted that the application of information and communication technologies in the healthcare environment will improve care delivery greatly. It can enhance citizen’s health, but also including well-being and social care. Moreover, it increases subjects’ quality of life and independence as well as reducing rising healthcare costs in an ageing society. Recent trends in healthcare delivery have led to a shift from electronic health record (EHR) systems controlled by healthcare providers to personal health record (PHR) systems controlled by patients themselves. PHR systems allow patients to create, manage and control their PHRs through the Internet, which made it possible to easily access their health data and share their health data to health care providers, insurance practitioners, researchers, family members and friends. The health data on a PHR can be considered as a complete and accurate summary of an individual’s medical history and health status. On one hand, individuals can import their health records which may include medical history, laboratory and imaging results, list of medical problems, medication history from hosptial EHR systems. On the other hand, individuals can also upload health measurements from their devices such as wireless electronic weighing scales or collected passively from a smartphone. PHR systems can serve as an information hub for patients’ health management by helping patients keep track of their personal health information, relate accurate history during clinical encounters, check for drug interactions, and eliminate unnecessary duplication of laboratory tests and diagnostic studies. With PHR systems, patients can have access to a wide range of health information resources, as well as improving 978-0-7695-4808-1/12 $26.00 © 2012 IEEE DOI 10.1109/iNCoS.2012.65
8
access control policies exploit the use of cryptography to enforce access control policies. In such systems, there is no need for a trusted storage servers to check user credentials, and every user can get the encrypted data, but only users who have the right credentials can decrypt the encrypted data [4]. In traditional public key encryption systems or identitybased encryption (IBE) systems [5], encrypted data is targeted for decryption by a single known user who is described by a digital certificate or an identity. Thus traditional public key encryption schemes or IBE schemes will not work for situations when the sender does not know the exact identity of the recipient. For example, if a patient wants to send his PHR data to multiple users, the patient needs to know the digital certificate or the identity for each recipient, and then encrypt the same data many times using each recipient public key or identity. Therefore, we need a crypto scheme which offers a more suitable solution for enforcing access policies based on data recipient attributes instead of the identity of the data recipient. The patient specifies only the attributes the recipient needs to have in order to access patient’s data. To address these emerging needs, Sahai and Waters [6] introduced the concept of attribute-based encryption (ABE). Instead of encrypting to individual users, in ABE system, one can embed an access policy into the ciphertext or decryption key. Besides, ABE also has collusion-resistance property, i.e., if multiple users collude, they should only be able to decrypt a ciphertext if at least one of the users could decrypt it on their own. Thus, data access is self-enforcing from the cryptography, requiring no trusted mediator. ABE can be viewed as an extension of the notion of IBE in which user identity is generalized to a set of descriptive attributes instead of a single string specifying the user identity. Compared with traditional public key encryption and IBE, ABE has significant advantage as it achieves flexible one-tomany encryption instead of one-to-one, it is envisioned as a promising tool for addressing the problem of secure and finegrained data sharing and decentralized access control. There are two types of ABE depending on which of private keys or ciphertexts that access policies are associated with. In key-policy ABE (KP-ABE) system [7][8], users’ keys are issued by the attribute authority captures an access structure that specifies which type of ciphertexts the key can decrypt, while ciphertexts are labeled by the sender with a set of descriptive attributes. KP-ABE may be suitable for structured organizations with rules about who may read particular documents, but it is unable to specify policies on a per-message basis. Other important applications include secure forensic analysis and pay-TV system with package policy (called target broadcast). In ciphertext-policy ABE (CP-ABE) system [9][10], senders can encrypt a message with a specific access policy in terms of access structure over attributes, stating what kind of receivers will be able to decrypt the ciphertext. Users possess sets of attributes and obtain corresponding secret attribute keys from the attribute authority. Such a user can decrypt a ciphertext if his/her attribute satisfies the access policy associated to
the ciphertext. An example application of CP-ABE is secure mailing list system with access policy. Since the concept of ABE is proposed, a lot of research work used ABE to realize fine-grained access control for outsourced data emerged [11]. Especially, there has been an increasing interest in applying ABE to secure EHRs or PHRs [12][18][13][14][15][17]. Ibraimi et.al. [12] applied CPABE to enforce patient/organizational access control policies such that everyone can download the encrypted data but only authorized users from the social domain (e.g. family, friends, or fellow patients) or authorized users from the professional domain (e.g. doctors or nurses) are allowed to decrypt it. Mohan et al. [18] presented the design and initial prototype implementation of an MedVault subsystem for EHR sharing, which covers attribute-based access control and verifiable and selective health information disclosure. Narayan et al. [14] proposed an attribute-based infrastructure for EHR systems, where each patient’s EHR files are encrypted using a broadcast variant of CP-ABE that allows direct revocation. However, the ciphertext length grows linearly with the number of unrevoked users. Akinyele et al. [15] provide a design and implementation of self-protecting electronic medical records (EMRs) using dual-policy attribute-based encryption, which can either be stored on cloud servers or cellphones so that EMR could be accessed when the health provider is offline. Li et al. [17] proposed a patient-centric framework of secure sharing of PHRs in cloud computing. They focus on the multiple data owner scenario, and divide the users in the PHR system into multiple security domains that greatly reduces the key management complexity for owners and users. A high degree of patient privacy is guaranteed simultaneously by exploiting multi-authority ABE. In this paper, we design and implement a PHR cloud platform integrated with the idea of CP-ABE. The developed PHR cloud platform enables patients to securely store and share their health records in a flexible way. The patient can store PHRs in an encrypted form, and cryptographically enforces patient or organizational access policies. To the best of our knowledge, we are the first to improve PHR sharing mechanism of Indivo X project [19] by adopting CP-ABE. The rest of this paper is organized as follows. Some preliminary works about CP-ABE schemes are introduced in Section II. The architecture of PHR cloud platform to be developed is described in Section III. The implementation details about PHR cloud platform are presented in Section IV. Performance evaluation is given in Section V. Finally, we conclude the paper in Section VI. II. P RELIMINARIES A. Access Structure Let P = {P1 , P2 , . . . , Pn } be a set of parties. A collection A ⊆ 2P is monotone if ∀B, C, we have that if B ∈ A and B ⊆ C then C ∈ A. An access structure (respectively, monotone access structure) is a collection (respectively, monotone collection) A ⊆ 2P \ {∅}. The sets in A are called
9
the authorized sets, and the sets not in A are called the unauthorized sets [8][10]. In our context, the role of the parties is taken by the attributes. Thus, the access structure A will contain the authorized sets of attributes. We restrict our attention to monotone access structures.
Phase 2. Phase 1 is repeated with the restriction that none of sets of attributes Ωq1 +1 , . . . , Ωq satisfy the access structure corresponding to the challenge. • Guess. The adversary outputs a guess b of b. The advantage of an adversary A in this game is defined as Pr[b = b] − 12 . We note that the model can easily be extended to handle chosen-ciphertext attacks by allowing for decryption queries in Phase 1 and Phase 2. •
B. Syntax for CP-ABE Scheme A CP-ABE scheme is specified by four polynomial algorithms as follows [9]. λ • Setup(1 ) → (params, msk): The probabilistic polynomial-time (PPT) setup algorithm takes as input a security parameter λ. It outputs the public parameters params and the master secret key msk which is only to the trusted attribute authority (AA). • Encrypt(params, m, A) → c: The PPT encryption algorithm takes as input the public parameters params, a message m together with the access structure A specified by the sender. It outputs ciphertext c encrypted under the access structure A. • KeyGen(params, msk, ω) → SKω : The PPT key generation algorithm is an interactive protocol between the AA and the user. The common input to AA and the user are the public parameters params, the set of attributes ω which the user owns, and the private input to the AA is the master secret key msk. At last, the user receives a decryption key SKω associated with the set of attributes ω. • Decrypt(params, c, SKω ) → m or ⊥: The deterministic polynomial time algorithm takes as input the public parameters params, the ciphertext c that was encrypted under the access structure A, and the user secret key SKω related to the set of attributes ω. It outputs the message m if ω ∈ A or an error message ⊥ if ω ∈ A.
Definition 1. A CP-ABE scheme is secure if all polynomial time adversaries have at most a negligible advantage in the above game. III. ARCHITECTURE OF PHR CLOUD PLATFORM We identify the main security requirements for PHR cloud platform as follows. • Confidentiality of health data in storage and transit: By confidentiality we mean the cloud provider or an adversary will not be able to read patients’ PHR data. Therefore, the patient’s PHR data have to be encrypted before it is upload to PHR cloud. • Integrity of health data: By integrity we mean to preserve the accuracy and consistency of data. In the PHR cloud platform, integrity refers to the fact that PHR data has not been tampered by unauthorized use. Integrity can be achieved by cryptographic hash function. • Authenticity of health data: By authenticity, we mean to ensure that the data are genuine and to validate that both parties involved are who they claim they are. In the PHR cloud platform, the PHR data are collected, stored and shared by a party other than the original health care provider. As such, the issue of verifying that the information was actually created by the claimed source must be addressed. Authenticity can be achieved by special signature schemes, such as group signature, ring signature and redactable signature [4], [18]. • Privacy protection for patients: Data disclosures are controlled following the data minimization principle, namely, the disclosure and retention of personal data should be limited to what is directly relevant and necessary to accomplish a specified purpose. • Patient-centric fine-grained access control: Patient should be aware of their privacy rights, and able to specify and delegate the access control policy of their data. The patient encrypts the PHR data according to ciphertext access policy (includes patient’s policy, system policy and statutory policy) such that only the users who satisfy the access policy can decrypt the protected data. In addition, the access policy should be flexible and convenient to create and manage. • Revocation: When a user’s secret key or attributes are no longer valid, this user can’t decrypt any PHR data even if they were supposed to. There are five participants in PHR cloud platform: health care provider, cloud service provider, attribute authority, PHR owner (patient), and PHR viewer.
C. Security Model for CP-ABE Scheme Like IBE schemes [5], the security model allows the adversary to query for any private keys that cannot be used to decrypt the challenge ciphertext. In CP-ABE scheme, the private keys are identified with attributes and the ciphertexts are identified with access structures. It follows that the security model for CP-ABE scheme allows the adversary to ask for any private key associated with the set of attributes Ωi that cannot be used to decrypt the challenge ciphertext, which is encrypted under an access structure A∗ , i.e., Ωi does not satisfy A∗ . The formal security game for CP-ABE is described as follows. • Setup. The challenger runs the Setup algorithm and gives the public parameters params to the adversary. • Phase 1. The adversary makes repeated private keys corresponding to sets of attributes Ω1 , . . . , Ωq1 . • Challenge. The adversary submits two equal length messages m0 and m1 . In addition the adversary gives a challenge access structure A∗ such that none of the sets Ω1 , . . . , Ωq1 from Phase 1 satisfy the access structure. The challenger flips a random coin b, and encrypts mb under A∗ . The ciphertext c is given to the adversary.
10
•
with logical AND operation. Decrypt: The encrypted PHR data can be accessible by everyone from cloud. Decryption is only possible if and only if the set of attributes corresponding to the PHR viewer’s private key satisfy the access policy embedded in the ciphertext. The PHR viewer can first get the content encryption key by running Decrypt algorithm of CP-ABE scheme, and then he can get plaintext PHR data using the content encryption key.
IV. IMPLEENTATION OF PHR CLOUD PLATFORM Fig. 1.
We implement a secure PHR cloud platform using CPABE based on Indivo X [19]. We change the data storage architecture and sharing mechanism of original PHA (Personal Health Application), and a new Indivo API calls are added and a Python ABE library named pyabelib is built [20]. It is important to choose a proper attribute set for designing a PHR cloud platform. In previous PHR systems using ABE [12][13][14][15][16][17], they simply choose user’s Workplace or Occupation as attributes. To provide more expressive policy, we define { Name, Date of Birth (DOB), Gender, Marriage status, Occupation, Workplace, Address, Key Expiration } as the set of attributes. The attribute Key Expiration is not a user-specified attribute, which is set by the AA to provide key revocation. According to the Waters’ CP-ABE scheme [10], there are two types of attributes: numerical type and non-numerical type. The numerical type is specified as attr = value, where attr is the name of attribute and value is a non-negative integer less than 264 . The non-numerical attributes can be any string of digits, letters and underscores, beginning with a letter. In order to preserve user’s attribute privacy, we only regard Name as non-numerical attribute, while the rest are regarded as numerical form in attribute storage. Another reason is that patient may treat Occupation = Doctor and Occupation = Physician as the same meaning, but they are two different non-numerical attributes in the KeyGen algorithm. If a patient encrypted a PHR with attribute Occupation = Doctor, and a doctor gets his private key associated with Occupation = Physician, then in this case, he couldn’t decrypt the PHR, which is supposed to be done. So we convert these nonnumerical style attributes to numerical ones to avoid such kinds of decryption failure. For example, we convert attribute DOB into Age as numerical type. We treat attributes Gender, Marriage and Occupation as enumerated data types, like “0” represents Female, and “1” stands for Male. For the attributes Workplace and Address, we organize it as (Country, Province, City, Workplace/Address). We assign a unique id for each concrete attribute, and every table has a foreign key referencing the corresponding id. The attributes Workplace and Address would have their own id. We can convert all attributes to numerical form by above method. We only store attributes Gender, Marriage, Occupation, Workplace and Address in Indivo X Server. These attributes are public and irrelevant to user’s identity. AA must get these five ids from Indivo X Server during the phase of
System architecture and workflow
It is important to assume that the cloud service providers are semi-trusted (i.e., honest but curious, HBC), which means that cloud service providers would try to find out as much information as possible while following the protocol. The purpose is to enable patients to control the distribution and use of their PHR data. As a provisional mitigation solution to this, PHR data needs to be encrypted before uploading to the cloud. The protection mechanism needs to ensure that patient’s data can only be decrypted by authorized parties according to the patient’s policy and consent. Fig. 1 shows the system architecture of the proposed PHR cloud platform where the patient can securely manage his/er health records using the CP-ABE scheme. In the following we explain the interactions that occur in the system. •
•
•
•
System Setup: AA runs Setup algorithm of Waters’ CPABE scheme, it outputs the public parameters params and the master secret key msk which is kept by AA secretly. Generate PHR: PHR owner gets original electronic medical record (EMR) from health care provider, then constructs PHR data based on EMR data and other data. Encrypt: It’s not suitable using CP-ABE to encrypt the PHR data for efficiency reasons. Instead, PHR owner first generates a AES key at random as content encryption key, and encrypts the PHR data using the content encryption key. PHR owner then sets access policy and encrypt the content encryption key using CP-ABE scheme under the access policy. KeyGen: User send a request for attribute private key along with his credentials to the AA. The AA administrator verifies and marks these requests as ”approved” or ”denied”. For the ”approved” request, AA administrator signs the request with his private key as qualified request and sends it to the AA server. Then AA server verifies signatures for requests approved by AA administrator, runs the KeyGen algorithm of CP-ABE scheme and delivers the private key corresponding to the set of attributes to the user. Currently the revocation for CP-ABE schemes is not very robust [11], we adopt the idea of expiration to solve this problem. AA generates a new access policy by adding expiration attribute to the original access policy
11
Fig. 2.
let the cloud encrypt or decrypt PHR directly. We create a client plugin using PyQt framework to execute Encrypt and Decrypt step. The PHA for encrypting and sharing should follow OAuth protocol as well [20]. The PHA for encrypting just lets patient choose PHR and set encrypted PHR name, access policy and keywords, then invokes the client plugin to complete encrypting operation. The sharing mechanism of Indivo X is improved to provide fine-grained security. In our improved sharing PHA, once a user enables it, it means that this user allows to share his PHR with those who also enabled PHR sharing PHA. After authorized, user could get a list which contains other people’s encrypted PHR. User can choose one he wants to view, then download the PHR and try to decrypt it, as shown in Fig 2. If the set of attributes corresponding to the user’s private key satisfy the access policy which is embedded in the encrypted PHR, he can successfully decrypt it.
User view and decrypt encrypted PHR
key generation. We add one new Indivo API to complete this conversion. Access policy is specified by PHR owner and is embedded in the ciphertext, which can be expressed by logical operations AND, OR, and OF. It also supports comparison operators, such as =, and ≥ for numerical attribute expression. For example, a policy could be “Doctor AND 2 OF (Age > 30, Male OR Female, Children hospital)”. Indivo X is using Python as its programming language. To facilitate backend servers and clients invoking ABE functions, we build the Python version pyabelib based on libfenc [21], which is a C library of ABE. Considering pyabelib’s performance, we use C to complete all of the computational work, and make calls using Python. The original Indivo X Server stores patient’s PHR in XML plaintext. To support CP-ABE scheme, we create a new XSD (XML Schema Definition) to replace the original XSD, which is depicted as follows.
V. EVALUATION OF PHR CLOUD PLATFORM
