2015 IEEE 17th International Conference on High Performance Computing and Communications (HPCC), 2015 IEEE 7th

International Symposium on Cyberspace Safety and Security (CSS), and 2015 IEEE 12th International Conf on Embedded Software
and Systems (ICESS)

Auditing and Revocation Enabled Role-Based Access Control over Outsourced

Private EHRs

Weiran Liu∗ , Xiao Liu∗ , Jianwei Liu∗ , Qianhong Wu∗ , Jun Zhang∗ , Yan Li†
∗ Schoolof Electronic and Information Engineering, Beihang University, Beijing, China
Email: liuweiran900217@gmail.com; liuxiaobh@gmail.com; liujianwei@buaa.edu.cn;
qianhong.wu@buaa.edu.cn; buaazhangjun@vip.sina.com
† Aerospace Hengxing Science and Technology co. LTD, Beijing, China
Email: liyanyq@163.com

Abstract—Electronic Health Record (EHR) systems have
an abundance of convenience for telediagnosis, medical data
sharing and management. The main obstacle for wide adoption
of EHR systems is due to the privacy concerns of patients.
In this work, we propose a role-based access control (RBAC)
scheme for EHR systems to secure private EHRs. In our
RBAC, there are two main types of roles, namely independent
patients and hierarchically organized medical staff. A patient is
identified by his/her identity, and a medical staff is recognized
by his/her role in the medical institute. A user can comprehend
an EHR only if he/she satisfies the access policy associated with
this EHR, which implies a fine-grained access control. A public
auditor is employed to verify whether the EHR is correctly
encapsulated with the specified access policy, which provides
an a priori approach to find fraudulent EHRs and prevent
potential medical disputes. Moreover, our RBAC enforces a
forward revocation mechanism. A revoked user cannot access
to the future EHRs even if his/her previous role satisfies the
access policy. We analyse the security and efficiency of our
RBAC, showing that it is an practical solution to secure EHRs.
Keywords-electronic health record; data privacy; role-based
access control; public audit; forward revocation;
I. I NTRODUCTION
The development of Electronic Health Record (EHR)
for enabling electronic health systems has drawn extensive
attentions from both academia and industry. Compared to
traditional Paper-Based Health Records (PBHR), EHRs can
be stored and shared in a more flexible way. Due to its digital
format, various types of health data can be contained in one’s
EHR account, including prescription files, medical images
such as X-ray, B-scan, audio clips and video files. The digital
feature also allows EHRs to be accessed in a convenient
manner. To find one’s EHRs, the patient and his/her doctors
just need to retrieve them from the storage server, instead
of seeking carefully in a piled-up archive room. These
attractive properties render EHRs as a promising alternative
advantageous over PBHRs.
It is a daunting task for healthcare providers who may not
have professional capabilities required to manage a large-
scale EHR database with universal access. This impedes the
practicability of EHR system [1]. The recent advancement
of cloud computing may relieve healthcare providers from
this issue. Instead of establishing EHR servers locally, EHRs
can be outsourced to a cloud storage server. In this way, the
capital and operational expenditures can be tremendously
reduced for healthcare providers, simultaneously preserving
EHR data availability [2], [3].
There are remaining obstacles for outsourcing EHRs.
Among them, privacy and security risks on patients’ health
records are considered as the dominating barriers [4], [5].
Patient’s EHRs are often the target of various malicious
attacks, vulnerable to loss, leakage, or theft [6]. To ensure
data privacy of EHRs, a plausible way is to encapsulate
patients’ EHRs by encrypting them prior to outsourcing
them to the storage server, e.g., by applying classical private
key or public key cryptosystems. However, the problem in
outsourcing EHRs is that the EHR owners (i.e., patients)
may not know who will be allowed to access the EHRs prior
to the next diagnosis. A possible remedy is to encrypt many
copies with different keys and assign each key to the doctor
who needs to access the EHRs. However, this implies either
overwhelming key management and computational overhead
[7] or failure of flexible access control [8].
New access control approaches are required to secure out-
sourced EHRs before they are widely adopted [9]. To address
this problem, we consider a typical hospital organization as
depicted in Figure 1. In such a scenario, there are two main
types of users, i.e., patients and medical staff. The patients
can be recognized by their national identity numbers, social
security numbers or names plus their telephone numbers.
The medical staff in the hospital are usually grouped hi-
erarchically into a relatively small number of roles. For
example, the out-patient doctors and out-patient nurses are
grouped into the role “(out-patient)”. In the department of
medicine, the chief doctor is recognized by the role “(Dept.
of Medicine, chief doctor)”. Its subordinates, including head
nurses, nurses and associate doctors, are all labeled with
their roles. One may observe that in the real world the users’
access privileges are usually determined by their roles in the
system. This observation indicates a conceivable role-based
access control over outsourced EHRs.

