See discussions, stats, and author profiles for this publication at: https://www.researchgate.

net/publication/261057201

Implementing a Personal Health Record Cloud Platform Using Ciphertext-Policy

Attribute-Based Encryption

Conference Paper · September 2012

DOI: 10.1109/iNCoS.2012.65

CITATIONS READS

26 1,106

3 authors, including:

Changji Wang
Guangdong University of Foreign Studies
141 PUBLICATIONS   3,699 CITATIONS   

SEE PROFILE

All content following this page was uploaded by Changji Wang on 02 May 2015.

The user has requested enhancement of the downloaded file.

 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: isswchj@mail.sysu.edu.cn

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. More-
over, 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
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 technolog-
ical 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 ac-
celeration of adoption of cloud computing among enterpris-
es. 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 be-
haviors 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

978-0-7695-4808-1/12 $26.00 © 2012 IEEE 8

DOI 10.1109/iNCoS.2012.65
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 identity-
based 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-to-
many encryption instead of one-to-one, it is envisioned as a
promising tool for addressing the problem of secure and fine-
grained 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 doc-
uments, 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
9
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 CP-
ABE 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 implemen-
tation 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 prelim-
inary 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 (respective-
ly, monotone access structure) is a collection (respectively,
monotone collection) A ⊆ 2P \ {∅}. The sets in A are called
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 autho-
rized sets of attributes. We restrict our attention to monotone
access structures.
B. Syntax for CP-ABE Scheme
A CP-ABE scheme is specified by four polynomial algo-
rithms 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 al-
gorithm 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 gen-
eration 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 determinis-
tic 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.
C. Security Model for CP-ABE Scheme
Like IBE schemes [5], the security model allows the ad-
versary 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 mes-
sages 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
• 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.
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 con-
trolled 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.

Fig. 1. 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’ CP-
ABE 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 adminis-
trator 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 sig-
natures 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
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
We implement a secure PHR cloud platform using CP-
ABE 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 Work-
place 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 Ex-
piration 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 non-
numerical 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 at-
tributes 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

Fig. 2. 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 perfor-
mance, 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.
<?xml version="1.0" encoding="ISO-8859-1"?>
<schema xmlns="http://www.w3.org/2001/
XMLSchema:elementFormDefault="qualified">
<element name="Abe_document">
<complexType>
<sequence>
<element name="Name" type="string"
minOccurs="1" maxOccurs="1"/>
<element name="Content" type="string"
minOccurs="1" maxOccurs="1"/>
<element name="KeyWord" type="string"
minOccurs="0" maxOccurs="1"/>
<element name="Policy" type="string"
minOccurs="0" maxOccurs="1"/>
</sequence>
</complexType>
</element>
</schema>
In the new XML, patients can specify custom PHR name,
concrete access policy, and keywords used for searching. The
“Content” element is encrypted PHR.
To achieve high level of data confidentiality, we won’t
12
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.
V. EVALUATION OF PHR CLOUD PLATFORM
Compared with Indivo X, our system has little influence on
the server side. We have added some new Indivo X style APIs
following its security protocol strictly, in order to make Indivo
X backend server support new encrypted PHR storage format.
The encryption and decryption steps are executed at client side,
so it is supposed that Indivo X server won’t have additional
overhead. Here we mainly measure pyabelib performance and
then compare it with libfenc. The client side will load params
from cached files, and AA also need to load params and msk
from local files, it is necessary to consider the I/O cost of
reading files. Therefore, we give a total execution period for
each Encryption, Decryption and KeyGen step including the
cost of reading files, meanwhile, we also calculate the actual
computation period in each step, excluding that cost.
In Waters CP-ABE scheme, each non-numerical attribute
corresponds to only one leaf node in access structure, but
numerical form may have more leaf nodes, thus we use the
number of leaf nodes instead of the number of attributes as
X-axis. Y -axis is each step’s time overhead.
We randomly create 50 attribute sets, only using non-
numerical form. For the i-th attribute set, it contains i at-
tributes, same as leaf nodes. In Encryption, to make sure
every leaf node is visited, we only use AND gate in the
policy. The we encrypt the same PHR plaintext using the
pre-created attribute sets starting from 1 to 50. For instance,
we first create some attribute sets: {a1001}, {a1001, b1002},
{a1001, b1002, c1003}. Then we convert them into “a1001”,
“a1001 and b1002”, “a1001 and b1002 and c1003” as the input
in Encryption. We run this procedure 10 times to get the mean
value.
In KeyGen, we also randomly create 50 attribute sets same
as above. Then we use these attribute sets to generate SKω .
We run it 10 times as well to calculate the average cost of
KeyGen.
In Decryption, the content encryption key (AES encryption
key) is set to 128-bit, which means the size of ciphertext is
 Fig. 4. Evaluation of pyabelib: Encryption