978-1-4799-8937-9/15 $31.00 © 2015 IEEE 336

DOI 10.1109/HPCC-CSS-ICESS.2015.10

Figure 1: Typical Hospital Organization
We propose a generic framework of role-based access
control (RBAC) over outsourced EHRs. We formalize the
system model and identify security and privacy requirements
in such a system. Following the generic framework, we
present an efficient and secure RBAC scheme for securing
EHRs stored in a storage server maintained by a third party
who is not fully trusted. Specifically, our RBAC scheme is
equipped with the following essential and attractive features.
Versatile Access Control. Our RBAC offers a novel
and more efficient approach to support fine-grained access
control without leveraging attribute-based encryption (ABE)
[10], [11]. A user can encapsulate each EHR with an on-
demand access policy. Only the corresponding patient and
medical staff with roles that satisfy the access policies
can decapsulate. Scalable sharing of EHRs is supported by
allowing senior medical staff to delegate access credentials
for their subordinates.
Provable Privacy. The security of RBAC is formally
defined. The security of our concrete construction is strict-
ly proven under well-established assumptions. Specifically,
ones without matching roles can get no useful information
about the EHR data, even if they collude and the storage
server is untrusted.
Public Auditability. A public auditor is employed to
verify whether the EHR is correctly encapsulated according
to the specified access policy. In this way, RBAC provides
an a priori approach to find fraudulent EHRs and prevent
potential medical disputes.
Forward Revocation. An automatic revocation mechanis-
m is supported in RBAC scheme. The revoked user cannot
access to the future EHRs even if its previous role satisfies
the access policy defined in the newly generated EHRs.
Thorough theoretical and experimental analyses show
the feasibility and efficiency of our RBAC in terms of
communication and computation. The encapsulation headers
for EHRs with any access policies contain only two group
elements. Time consumptions for all procedures involved
337
in our RBAC, including encapsulation and decapsulation,
are less than one second even when the access policies are
considerably complicated. All of these features commit the
proposed RBAC a practical solution to secure EHR systems.
II. R ELATED W ORK
It is essential to identify the potential security and privacy
threats of EHR systems in their deployment for seeking
design guidelines. Kwak [12] introduced relevant definitions
of EHR systems and summarized the available standards of
EHR systems presented by International Standards Develop-
ing Organizations (SDO). Ray and Wimalasiri [13] identified
privacy requirements for EHR systems in the context of
HealthLink in Australia and HIPAA in USA, which are
the two well-known eHealth frameworks around the world.
Recently, Li et al. [14] presented new threats against EHR
systems and indicated that EHRs are very vulnerable without
effective privacy protection.
Efforts have been devoted to access control in EHR
systems. Benaloh et al. [8] showed efficient EHR systems
that allow patients to both share access rights with others,
and to support searches over their EHRs. Löhr et al. [4]
presented a security architecture allowing legitimate sharing
and ensuring privacy for EHR systems. Some proposals have
been implemented to handle access control with security
and privacy enabled approaches, including identity-based
authentication [15], [16] and smartcard-based authentication
[17]. Schemes exploiting multiple cryptographic primitives
have been proposed to achieve additional functionalities,
e.g., cross-domain [18] and emergency [19] EHR sharing.
A plain implementation of aforementioned proposals do
not achieve flexible access control. Attribute-based encryp-
tion (ABE) [20], a new cryptographic primitive, is a novel
method to obtain flexible access control in clouds [21], [22].
Applications have been also proposed to obtain access con-
trol [23], [5] and authentication [24] for outsourced EHRs.
Very recently, an access control framework of EHR systems
was proposed [7] by combining identity-based encryption
and ABE, in which the former is employed to encapsulate
EHR for patients while the latter is for medical staff.
III. S YSTEM M ODEL
A. System Architecture
As illustrated in Figure 2, five entities are involved in our
RBAC: Trusted Keying Authority (TKA), Patient, Medical
Staff, Auditor and Storage Server. We assume that TKA
is always trusted in our system. Patient, Medical Staff and
Auditor are untrusted but honest, i.e., they honestly execute
the algorithms that they are responsible to execute. If they
are authorized by an access policy specified to an EHR,
they do not reveal any useful information of the EHR to
unauthorized entities. However, if they are not authorized
by an access policy, they may be a potential adversary. We
focus on malicious attacks from unauthorized entities.

Figure 2: System Model
For ease of description, we assume that the owner of EHR
is the patient. In some specific situations, patients might not
have access to their own EHRs. For example, according to
HIPAA, patients might not be allowed to access to their own
psychotherapy notes without proper authorization for the
medical staff. We can follow the regulations (i.e., HIPAA) to
set parametric roles in such scenarios to meet more accurate
access control requirements.
All patients need to be identified individually in our R-
BAC. Their roles are labeled by their identities. Medical staff
in a hospital that provides healthcare services for patients are
hierarchically organized. Each medical staff is defined by a
role consisting of ordered atom roles. A medical staff whose
role is at higher level of the medical institute is responsible
for managing other medical staff with roles at lower level,
which implies a tree-like organization. For instance, as
shown in Figure 2, a medical staff in the department of
surgery with lower-level role (dept. surgery, chief doctor,
associate doctor, doctor) consisting of different atom roles
“dept. surgery”, “chief doctor”, “associate doctor”, “doctor”,
is administrated by the associate doctor in the same de-
partment with higher-level role (dept. surgery, chief doctor,
associate doctor). The associate doctor is then managed by
the chief doctor with role (dept. surgery, chief doctor).
TKA is responsible for setting up the system and au-
thenticating users (patients and medical staff) to determine
their eligibilities for accessing EHRs. All patients and
medical staff is eventually managed by TKA. Patients and
medical staff can generate and encapsulate different kinds
of EHRs (X-ray, B-scan, etc.) associated with on-demand
access policies, and then store them in the storage server
for sharing with the designating patient and the entitled
medical staff. The storage server only needs to guarantee
basic storage functionalities, such as storage management
and integrity examination, which have been widely studied
and implemented by existing researches [25], [26]. Before
storing EHRs, an auditor is employed to verify whether the
EHR is associated with the specified access policy. Only
valid EHRs will be stored in the storage server.
338
B. Adversary Model and Security Requirements
Since inside attackers can gain more information to attack
the system than outsiders, the system will be secure against
outside attackers if it is secure against insider attacks.
Hence, we will focus on inside attackers. In practice, all
entities except TKA are likely to attack the system. A
dishonest party may try to get useful information from the
encapsulated EHRs that it is not authorized to access, or
divert from the system instructions for benefits (e.g., with
false EHRs in medical disputes). Multiple dishonest parties
may collude to achieve this goal. In the context of such
attacks, an RBAC system is expected to meet the following
security requirements.
Data Privacy. The privacy of outsourced EHR must be
protected for authorized access. The users (patients and
medical staff) whose roles satisfy the access policy specified
in the encapsulated EHRs can have access, while any other
unauthorized entities cannot get any useful information from
the encapsulated EHR data, even if they collude.
Public Auditability. A public procedure can be employed
to verify whether the EHR is correctly encapsulated with
the specified access policy, which provides an a priori
approach to find fraudulent EHRs and prevent potential
medical disputes.
Forward Revocation. Forward revocation mechanism
should be designed to disallow revoked users to access the
future EHRs, even if their previous roles satisfy the access
policy defined in the newly generated EHRs.
IV. A C ONCRETE RBAC S CHEME
A. Notations
We introduce several notations to simplify the description
of our RBAC. We use [a, b] to denote an integer set {a, a +
1, · · · , b}. The role of a medical staff is denoted by a vector
R = (R1 , · · · , Rd ) consisting of distinct atom roles Ri .
We define R as the number of atom roles in R and SR
as the atom role set associating with R. An access policy P
is defined by a role set consisting of distinct roles. Similarly,
the number of atom roles in P and the atom role set of P
can be defined accordingly. We slightly abuse the term prefix
and define the prefix of a role R = (R1 , · · · , Rd ) as a role
set denoted by P ref (R) = {(R1 , · · · , Rd ) : d ≤ d}.
Similarly, wedefine the prefix of an access policy P as
P ref (P) = R∈P P ref (R).
B. Bilinear Groups
Bilinear groups have been shown useful in constructing
advanced access control schemes to secure EHRs [24], [19]
and remote storage systems [21], [22]. They are defined
by using a group generator G, an algorithm which takes
a security parameter λ as input and outputs a description
of a bilinear group, (p, G, GT , e) ← G(1λ ), where p is a
large prime, G and GT are cyclic groups of order p, and and outputs
an efficient bilinear map e : G × G → GT satisfying: (1)   r 
 