Fig. 3. Evaluation of pyabelib: Key Generation

fixed. We repeat Encryption and KeyGen steps above to get ci-

phertext and SKω . To guarantee the success of decryption, the
attribute set used in KeyGen also must be used in Encryption.
We also run it 10 times to get the mean value.
The experiments were run on a server on Ubuntu 10.04
LTS, kernel 2.6.32-pae-32bit, python 2.6.5, GCC 4.4.3, with
2 x Intel Xeon E5606 @2.13GHz CPU, 4 x 4GB of RAM.
The evaluation results are shown in Fig.3, Fig.4 and Fig.5,
respectively. There are three lines, the red one is the cost of
libfenc, the black one is the cost of pyabelib, and the blue
one is the actual computation cost of each step in CP-ABE
scheme. The red line almost fully overlaps with black line,
indicating that the performance of our pyabelib is consistent
with libfenc. All processing time increases linearly with the
Fig. 5. Evaluation of pyabelib: Decryption
number of leaf nodes, although it’s not very clear in KeyGen.
Besides, reading files costs additional 0.5 − 0.7 seconds. As
expected, time cost is acceptable, thus it’s practical for us we ACKNOWLEDGMENT
to combine CP-ABE with Indivo X. KeyGen is normally less This research is jointly funded by the National Natural
than 1 second under 50 leaf nodes, the server wouldn’t have Science Foundation of China (Grant No. 61173189 and No.
much overhead. 61100224), by Natural Science Foundation of Guangdong
Province (Grant No. 10451009101004573) and Grant for U-
VI. C ONCLUSIONS niversities in Guangzhou City (No. 10A008), Foundation for
Distinguished Young Talents in Higher Education of Guang-
Traditional access control mechanisms as well as traditional dong Province, and Guangdong Province Information Security
encryption techniques are not suitable to be used in the public Key Laboratory Project.
PHR cloud computing scenarios, which needs to provide pri-
vacy protection and fine-grained access control. The CP-ABE R EFERENCES
scheme has shown to be more useful in a healthcare setting [1] AHIMA e-HIM Personal Health Record Work Group, Practice brief.
since the access policy is enforced by virtually associating The role of the personal health record in the EHR, Journal of AHIMA
the access control policy to the protected data. This removes / American Health Information Management Association, 76 (7): pp.
64A-64D, 2005.
the need for involving a trusted entity which has to enforce [2] P. Mell and T. Grance, The NIST Definition of Cloud, 53(6): pp. 50,
access policies. In this paper, we propose a patient-centric, 2009.
privacy-preserving PHR sharing model in cloud, using CP- [3] Gartner report, Forecast: Public Cloud Services, Worldwide
and Regions, Industry Sectors, 2009-2014, Available at
ABE to provide privacy protection and fine-grained access http://www.gartner.com/resId=1378513.
control. Then we design and implement a PHR cloud platform [4] R. Zhang and L. Liu, Security Models and Requirements for Healthcare
based on Indivo X. PHR data are encrypted using CP-ABE Application Clouds, In IEEE 3rd International Conference on Cloud
Computing, pp. 268–275, 2010.
scheme and are stored in the cloud.

13
 [5] D. Boneh and M. K. Franklin, Identity-based encryption from the Weil