Bilinearity: ∀g, h ∈ G, ∀a, b ∈ Zp , e(g a , hb ) = e(g, h)ab ; ACR = g2α g3 · ut0 uR
i
i
,g r
, ghr , urj j∈[1,n+1]\I .
(2) Non-degeneracy: There exists at least an element g ∈ G i∈I
such that e(g, g) has order p in GT . Note that TKA can generate access credentials for any
medical staff with authorized roles by running ACGenM
C. The Proposal
algorithm.
We are now ready to describe our scheme. Technically, our
ACDeleM(P K, ACR , R). When a junior medical staff
construction contributes in three aspects. First, we extend a
associated with role R = (R , R) is authenticated by a
recent hierarchical identity-based encryption (HIBE) scheme
supervisor associated with role R , the supervisor delegates
[27] to efficiently encrypt to multiple receiver paths. In
the access credential for the junior one by using
HIBE [27], an encryptor can only encrypt to a single
⎛  r  ⎞
path, which implies either constrained access policy or    
repetitive encryption to multiple receiver paths. Our RBAC ACR = ⎝g2α g3 · ut0 R
ui i , g r , ghr , urj ⎠
j∈[1,n+1]\I
construction supports fine-grained access control by encap- i∈I
 
sulating EHRs to any subset of hierarchically organized = a0 , a1 , a2 , {bj }j∈[1,n+1]\I
users with a short header file. Note that our RBAC offers
a novel and more efficient approach to support fine-grained where I = {i : Ri ∈ SR }, r is the random exponent used
access control without ABE systems [10], [11]. Second, we in ACR . The senior medical staff picks a random exponent
propose a new direct chosen-ciphertext secure construction R
s ← Zp and outputs the access credential
from chosen-plaintext secure encryption. Compared with ⎛  s ⎞
  
the shrink construction approach [28] which builds chosen-
⎜ a0 bR i
g3 · ut0 uR i
,⎟
ACR = ⎜ ⎟
ciphertext secure l-hierarchy HIBE from chosen-plaintext i i
i∈I\I
⎝  i∈I ⎠
secure (l + 1)-hierarchy HIBE, our approach only adds
a1 g s , a2 ghs , bj usj j∈[1,n+1]\I
one on-the-fly dummy verification role in the first hierar-
chy, instead of a hierarchy of dummy identities. Also, our where I = {i : Ri ∈ SR }.
construction allows public verification of the encapsulation By implicitly setting r = r + s, this delegated access
consistency, which implies that a single public auditor can credential can be written in the form
be employed to validate all EHRs to be outsourced. Third,   r 
  r
Ri
our RBAC facilitates forward revocation. This is realized by ACR = g2 g3 · u0
α t
ui r r
, g , gh , uj j∈[1,n+1]\I
introducing a lifetime t to each access credential and each i∈I
EHR header, where t is decided by the expired time of EHRs which is well-formed as if it were generated directly by
and published by TKA. Our scheme works as follows: TKA with the ACGenM algorithm. Hence it is a properly
Setup(λ, n). It is run by TKA to establish our RBAC. Given distributed access credential for the medical staff associated
the security parameter λ ∈ Z∗ , TKA runs (p, G, GT , e) ← with role R = (R , R).
G(1λ ) to generate a prime p, two groups G, GT or order ACGenP(P K, M SK, ID). It is run by TKA when a
p, and a bilinear map e : G × G → GT . A secure symmet- patient with identity ID requests an access credential in
ric encryption scheme εsym with algorithms SymEnc(K, order to access its own EHRs. To do so, TKA pick-
M ) and SymDec(K, M ), and a collision resistant hash R
s a random exponent r ← Zp and outputs ACID =
function H : G → Zp are also employed in the scheme.   r 
R g2α g3 · ghID , g r , urj j∈[0,n+1] .
Then, TKA selects a random generator g ← G, a random
R
exponent α ← Zp , and sets g1 ← g α . Next, it picks EHREnc(P K, ID, P, EHR). For an access policy P,
R R denote I = {i : Ri ∈ SP }. When EHR needs to be
random elements g2 , g3 , gh ← G and ui ← G for all
encapsulated under the patient’s identity ID and the access
i ∈ [0, n + 1]. The system parameter P K is published as
policy P, the user (a patient or a medical staff) first picks
P K = g, g1 , g2 , g3 , gh , {ui }i∈[0,n+1] . The master secret R
key M SK = g2α is kept by TKA. a random exponent β ← Zp and computes the first element
of the header C0 = g β . Next, the user generates the
ACGenM(P K, M SK, R). It is run when a medical staff encapsulation key K as the group element K = e(g1 , g2 )β
is authenticated by TKA. For a medical staff associated with and computes EF = SymEnc(K, EHR). Finally, the user
role R = (R1 , · · · , Rd ), denote I = {i : Ri ∈ SR }. computes w = H(C0 ) and the second element of the header
Recall that the lifetime t is published by TKA. To generate  β

an access credential for that medical staff using the master C1 = u0 · gh · un+1 · g3 ·
t ID w Ri
ui .
R
secret key M SK, TKA picks a random exponent r ← Zp i∈I

339
The encapsulated EHR data is formed as (Hdr, EF ) =
(C0 , C1 , EF ).
EHRAudit(P K, ID, P, (Hdr, EF )). Before an encapsulated
EHR (Hdr, EF ) = (C0 , C1 , EF ) is outsourced to the
storage server, the auditor verifies whether the EHR has been
correctly encapsulated under the specified access policy by
testing the following equality
  
?
 D. Security Results
e(g, C1 ) = e C0 , ut0 · ghID · uwn+1 · g3 · uiRi (1)
i∈I
where I = {i : Ri ∈ SP }, w = H(C0 ). If the equality holds,
the auditor outputs V alid to indicate the EHR encapsulation
is valid. Otherwise, it outputs Invalid to alarm related
parties. Note that the inputs of algorithm EHRAudit are
all publicly known; so the auditing can be verified publicly.
EHRDecM(P K, ID, P, (Hdr, EF ), ACR ). Given the
encapsulated data (Hdr, EF ) = (C0 , C1 , EF ) stored in the
EHR storage server, a medical staff whose role R satisfies
the access policy P, that is, R ∈ P ref (P), can use
its access credential to decapsulate the EHR. Suppose the
access credential for the medical staff with role R is
 
ACR = a0 , a1 , a2 , {bj }j∈[1,n+1]\I
where I = {i : Ri ∈ SR }. Denote I = {i : Ri ∈ SP }. The
medical staff computes
⎛ ⎞
 uploaded EHR data under lifetime t = t cannot be decap-
K = e ⎝a0 · aID
2 · bn+1 ·
w
bi i , C0 ⎠/e(C1 , a1 )
R
i∈I\I
where w = H(C0 ). It finally runs EHR = own EHRs since the lifetime is not embedded in their access
SymDec(K, EF ) to get EHR.
EHRDecP(P K, ID, P, (Hdr, EF ), ACID ). The patient with
identity ID can decapsulate his/her own EHRs using his/her
access credential. Suppose the access credential ACID for
the patient associated with identity ID is
  r  
ACID = g2α · g3 ghID , g r , urj j∈[0,n+1]
 

= a0 , a1 , bj j∈[0,n+1] .
Denote I = {i : Ri ∈ SP }. The patient computes the
message encapsulation key
 
 Ri
 t w
K = e a0 · b 0 · b n+1 · b i , C0 /e(C1 , a1 )
 elements in G. The system parameter, the master secret key