pairing, In CRYPTO 2001, LNCS 2139, Springer-Verlag, pp. 213–229,
2001.
[6] A. Sahai and B. Waters, Fuzzy Identity Based Encryption. In EURO-
CRYPT 2005, LNCS 3494, Springer-Verlag, pp. 457–473, 2005.
[7] V. Goyal, O. Pandey, A. Sahai and B. Waters, Attribute Based Encryption
for Fine-Grained Access Conrol of Encrypted Data, In Proceedings of
the 13th ACM conference on Computer and Communications Security,
pp. 89-98, 2006.
[8] R. Ostrovsky, A. Sahai and B. Waters, Attribute-Based Encryption with
Non-Monotonic Access Structures, In Proceedings of the 14th ACM
Conference on Computer and Communications Security, pp. 195–203,
2007.
[9] J. Bethencourt, A. Sahai and B. Waters, Ciphertext-policy attribute-
based encryption, In IEEE Symposium on Security & Privacy, pp. 321–
334, 2007.
[10] B. Waters, Ciphertext-Policy Attribute-Based Encryption: An Expressive,
Efficient, and Provably Secure Realization, In 14th International Con-
ference on Practice and Theory in Public Key Cryptography, Springer-
Verlag, LNCS 6571, pp. 53–70, 2011.
[11] C. Yin and R. Zhang, Access Control for the Smart Meters Based on
ABE, In 2011 International Conference on Cyber-Enabled Distributed
Computing and Knowledge Discovery, pp. 79-82, 2011.
[12] L. Ibraimi, M. Asim, M. Petkovic, Secure Management of Personal
Health Records by Applying Attribute-Based Encryption, In 6th In-
ternational Workshop onWearable Micro and Nano Technologies for
Personalized Health (pHealth), pp. 71-74, 2009.
[13] M. Li, S. Yu, K. Ren and W. Lou, Securing Personal Health Records
in Cloud Computing: Patient-centric and Fine-grained Data Access
Control in Multi-owner Settings, In Security and Privacy in Communi-
cation Networks 6th Iternational ICST Conference, SecureComm 2010,
Singapore, Springer, vol.50, pp. 89–106, 2010.
[14] S. Narayan, M. Gagné and R. Safavi-Naini, Privacy Preserving EHR
System Using Attribute-based Infrastructure, CCSW 2010, pp. 47–52,
2010.
[15] J. A. Akinyele, M. W. Pagano, M. D. Green, C. U. Lehmann, Z. N.
J. Peterson, A. D. Rubin, Securing Electronic Medical Records Using
Attribute-Based Encryption On Mobile Devices, In Proceedings of the
1st ACM workshop on Security and privacy in smartphones and mobile
devices, Chicago, pp. 75–86, 2011.
[16] Y. Zheng, Privacy-Preserving Personal Health Record System Using
Attribute-Based Encryption, MS thesis, Worcester Polytechnic Institute,
2011.
[17] M. Li, S. C. Yu, Y. Zheng, K. Ren, and W. J. Lou, Scalable and Secure
Sharing of Personal Health Records in Cloud Computing using Attribute-
based Encryption, IEEE Transactions on Parallel and Distributed Sys-
tems, accepted, 2012.
[18] A. Mohan, D. Bauer, D. M. Blough, M. Ahamad, B. Bamba, R. Krish-
nan, L. Liu, D. Mashima, B. Palanisamy, A Patient-centric, Attribute-
based, Source-verifiable Framework for Health Record Sharing, GIT
CERCS Technical Report No. GIT-CERCS-09-11, 2009.
[19] K. D. Mandl, W. W. Simons, W. C. Crawford, J. M. Abbett, Indivo: a
personally controlled health record for health information exchange and
communication, BMC Med Inform Decis Mak, 7(25), pp. 1–10, 2007.
[20] Personally Controlled Health Record (PCHR) system using
Attributed-Based Encryption Project, The pyabelib toolkit,
https://code.google.com/p/abe-pchr/.
[21] The Functional Encryption Library, http://code.google.com/p/libfenc/

14

View publication stats