i∈I
where w = H(C0 ), and also runs EHR = efficiency analyses is presented in the full version.
SymDec(K, EF ) to decapsulate its own EHRs.
Correctness. The correctness of our RBAC is guaranteed
by Theorem 1 and Theorem 2. The proofs are shown in the
full version of the paper.
Theorem 1. If an EHR is correctly encapsulated with the
specified access policy, then equation (1) holds and the
auditing can be approved.
Theorem 2. The medical staff whose role satisfies the access
policy that is designated to the encapsulated EHR data can
correctly decapsulate it. The corresponding patient can also
correctly decapsulate his/her own EHRs.
The following states that the proposed RBAC scheme
achieve the security requirements described in Sec. III-B.
Formal security analysis is given in the full version.
Data Privacy. The privacy of EHRs is protected by applying
a secure symmetric encryption scheme εsym such as AES
[29]. The message encapsulation key K can only be obtained
by the corresponding patient and the medical staff with
matching roles. The ones whose roles do not satisfy the
access policy cannot extract K, and hence cannot obtain
useful information from the encapsulated EHRs.
Public Auditability. The public auditing procedure ensures
the legitimacy of the encapsulated EHR. The inequality
of the auditing equation (1) shows that the EHR is not
encapsulated with the specified access policy.
Forward Revocation. The lifetime t has embedded in the
access credentials of medical staff. Hence, they can only
decapsulate EHR data during the given lifetime. Newly
sulated by expired access credentials of medical staff. The
patients, on the other hand, can still correctly decapsulate his
credentials. However, due to the fact that the identity has
been embedded in the his/her access credential, the patient
can only access EHRs that are encapsulated with his/her
identity.
V. P ERFORMANCE A NALYSES
In our RBAC, the encapsulation procedure (EHREnc)
requires one pairing operation (which can be pre-computed).
The public audit procedure (EHRAudit), the decapsulation
procedures (EHRDecM and EHRDecP) require two pairing
operations. The scheme is efficient in computation. For any
subset of receivers (patients or medical staff), the header
of the encapsulated EHR data always contains two group
and the access credentials (of patients or medical staff) are
linear with the maximal atom role number. The detailed
ACKNOWLEDGMENT
This paper is partially supported by the National Key
Basic Research Program (973 program) through project
2012CB315905, by the Natural Science Foundation through

340
projects 61272501, 61173154, 61370190 and 61003214, by
the Fundamental Research Funds for the Central Universities
through project No.YWF-15-GJSYS-059, by the Innovation
Fund of China Aerospace Science and Technology Corpora-
tion Satellite Application Research Institute through project
2014-CXJJ-TX-10, and by the Beijing Natural Science
Foundation through project 4132056.
R EFERENCES
[1] S. Yu, C. Wang, K. Ren, and W. Lou, “Achieving secure,
scalable, and fine-grained data access control in cloud com-
puting,” in INFOCOM ’10. IEEE, 2010, pp. 1–9.
[2] M. Barua, X. Liang, R. Lu, and X. Shen, “Espac: Enabling
security and patient-centric access control for ehealth in cloud
computing,” pp. 67–76, 2011.
[3] S. Kamara and K. Lauter, “Cryptographic cloud storage,” in
FC ’10. Springer Berlin Heidelberg, 2010, pp. 136–149.
[4] H. Löhr, A. R. Sadeghi, and M. Winandy, “Securing the e-
health cloud,” in IHI ’10. ACM, 2010, pp. 220–229.
[5] M. Li, S. Yu, Y. Zheng, K. Ren, and W. Lou, “Scalable and
secure sharing of personal health records in cloud computing
using attribute-based encryption,” IEEE Transactions on Par-
allel and Distributed Systems, vol. 24, no. 1, pp. 131–143,
2013.
[6] M. E. Johnson, “Data hemorrhages in the health-care sector,”
in FC ’09. Springer Berlin Heidelberg, 2009, pp. 71–89.
[7] J. Huang, M. Sharaf, and C. T. Huang, “A hierarchical
framework for secure and scalable ehr sharing and access
control in multi-cloud,” in ICPPW ’12. IEEE, pp. 279–287.
[8] J. Benaloh, M. Chase, E. Horvitz, and K. Lauter, “Patient
controlled encryption: Ensuring privacy of electronic medical
records,” in CCSW ’09. ACM, 2009, pp. 103–114.
[9] L. Røstad and O. Nytrø, “Personalized access control for a
personally controlled health record,” in CSAW ’08. ACM,
2008, pp. 9–16.
[10] J. A. Akinyele, C. U. Lehmann, M. D. Green, M. W. Pagano,
Z. N. J. Peterson, and A. D. Rubin, “Self-protecting electronic
medical records using attribute-based encryption,” Cryptology
ePrint Archive, Report 2010/565, 2010, http://eprint.iacr.org/.
[11] S. Narayan, M. Gagné, and R. Safavi-Naini, “Privacy preserv-
ing ehr system using attribute-based infrastructure,” in CCSW
’10. ACM, 2010, pp. 47–52.
[12] Y. S. Kwak, “International standards for building electronic
health record (ehr),” in HEALTHCOM ’05. IEEE, 2005, pp.
18–23.
[13] P. Ray and J. Wimalasiri, “The need for technical solutions
for maintaining the privacy of ehr,” in EMBS ’06. IEEE,
2006, pp. 4686–4689.
[14] F. Li, X. Zou, P. Liu, and J. Y. Chen, “New threats to health
data privacy,” BMC Bioinformatics, vol. 12, no. 12, pp. 1–7,
2011.
341
[15] C. C. Tan, H. Wang, S. Zhong, and Q. Li, “Body sensor
network security: An identity-based cryptography approach,”
in WiSec ’08. ACM, 2008, pp. 148–153.
[16] ——, “Ibe-lite: A lightweight identity-based cryptography for
body sensor networks,” IEEE Transactions on Information
Technology in Biomedicine, vol. 13, no. 6, pp. 926–932, 2009.
[17] T. Hupperich, H. Löhr, A. R. Sadeghi, and M. Winandy,
“Flexible patient-controlled security for electronic health
records,” in IHI ’12. ACM, 2012, pp. 727–732.
[18] J. Sun and Y. Fang, “Cross-domain data sharing in distributed
electronic health record systems,” IEEE Transactions on
Parallel and Distributed Systems, vol. 21, no. 6, pp. 754–764,
2010.
[19] J. Sun, X. Zhu, C. Zhang, and Y. Fang, “Hcpp: Cryptography
based secure ehr system for patient privacy and emergency
healthcare,” in ICDCS ’11. IEEE, 2011, pp. 373–382.
[20] V. Goyal, O. Pandey, A. Sahai, and B. Waters, “Attribute-
based encryption for fine-grained access control of encrypted
data,” in CCS ’06. ACM, 2006, pp. 89–98.
[21] M. Nabeel and E. Bertino, “Privacy preserving delegated
access control in the storage as a service model,” in IRI ’12.
IEEE, 2012, pp. 645–652.
[22] Z. Wan, J. Liu, and R. H. Deng, “Hasbe: A hierarchical
attribute-based solution for flexible and scalable access con-
trol in cloud computing,” IEEE Transactions on Information
Forensics and Security, vol. 7, no. 2, pp. 743–754, 2012.
[23] M. Barua, X. Liang, R. Lu, and X. Shen, “Peace: An efficient
and secure patient-centric access control scheme for ehealth
care system,” in INFOCOM WKSHPS ’11. IEEE, 2011, pp.
970–975.
[24] L. Guo, C. Zhang, J. Sun, and Y. Fang, “Paas: A privacy-
preserving attribute-based authentication system for ehealth
networks,” in ICDCS ’12. IEEE, 2012, pp. 224–233.
[25] R. Agrawal and C. Johnson, “Securing electronic health
records without impeding the flow of information,” Interna-
tional Journal of Medical Informatics, vol. 76, no. 5, pp. 471–
479, 2007.
[26] L. E. Olson, C. A. Gunter, and S. P. Olson, “A medical
database case study for reflective database access control,”
in SPIMACS ’09. ACM, 2009, pp. 41–52.
[27] D. Boneh, X. Boyen, and E. J. Goh, “Hierarchical identity
based encryption with constant size ciphertext,” in EURO-
CRYPT ’05. Springer Berlin Heidelberg, 2005, pp. 440–456.
[28] X. Boyen, Q. Mei, and B. Waters, “Direct chosen ciphertext
security from identity-based techniques,” in CCS ’05. ACM,
2005, pp. 320–329.
[29] J. Daemen and R. Vincent, The Design of Rijndael: AES - The
Advanced Encryption Standard. Springer Berlin Heidelberg,
2002.