SPECIAL SECTION ON SECURITY AND PRIVACY IN EMERGING

DECENTRALIZED COMMUNICATION ENVIRONMENTS

Received August 9, 2019, accepted September 10, 2019, date of publication September 23, 2019, date of current version October 2, 2019.
Digital Object Identifier 10.1109/ACCESS.2019.2943153

Cloud-Assisted EHR Sharing With Security and

Privacy Preservation via Consortium Blockchain
YONG WANG1 , AIQING ZHANG 1 , (Member, IEEE), PEIYUN ZHANG2 , (Senior Member, IEEE),
AND HUAQUN WANG 3 , (Member, IEEE)
1 School of Physics and Electronic Information, Anhui Normal University, Wuhu 241002, China
2 School of Computer and Information, Anhui Normal University, Wuhu 241002, China
3 School of Computer Science, Nanjing University of Posts and Telecommunications, Nanjing 210023, China

Corresponding author: Aiqing Zhang ([email protected])

This work was supported in part by the National Natural Science Foundation of China under Grant 61601005, Grant 61872006, and Grant
61872192, in part by the Natural Science Foundation of Anhui Province under Grant 1808085MF164, in part by the Anhui Provincial Key
Laboratory of Network and Information Security under Grant AHNIS2018003, in part by the Scientific Research Staring Foundation of
Anhui Normal University under Grant 2018XJJ40, and in part by the Natural Science Foundation of Jiangsu Province under Grant
BK20181394.

ABSTRACT The sharing of electronic health records (EHRs) has great positive significance for research of
disease and doctors’ diagnosis. In recent years, cloud-based electronic medical record sharing scheme has
brought a lot of conveniences, but the centralization of cloud exposes threats inevitably to data security
and privacy preservation. Blockchain technology can be seen as a promising solution to address these
problems on account of its unique propertis of decentration, anonymity, unforgeability and verifiability.
In this paper, we propose a blockchain based secure and privacy-preserving EHR sharing protocol. Data
requester can search desired keyword from data provider to find relevant EHRs on the EHR consortium
blockchain and get the re-encryption ciphertext from cloud server after getting the data owner’s authorization.
The scheme mainly uses searchable encryption and conditional proxy re-encryption to realize data security,
privacy preservation, and access control. Furthermore, proof of authorization is designed as the consensus
mechanism for consortium blockchain to guarantee system’s availability. Security analysis demonstrates
that the proposed protocol can achieve security goals. Besides, we emulate the cryptographic primitives and
implement the proposed scheme on Ethereum platform. Performance evaluation shows that the proposed
scheme has high computational efficiency.

INDEX TERMS Electronic health records, data sharing, blockchain, data security, privacy preservation.

I. INTRODUCTION EHR sharing has attracted extensive attentions and

With high-speed development of information technology and researches from industry and academia, where the most note-
Internet technology, Electronic Health Records (EHRs), as a worthy issues are privacy preservation, data security and
replacement of traditional manuscript patient’s health records interoperability [2]. First, EHRs include personal and high
on paper, solve the problems of paper that easy to lose, privacy-sensitive information, thus privacy preservation is
difficult to save for a long time and not easy to carry. For the guard of patients’ reputation and benefit. Second, only
the research of disease, doctors or medical institutions need the authentic data in EHRs can reflect the real situation
abundant EHRs which contain similar or related disease to and promote the development of medical treatment. On the
compare and analyze for seeking better therapeutic meth- contrary, the forged or modified data reduces the effec-
ods [1]. For a patient, he/she may not be able to remember tive utilization of EHRs. Additionally, the interoperability
his/her medical history or can’t describe detailed symptoms. can help patients to control the access right of their EHRs
EHR sharing is a promising solution for these problems, and enhance mobility of EHRs between different healthcare
which can help doctors know more about patients, such that institutions.
improving the accuracy of disease diagnosis. In response to these questions, cloud technology has been
put forward for health data storage, management and shar-
The associate editor coordinating the review of this manuscript and ing [3]–[8]. These works use different cryptographic algo-
approving it for publication was Xiaochun Cheng . rithms and cloud technology to design access control schemes

This work is licensed under a Creative Commons Attribution 4.0 License. For more information, see http://creativecommons.org/licenses/by/4.0/
136704 VOLUME 7, 2019
Y. Wang et al.: Cloud-Assisted EHR Sharing With Security and Privacy Preservation via Consortium Blockchain

for EHR sharing to realizing privacy preservation and •We present a cloud-assisted secure and privacy-
data security. Although these works provide promising solu- preserving EHR sharing protocol based on consortium
tions for EHR sharing in cloud environment and pay high blockchain. Only the authorized data requesters who
attention to data security and privacy protection, there still have searching trapdoor are allowed to acquire the key-
remains one severe challenge: the cloud is supposed to be words and related information. Moreover, the autho-
trusted in storing and managing the data. The pattern of cloud- rization and other access services are accomplished by
based EHR sharing relies on third-party which may steal, the blockchain accounts, which ensures identity privacy
leak, tamper or abuse the data once they are under attacks or protection. Also, the cloud re-encrypts the EHR cipher-
lack of monitoring. Despite that many cryptographic primi- text and sends the re-encrypted ciphertext to specified
tives are applied in different schemes [4]–[7], the problem of data requester when they come to an agreement with the
single point failure can’t be solved due to the centralization patient.
characteristic of cloud. The structure of the paper is organized as follows.
Fortunately, blockchain technology as a distributed public An overview on existing works related to our research is
ledger is a prospective solution to figure out security issues presented in section II. Section III gives the key technolo-
in EHR sharing after the cloud-based system [9]. Due to the gies prepared for our scheme. Section IV constructs the sys-
fact that the blockchain is open and transparent, EHR shar- tem architecture, EHR consortium blockchain and analyzes
ing based on blockchain can help patients to control access the threat model and security goals. The data structure and
permission and supervise the utilization of their EHRs. Even consensus mechanism of EHR consortium blockchain are
though blockchain technology has a series of advantages designed in section V. Section VI describes details of the
for building EHR sharing system, we still face the follow- protocol and security proof. Later, we discuss how the pro-
ing challenges: 1) How to achieve data privacy preservation tocol achieves security goals in section VII. Furthermore, we
with EHR searchability in blockchain? 2) How to realize compute the computational overhead and communication
that only the patient and authorized entities can access the overhead and evaluate the performance of our system by
EHR? 3) How to design the data structure and consensus implementing it on Ethereum platform in section VIII.
mechanism of consortium blockchain established by differ- Finally, section IX summarizes the paper and looks ahead to
ent entities to maintain the system running efficiently and the future.
normally?
In order to address the above challenges, we propose a II. RELATED WORK
cloud-assisted blockchain scheme which combines search- In this section, we discuss works that focus on EHR sharing
able encryption and proxy re-encryption technology to real- with the help of cloud technology and blockchain technology.
ize privacy preservation and data security for EHR sharing.
In this work, the keyword ciphertext stored in consortium A. EHR SHARING WITH CLOUD
blockchain ensures users to find expected EHRs and pro- In order to achieve data security during the process of
tects data security with searchability. Besides, the combi- EHR sharing, some access control schemes based on cloud
nation with proxy re-encryption and cloud technology is were introduced in [3]–[5]. A new method of fine-grained
adopted to guarantee that only authorized entities can access access control called ciphertext-policy attribute-based sign-
the EHRs. We also design a suitable data structure and cryption and secure sharing of personal health records in
consensus mechanism of consortium blockchain to ensure cloud computing was proposed in [3]; In [4], an efficient
high-efficiency, reliability, and safety of the entire system. and secure fine-grained access control scheme was pre-
In summary, the contributions of our scheme are threefolds sented which can realize authorized users to access EHRs
as follows. in cloud storage. It supports some specific physicians to
• We propose a new framework for cloud-assisted EHR write on EHRs; [5] proposed a hierarchical comparison-
storage and sharing with privacy preservation and data based encryption scheme and developed a dynamic policy
security based on consortium blockchain. The cloud is updating scheme by using the proxy re-encryption tech-
used to store patients’ EHR ciphertext while the consor- nique to achieve dynamic access control in cloud-based EHR
tium blockchain keeps reocrds of keyword ciphertext for systems.
data searching and sharing. For improving the searchability and interoperability of
• We design the following core components for consor- EHR sharing, [6] proposed a new cloud-based EHR system
tium blockchain: network model, data construction, and supporting fuzzy keyword search for secure data sharing and
consensus mechanism. We define different entities, and effective utilization of the EHRs; [7] utilized conjunctive key-
stipulate their authority according to the demand of our word search with proxy re-encryption to build a secure EHR
system in the network. We design the block structure searching scheme for data sharing between different medical
and transaction structure and incorporate cryptography institutions. Moreover, [8] proposed a general framework for
primitives to store data securely. Furthermore, we put secure sharing of EHRs that patients are allowed to securely
forward proof of authorization as the consensus mecha- store and share their EHR in the cloud server and doctors can
nism for consortium blockchain. access the EHRs in cloud.

VOLUME 7, 2019 136705

 Y. Wang et al.: Cloud-Assisted EHR Sharing With Security and Privacy Preservation via Consortium Blockchain

B. EHR SHARING WITH BLOCKCHAIN Reference [16] presented a blockchain-based system archi-
With the development of blockchain technology, its decen- tecture to achieve an auditable medical data sharing and
tralized, traceability and anonymous characteristics have healthcare data access permission handling. In other aspects,
been widely concerned in applications of medical industry Chen et al. [17] proposed a blockchain-based searchable
issues. At present, many scholars are focusing on the privacy encryption scheme for electronic medical record sharing to
and security in EHR sharing based on blockchain technology. improve data searchability. In this scenario, the construc-
In order to help patients use and share their personal health tion of EHR indexes stored in the blockchain were complex
data conveniently and safely, Amofa et al. [10] presented logical expressions, so that data users can use those logical
a blockchain architecture to realize the security control of expressions to search the indexes. Taking advantage of the
personal data in health information exchange by matching decentralized property of blockchain, data owners had com-
intelligent contracts with user-generated acceptable policies. plete control over who can see their EHRs. The blockchain
The architecture minimized data security risks by designing technology guarantees data integrity, anti-interference, and
a mechanism to control the shared data. X. Zheng et al. [11] traceability.
proposed a conceptual design for personal continuous- Different from the above works, Zhang and Lin et al. [29]
dynamic health data sharing based on blockchain technology. proposed a multi-typed blockchain-based secure and privacy-
It is supplemented by cloud storage, so as to share infor- preserving PHI sharing (BSPP) for diagnosis improvements.
mation related to personal health in a safe and transparent In BSPP, the private blockchain was used to store PHI for
way. In [12], an identity and access management system hospital and the consortium blockchain was responsible for
using blockchain technology to support the authentication recording the secure indexes of the PHI. The scheme used
and authorization of entities in digital systems was pro- public key encryption with keyword search for realizing data
posed. This system described the application of blockchain security and privacy preservation of data sharing on consor-
in Hyperledger Fabric framework for identity authentication tium blockchain.
and access management. Moreover, Guo et al. [14] proposed The aboving works proposed various EHR sharing
an attribute-based signature scheme with multiple authori- schemes from different aspects. Generally, they presented an
ties to ensure the effectiveness of encapsulated EHRs in the idea or concept while without detail solutions for a specific
blockchain. In this scheme, the patient endorsed the message application scenarios. In our work, we combine keyword
according to the attributes and only provided the evidence that searchable encryption and proxy re-encryption technology
he had attested to it. to realize privacy-preserving and secure data sharing for
Some schemes combine cloud technology with blockchain EHR sharing based on consortium blockchain technology
technology to improve the security of EHR sharing. and cloud storage. Furthermore, we design the protocol in
Cao et al. [13] proposed a cloud-assisted secure eHealth details.
system, using blockchain technology to protect outsourced
EHRs in cloud from illegal modification. The key idea III. PRELIMINARIES
of this system was that EHRs can only be outsourced by In this section, we give the technical preliminaries required
authenticated participants. Each operation on the outsourced in this paper.
EHRs was integrated into public blockchain as a transac-
tion. Liu et al. [18] proposed a blockchain-based privacy- A. BILINEAR MAPS
preserving data sharing scheme, namely, BPDS. In BPDS, Let G1 and G2 be two cyclic groups of the same prime order
the cloud was used to store the original EMRs securely q. A bilinear map ê : G1 × G1 → G2 is an admissible bilinear
and a tamper-proof consortium blockchain was designed to map if it satisfies the following properties:
share the EMR indexes. The scheme used this way to reduce 1) ê(aR, bS) = ê(R, S)ab , for all R, S ∈ G1 and a, b ∈ Zq∗ .
the risk of medical data leakage. The use of consortium 2) ê(R, S) = ê(S, R).
blockchian ensures that the EMRs cannot be modified dis- 3) ê(R + S, T ) = ê(R, T )ê(S, T ), for all R, S, T ∈ G1 .
cretionarily. In [19], a storage scheme and service framework 4) ∃R, S ∈ G1 , ê(R, S) 6= 1G2 .
were proposed for storing, sharing and using medical data 5) ê can be efficiently computed.
based on blockchain and cloud. In this scheme, blockchain-
based personal medical data applications can provide a B. COMPLEXITY ASSUMPTIONS
patient medical information service without violating privacy Definition 1: Elliptic Curve Discrete Logarithm Prob-
concerns. lem (ECDLP). We suppose that E is an elliptic curve. The
Another line of work focused on handling the privacy and primitive element is P and X is another element in ellip-
access control of EHR sharing on blockchain. Reference [15] tic curve. Given ]E as the number of points on the curve,
proposed a confidential data sharing model to support per- the ECDLP is looking for the integer b, where 1 ≤ b ≤ ]E,
sonal health record system based on blockchain technol- which satisfies the following:
ogy and proxy re-encryption method. The model solved
three important problems: privacy of on-chain data, lim- P {z· · · + P} = bP = X
| +P+
ited storage for large medical data and consent revocation. b

136706 VOLUME 7, 2019

Y. Wang et al.: Cloud-Assisted EHR Sharing With Security and Privacy Preservation via Consortium Blockchain

In cryptosystems, the private key is usually an integer b D. CONDITIONAL PROXY RE-ENCRYPTION

and the public key X is a point on the curve with coordinates Conditional proxy re-encryption is a scheme which only
X = (xX , yX ). allows the proxy with a re-encryption key to convert cipher-
ECDLP Assumption. It is assumed that it is difficult to text satisfying a concrete condition. The re-encryption cipher-
solve the ECDLP in polynomial time. text encrypted by a delegator’s public key and condition c can
Definition 2: Decision Linear Diffie-Hellman Prob- be decrypted by the delegatee who satisfies the condition c
lem (DLDH). We denote an elliptic curve E and consider with his/her private key. The scheme consists of the following
a cycle group G1 of prime order q. Let P1 , P2 , P3 be algorithms [21].
random elements in G1 and a1 , a2 , a3 random numbers in • Setup(k): Given a security parameter k as input, the algo-
Zq∗ . The DLDH problem is defined as follows: Given a tuple rithm outputs the system’s public parameter.
(P1 , P2 , P3 , a1 P1 , a2 P2 , a3 P3 ) ∈ G1 as input, output 1 if • KeyGen(i): This algorithm generates a public-private
a3 = a1 + a2 and 0 otherwise. We define the advantage of an key pair (pki , ski ) for user.
algorithm A to deciding the DLDH problem in G1 as: • Enc(sks , pki , m): It takes the sender s’s private key,
the receiver i’s public key and plaintext m as input, and
 Pr[A(P1 , P2 , P3 , a1 P1 , a2 P2 , (a1 + a2 )P3 ) = 1] 
 
  returns ciphertext Cm .
Adv1 =  − 
• ReKeyGen(pks , ski , pkj ): The delegator i generates a re-
 Pr[A(P1 , P2 , P3 , a1 P1 , a2 P2 , a3 P3 ) = 1]

encryption key by using his/her private key, the sender


DLDH Assumption. If the probability of any t-time adver- s’s public key and delegatee j’s public key.
• ReEnc(Cm , rk): This algorithm takes as input cipher-
sary successfully solving the problem is Adv1 ≤ ε, where ε
is negligible, it is assumed that it is hard to solve the DLDH text Cm and re-encryption key rk, and outputs the re-
problem in polynomial time. encryption ciphertext Cm0 .
• Dec(Cm 0 , sk ): It takes the re-encryption ciphertext C 0
Definition 3: Modified Decisional Bilinear Diffie-Hellman j m
Problem (m-DBDH). We denote E an elliptic curve and the and delegatee j’s private key as input, and returns the
primitive element is P. Consider cycle group G1 and G2 of plaintext m.
prime order q. The m-DBDH is defined as follows: Given a
tuple (P, cP, dP, T ) ∈ G31 × G2 as input, where c, d ∈ Zq∗ , E. BLOCKCHAIN TECHNOLOGY
decide whether T = ê(P, P)d/c .We define the advantage of Blockchain is an ordered list of records linked together
an algorithm A to deciding the m-DBDH problem as: through a chain on blocks [22]. It is essentially a decentralized
  database, which is a new application mode of distributed data
0
 Pr[A(P, cP, dP, e(P, P)d/c ) = 1]  storage, point-to-point transmission, consensus mechanism,
Adv1 =   
− Pr[A(P, cP, dP, T ) = 1]  encryption algorithm, and other computer technologies. It is
also a distributed ledger that cannot be tampered or forged by
m-DBDH Assumption: If the probability of any t-time using the cryptography method.
adversary successfully solving the problem is Adv01 ≤ ε, Current blockchain systems can be categorized into three
where ε is negligible, it is assumed that it is difficult to decide types: Public blockchain, private blockchain, and consor-
the m-DBDH in probabilistic polynomial time. tium blockchian [24]. Public blockchain is permissionless
blockchain where all records are visible to the public and
C. PUBLIC KEY ENCRYPTION WITH CONJUNCTIVE anyone can take part in the system and access informa-
KEYWORD SEARCH tion, for example, Bitcoin, Ethereum. A private blockchain
The public key encryption with conjunctive keyword search is regarded as a centralized network since an organiza-
enables data requesters to search a document containing tion fully controls the system. Consortium blockchain is
several keywords over a public key encryption setting. The a partially decentralized system since it is managed by
scheme is defined as following algorithms [20]. several organizations. In consortium blockchain, only those
• KeyGen(1k ): Given a security parameter 1k as input, nodes that come from authorized organizations can access
it outputs public/private key pair (pk, sk). data in blockchain. In our work, we conduct EHR data
• PECK (pk, W ): It selects a keyword set W = sharing on consortium blockchain. Several hospitals con-
{w1 , w2 · · · , wn }. It uses the public key to produce a stitute an alliance and create a consortium blockchain,
searchable keyword encryption Cw for W . which keeps records of secure indexes for patient’s
• Trapdoor(sk, Q): It takes the receiver’s private key sk EHR.
and the keyword query Q = (1 , 2 , · · · , t ) as input, In blockchain, the way to reach consensus among
and computes the trapdoor TQ for the conjunctive search untrust-worthy nodes in distributed environment is called
of a given keyword query. consensus mechanism. The consensus mechanism is the
• Test(pk, Cw , TQ ): It takes as input the public key pk, core of blockchain technology. Proof of work, proof
searchable keyword encryption Cw and the trapdoor TQ . of stake, practical byzantine fault tolerance and some
If Q is included in Cw , the server outputs ‘‘yes’’, other- other consensus mechanism have been proposed for
wise ‘‘no’’. blockchain [24]–[28].

VOLUME 7, 2019 136707

 Y. Wang et al.: Cloud-Assisted EHR Sharing With Security and Privacy Preservation via Consortium Blockchain

FIGURE 1. System model.

IV. SYSTEM MODEL they encrypt the health record and upload files to cloud
In this section, we present the architecture for cloud-assisted server. Afterwards, they conduct a data transaction consisting
consortium blockchain for EHR storing and sharing system. of keyword ciphertext for EHR and DO’s account address and
And then, we analyze the threats and put forward our security send it to the transaction pool. They act as data transaction
goals. senders in blockchain, as shown in Fig. 2. If a new DP wants
to join the blockchain, he/she has to take three steps:
A. SYSTEM ARCHITECTURE • Register an account in EHR consortium blockchain.
There are five entities in the proposed framework: Data own- • Submit a recommendation letter signed by one commis-
ers (DO), data providers (DP), cloud server (CS), blockchain sioner and send it to all of the commissioners.
(BC), data requesters (DR), as shown in Fig. 1. • Get at least 2/3 of the authorizations from

1) DATA OWNERS commissioners.

Date owners refer to patients who visit doctors in hospitals
3) CLOUD SERVER
or medical institutions for medical service. The electronic
health records including data of individual privacy will be Cloud server is in charge of storing encrypted EHR provided
produced after their interactions. As the source of health by DP. It is also responsible for sending the file location to
record, DO has the ownership and control rights for the DO’s account in EHR consortium blockchain. It is honest but
data. They must register an account for data sharing on EHR curious about the data. In addition, it takes responsibility for
consortium blockchain. The DP can upload health record to re-encrypting EHR using re-encryption key.
cloud after getting DO’s authorization. Data requesters need
DO’s permission for accessing the data. 4) DATA REQUESTERS
Data requesters refer to government, laboratory, clinic, and
2) DATA PROVIDERS so on, who need to access patient’s EHR. They have to get
Data providers are doctors or administrators of hospitals who search trapdoor from DP and search for keywords in the
manager EHRs. When receiving a patient’s authorization, blockchain at first, and then send a request to DO after getting

136708 VOLUME 7, 2019

Y. Wang et al.: Cloud-Assisted EHR Sharing With Security and Privacy Preservation via Consortium Blockchain

Once getting the appointment, they will gather data transac-

tion and service transaction from transaction pool and pack
them into a block. Then, they sign the block and send them
to all of the commissioners. When a valid block is added to
blockchain network, they will get the deserved reward.

3) DATA TRANSACTION SENDERS

Data providers undertake the responsibility of data transac-
tion sender. They were introduced in system architecture.
FIGURE 2. EHR consortium blockchain network.
4) SERVICE TRANSACTION SENDERS
search result. Once they get DO’s authorization, they Data requesters undertake the responsibility of service trans-
will receive the re-encrypted health record from cloud action sender. They were introduced in system architecture.
server. Their operation will generate service transactions that
will be put into transaction pool, thus they act as service C. THREAT MODEL AND SECURITY GOALS
transaction senders in blockchain, as shown in Fig. 2. They In our scheme, cloud servers are semi-trusted. It is honest
can join or exit blockchain network anytime as the ordinary but curious about electronic health record. They may try
users. They can see the whole consensus process and enjoy to decrypt the ciphertext. Some malicious opponent may
the services of the system. intercept, modify or counterfeit the health records during the
transmissions. The cloud and data requesters may collude to
B. CONSTRUCTION OF EHR CONSORTIUM BLOCKCHAIN deduce the plaintext of EHR.
The proposed EHR consortium blockchain is composed by Considering the above threat model, security goals are as
blocks which include keyword ciphertext, DO’s account follows:
address, DP’s signatures, and so on. In the blockchain, dif- 1) DATA CONFIDENTIALITY AND INTEGRITY
ferent members have different access right. Data requesters The patient’s health records can’t be read or modified by other
can perform keyword search and send data access request entities without data owner’s authentication, whatever it is
transactions to blockchain for data sharing. In blockchain net- stored in cloud server or transmitted in the public channel.
work, the nodes should achieve a consensus to generate new
blocks. Patients’ information is in ciphertext and unlinked to 2) ACCESS CONTROL
their identities, hence the blockchain can protect their privacy The data owners have the ability to control the data access.
effectively. Only getting the data owner’s authorization can other entities
The EHR consortium blockchain is composed by four dif- access the health records.
ferent nodes: commissioner (trusted authority), miner (data
administrator), data transaction sender (data provider), ser- 3) AUTHENTICATION
vice transaction sender (data requester), as show in Fig. 2. Data owners should be able to authenticate data providers to
ensure that health records come from reliable resource. Data
1) COMMISSIONERS requesters could be authenticated to guarantee legitimate use
Several hospitals, clinics and medical center constitute an of data. The cloud server should be able to authenticate data
alliance committee and create a EHR consortium blockchain. owner, data provider, and data requester.
Each organization owns a commissioner as the member of
the alliance committee to execute their decisions. The com- 4) SECURE SEARCH
missioner is responsible for recommending and approving Data requesters need to get DP’s authentication to search
new data administrator, data provider and verifying valid interested content in the EHR consortium blockchain. The
transactions and blocks. Each commissioner have equal status same keyword in different searching is unlinkability such that
in whole network. In practice, the commissioner can act as the eavesdroppers can’t speculate whether two or more EHRs
data administrator or data provider. Every block is sent to all come from the same source.
of the commissioners for verification after at least 2/3 of the
5) PRIVACY PRESERVATION
authorizations are received, the block will be marked as valid
block. Data owner’s identity information can’t be revealed with EHR
and account address. Moreover, the original EHR can’t be
2) DATA ADMINISTRATORS revealed to illicit entities.
Data administrators are generated by random selecting from
commissioners as a miner in the blockchain. They take charge 6) COLLUSION RESISTANCE
of packing transactions and producing blocks. Each coopera- Even if an entity colludes with the cloud server, they
tive organization must provide at least one data administrator can’t access the original EHR without access permission.
candidate for maintaining normal operation of blockchain. Besides, the DO and CS can’t collude to decrypt the EHR.

VOLUME 7, 2019 136709

 Y. Wang et al.: Cloud-Assisted EHR Sharing With Security and Privacy Preservation via Consortium Blockchain

in Fig. 3. Service content may vary from keyword search,

exchanging some information between two accounts, sending
access request to one’s account, and so on. In particular,
a valid service transaction must have legal sender and valid
receiver. This measure helps to reduce junk information in
transaction pool and keep the network running normally and
efficiently.

B. CONSENSUS MECHANISM
(PROOF-OF-AUTHORIZATION)
We propose a consensus mechanism, named proof of autho-
rization, to build the regulation for consortium blockchain
and ensure high-efficiency, reliability and safety of the
blockchain network as shown in Fig. 4.
Assume that the number of commissioners is Nc . We assign
FIGURE 3. Data structure. a random number M ∈ [0, Nc − 1] to each commissioner in
system setup. The system generates a random number M 0 ,
Moreover, any two data requesters can not speculate the 0 ≤ M 0 < N c , appoints the matched commissioner as data
information of EHR combined with the search trapdoor. administrator, and produces block in this round. The network
will inspect the number of commissioners at next round of
consensus and redistribute the number to them.
V. EHR CONSORTIUM BLOCKCHAIN DESIGN
When a data provider sends data to the EHR consortium
A. DATA STRUCTURE
blockchain, the data transaction will be stored in the trans-
1) BLOCK STRUCTURE
action pool at first. In the same way, when data requester
In our scheme, a valid block is composed of block header, submits a request, service transaction will be put into the
block body, data administrator’s signature, and timestamp, transaction pool. The appointed data administrator packages
as show in Fig. 3. Block header contains five components: x data transactions and y service transactions into a block.
Block ID, block size, previous block hash, random number, Then the block is sent to all of the commissioners.
and merkle root. Block ID is used for tracking software or If a commissioner verifies the block’s validity and agrees
protocol updating which is unique for each block; block size to authorize the block, he/she will sign the block and return
shows how much storage space the block takes up; previous the signature to the data administrator. After receiving at least
block hash is used to link previous block for avoiding modifi- 2/3Nc signatures, data administrator signs on the block and
cation; random number is used for appointing the next miner; sends it to the NTP server. The NTP server provides the
merkle root is a digital fingerprinting of the transactions set current timestamp, signs and encrypts the new block, then
from the block body [23]. Block body has two parts: x data returns the timestamp and signature to the data administrator.
transactions and y service transactions (The optimal design of At last, the data administrator generates another random
this quantity is beyond the scope of this article). Data transac- number M 0 ∈ [0, Nc −1] that determines who will be the next
tion is made up of encrypted EHR and relevant information data administrator for producing new block and broadcasts
generated by authorized data provider; service transactions to other nodes which can verify the time information of the
include keyword search, access request, and authorization etc. block. If the total time of the process is less than specified
data administrator’s signature helps to track the generator of time Tmax , the block is finally valid. Otherwise, the permis-
the block. Timestamp indicates the generation time of the sions of producing this block will be turned over to the data
block. administrator M 0 + 1(0 ≤ M 0 < Nc − 1). When a valid block
is generated, it means that a round of consensus is finished.
2) TRANSACTION STRUCTURE
Data transaction is made up of transaction ID, transaction VI. PROPOSED PROTOCOL
type, keyword ciphertext, DO’s account, and DP’s signature In this section, we first present an overview of the proposed
as show in Fig. 3. Transaction ID can help to track source of protocol for cloud assisted EHR sharing with security and
the transaction; transaction type distinguishes different trans- privacy-preservation based on EHR consortium blockchain.
actions to guarantee efficient operations; keyword ciphertext After that, we describe the proposed protocol in details and
is provided for data searching; access request is sent to the security proof.
DO’s account for getting the access authorization; DP’s sig-
nature provides proof of transaction’s validity. A valid data A. OVERVIEW
transaction are required by all of the above information. The process of the proposed protocol is represented in Fig. 5.
Service transaction consists of transaction ID, transaction The protocol is made up of three layers: Data generation layer,
type, service content, sender ID, and receiver ID as show data storage layer, and data sharing layer.

136710 VOLUME 7, 2019

Y. Wang et al.: Cloud-Assisted EHR Sharing With Security and Privacy Preservation via Consortium Blockchain

FIGURE 4. Consensus process.

FIGURE 5. Protocol.

When a patient (DO) i with identity Ii arrives at a hospital and private key generated by the EHR consortium blockchain
for a medical service, he/she needs to register an account will be sent to the patient. The patient i sents data packet
in the EHR consortium blockchain. An account address Ai ϑ0 = (Ii k Ai ) to a doctor k. The original EHR m for patient

VOLUME 7, 2019 136711

 Y. Wang et al.: Cloud-Assisted EHR Sharing With Security and Privacy Preservation via Consortium Blockchain

TABLE 1. Algorithm 1 : Data Generation DataGen(m, xk , pki , wi ).

TABLE 2. Algorithm 2 : Keyword Index Generation KeyInGen(W = w1 , w2 , · · · , wn , params).



i will be generated after interacting with the doctor (DP) k. TABLE 3. Algorithm 3 : Trapdoor Generation
TrapdoorGen( = (1 , 2 , · · · , t ), xk ).
The DP extracts a series of keyword wi from the EHR. Then,
the DP encrypts m with the patient’s public key pki , the DP’s
private key xk and keyword wi , getting the EHR ciphertext
Cm . In addition, it encrypts wi with the DP’s public key Xk
producing keyword ciphertext Cw . After that, the DP sends
data packet ϑ1 = (Cm k Cw k Ai ) to cloud server. The
file location Fi will be sent to the DO’s account when the
cloud server finished storing the data safely. Meanwhile,
the DP sends data packet ϑ2 = (Cw k Ai k Ck ) to the
EHR consortium blockchain, where Ck is DP’s signature for
proof of conformance. Also, DP uses keywords w and his/her collision-resistant hash function: H1 : {0, 1}∗ → G1 , H2 :
private key xk to produce a trapdoor TQ for keyword search. {0, 1}∗ × G1 × G1 → G1 , H3 : {0, 1}∗ → Zq∗ . Furthermore,
If government, laboratory or clinic (DR) would like to the DP randomly selects three parameter g1 , g2 , g3 ∈ Zq∗ , and
search for some EHR, they first submit a search request to computes P1 = g1 P, P2 = g2 P, P3 = g3 P as the secret
the DP. If the request is allowed, they will get a trapdoor key of the system. Additionally, the DP randomly chooses
TQ . Then the DR can find out the matched EHR and obtain xk ∈ Zq∗ as the master private key and computes the public key
the DO’s account address Ai by searching on the blockchain Xk = xk P. Set ĥ = ê(P, P). Finally, the system parameters is
with TQ . Afterwards, they can send data packet ϑ3 = (Ij k published as params = (q, P, ê, G1 , G2 , H1 , H2 , H3 , Xk , ĥ).
pkj k Xk k Aj ) to the DO’s account for access request. Registration: Both the DO and the DR register to DP
When the DO receives data request notification, they will for joining the system. The DO randomly chooses number
send an authorization including file location Fi and keyword xi ∈ Zq∗ as his/her private key ski and computes Yi = xi P
wi to DR’s account. Additionally, it generates a re-encryption as his/her public key pki . The DR randomly selects xj ∈ Zq∗
key rk and transmits it to CS, who carries out proxy re- as his/her private key skj and computes Yj = xj P as his/her
encryption for the required ciphertext. Finally, the DR uses public key pkj .
his/her private key skj to decrypt the re-encrypted ciphertext Phase 2: Data Storage and Index Generation
Cm0 . Data Generation: When a DO i visits a hospital and inter-
acts with a DP k, the original EHR m ∈ {0, 1}∗ will be
generated. The DP encrypts m with his/her private key xk ,
B. PROTOCOL DESCRIPTION the DO’s public key pki and the keyword wi to generate EHR
The proposed protocol is composed of three phases: System ciphertext Cm by performing Algorithm 1.
setup and registration, data storage and index generation, data Keyword Index Generation: The DP k selects a keyword
sharing. set W = {w1 , w2 , · · · , wn } for original EHR and two ran-
Phase 1: System Setup and Registration dom values u, v ∈ Zq∗ . It computes the searchable keyword
System Parameter Generation: Given a security parameter ciphertext Cw = (A, B, C1 , C2 · · · , Cn ) by performing Algo-
k, the DP generates a prime q and selects a bilinear pairing ê : rithm 2.
G1 ×G1 → G2 , where G1 is an additive cycle group and G2 is When DP finished data and index generation, the data
a multiplicative cycle group with the same prime order q. P is packet ϑ1 = (Cm k Cw k Ai ) is stored in cloud server and
the generator of G1 . The DP chooses three different one-way ϑ2 = (Cw k Ai k Ck ) is formated as a data transaction.

136712 VOLUME 7, 2019

Y. Wang et al.: Cloud-Assisted EHR Sharing With Security and Privacy Preservation via Consortium Blockchain

TABLE 4. Algorithm 4 : Re-encryption key Generation ReKeyGen(ski , Xk , H3 (i ), pkj , Fi ).

TABLE 5. Algorithm 5 : Re-encryption ReEnc(Cm , rk).

t t
Phase 3: Data Sharing X mX
= ê(vP, m hi ) · ê(uxk P, fi )
Keyword Search: The DP generates a keyword set  = xk
i=1 i=1
(1 , 2 , · · · , t ) searching trapdoor TQ for DR to search
= ê(A, TQ2 ) · ê(B, TQ3 )
desired keyword on the consortium blockchain after receiv-
ing the search request from DR. The trapdoor TQ = Data Access: When the DR gets the DO’s account address
(TQ1 , TQ2 , TQ3 ) is generated by using DP’s private key as Ai , he/she will send data packet ϑ3 = (I j k pkj k Xk k Aj ) for
Algorithm 3. access request to the DO’s account address Ai . After getting
After getting keyword searching trapdoor, the DR searches the access request notification, the DO transmits data packet
keyword in the secure indexes on the EHR consortium ϑ4 = (H3 (wi ) k Fi ) for authorization to DR’s account address
blockchain to find out the indexes for DO i. The test algo- Aj and generates re-encryption key rk = (rk1 , rk2 ) for cloud
rithm is executed on the blockchain by checking the equality server, where rk1 and rk2 are calculated by Algorithm 4.
t
Then the re-encryption key rk is sent to the cloud server to
ê(TQ1 ,
P
Ci ) = ê(A, TQ2 ) · ê(B, TQ3 ). If the equation holds,
i=1 re-encrypt the ciphertext from DP.
the blockchain outputs ‘‘yes’’ to the DR and sends DO’s Upon receiving the re-encryption key, the cloud server car-
account address Ai to him/her. Otherwise, it aborts. ries out the Algorithm 5 to generate a re-encrypted ciphertext
Correctness: We assume that the i in the keyword trap- Cm0 .
door TQ and wi in the ciphertext are equal, the correctness of Then, the cloud server sends the re-encrypted ciphertext
the test algorithm is verified as: Cm0 = (c01 , c02 , c03 , c04 , c05 , c06 ) to DR’s account. The DR j is able
to decrypt the re-encrypted ciphertext with his/her private key
t
X t
X according to Algorithm 6
ê(TQ1 , Ci ) = ê(mP, (vhi + ufi )) Correctness: The correctness of the Algorithm 6 is veri-
i=1 i=1 fied as:
t t r
X X c02 mĥ xk
= ê(mP, v hi + u fi ) m̃ = = =m
i=1 i=1 (c03 )1/skj rxj H3 (Fi )
xk · x H 1(F )
t t
ĥ j 3 i
X X ê(c04 , P) = ê(r(H3 (m)P1 + P2 ), P)
= ê(mP, v hi ) · ê(mP, u fi )
i=1 i=1 = ê(rP, H3 (m)P1 + P2 )

VOLUME 7, 2019 136713

 Y. Wang et al.: Cloud-Assisted EHR Sharing With Security and Privacy Preservation via Consortium Blockchain

= ê(c06 , H3 (m)P1 + P2 ) 0 , sk ).
TABLE 6. Algorithm 6 : Decryption Dec(Cm j

X t
ê(c01 , P) = ê(r H3 (wi )P, P)
i=1
t
X
= ê(rP, H3 (wi )P)
i=1
t
X
= (c06 , H3 (wi )P)
i=1

C. SECURITY PROOF encrypted by the DP’s public key. Thus, DP can control data
Theorem 1: The proposed PEKS is secure against IND- search.
CR-CKA in the random oracle model assuming the DLDH Moreover, when DO agrees DR to access his/her data,
assumption holds in G1 . he/she will send them a packet which contains file location
The PEKS includes system setup and registration, Algo- and keyword. Meanwhile, DO generates a re-encryption key
rithm 2, Algorithm 3. The security model of indistinguisha- rk and sends it to CS for performing proxy re-encryption.
t
bility of ciphertext from random against chosen keyword Note that in rk = (rk1 , rk2 ), rk1 = sk1i ( H3 (i ))Xk , rk2 =
P
attacks (IND-CR-CKA) is the same as [20]. i=1
1
Proof: See Appendix A. ski pkj H3 (Fi ), which are related to DO’s private key, DP’s and
Theorem 2: The proposed CPRE is IND-CCA secure in DR’s public key, file location, and keyword. In this way, only
the standard model assuming the m-DBDH assumption is the authorized DR can decrypt the re-encrypted ciphertext.
intractable. Therefore, DO is able to control the access of his/her data.
The CPRE includes system setup and registration, Algo-
rithm 1, Algorithm 4, Algorithm 5, Algorithm 6. The secu- 3) THE PROPOSED PROTOCOL CAN ACHIEVE
rity model of indistinguishability under Chosen Ciphertext AUTHENTICATION
Attacks (IND-CCA) is the same as [21]. Our scheme can achieve both identity authentication and data
Proof: See Appendix B. authentication. The EHR consortium blockchain network dis-
tinguishes different nodes and their legality. DR can affirm
VII. SECURITY ANALYSIS whether the ciphertext sent by CS is the expected data by
In this section, we demonstrate how the proposed protocol examining whether he/she has the ability of decrypting the
achieves the security goals effectively. ciphertext. The re-encryption key is generated by DO’s pri-
vate key, DP’s and DR’s public key, file location and keyword.
1) THE PROPOSED PROTOCOL CAN ACHIEVE DATA It ensures that only the EHR ciphertext which is stored in
CONFIDENTIALITY AND INTEGRITY designated location and encrypted by DO’s public key can be
DP encrypts EHR with his/her private key, DO’s public key re-encrypted. Only the authorized DR can decrypt the target
and a series of keywords extracted from the EHR before send- ciphertext by using his/her private key with right file location
ing them to cloud server. So the ciphertext can’t be decrypted and keyword.
without DP’s public key, DO’s private key and keywords. The
private key is secure under ECDLP assumption. In addition, 4) THE PROPOSED PROTOCOL CAN ACHIEVE SECURE
only the entity that gets DO’s authorization is allowed to SEARCH
access the data from cloud server. In practice, DO generates The keywords for searching are encrypted by DP’s public
a re-encryption key with DR’s public key, keyword, and file key in consortium blockchain. DR has to get a searching
location. Then cloud server re-encrypts the EHR ciphertext trapdoor from DP for searching target keyword. So, during
with re-encryption key. Thus, only the intended DR can the process of DR searching, other entities can’t know the
decrypt the ciphertext, which enhances data confidentiality. search keywords and the searching result. According to The-
Furthermore, the signatures in each block can achieve data orem 1, our scheme is IND-CR-CKA secure in random ora-
integrity. cle model. The attackers can’t find the relationship between
encrypted keyword and searching trapdoor even though they
2) THE PROPOSED PROTOCOL CAN ACHIEVE ACCESS get the trapdoor. As our scheme is IND-CCA secure in the
CONTROL standard model, according to Theorem 2, the cloud server
In our system, DP sends a keyword trapdoor TQ to authorize only executes proxy re-encryption for prescriptive original
DR for keyword searching in EHR consortium blockchain. ciphertext and sends it to specific DR. It is not allowed to
t obtain any information about original EHRs. Furthermore,
As TQ = (TQ1 , TQ2 , TQ3 ) = xmk
P
fi , it includes DP’s private
i=1
DP is only authorized to access keywords without revealing
key. It is used for searching the matched keywords which are other information.

136714 VOLUME 7, 2019

Y. Wang et al.: Cloud-Assisted EHR Sharing With Security and Privacy Preservation via Consortium Blockchain

5) THE PROPOSED PROTOCOL CAN ACHIEVE TABLE 7. Configurations of ethereum test blockchain.
PRIVACY PRESERVATION
In the process of data transmission, the entity sends and
receives data packets via his/her account in blockchain. The
blockchain account is anonymous and unlinkable to real
identity. So, the anonymity of blockchain can protect the
public information from divulging the real identity of entities.
Besides, during the process of keyword search, it will not
reveal any information about DO. During the process of proxy
re-encryption, the CS can’t deduce the real identity of DO
from the EHR ciphertext and re-encryption key.
6) THE PROPOSED PROTOCOL CAN ACHIEVE COLLUSION find all the schemes can achieve the properties of access
RESISTANCE control and privacy preservation, which is crucial security
On the one hand, the EHR ciphertext is encrypted by DP’s objectives in EHR sharing system.
private key, DO’s public key, and keyword. Even though DR
colludes with CS, they can’t decrypt any information from the C. COMMUNICATION OVERHEAD
ciphertext because they do not have DO’s private key. On the We donate |G1 |, |G2 | the size of an element in group G1
other hand, the re-encryption key is generated with DR’s and G2 , |Q| the size of the elements in Zq∗ , |σ | the size of
and DP’s public key, file location and keyword, so the re- signatures. The size of blockchain account is 32 bytes. The
encryption ciphertext can’t be decrypted without DR’s private communication overhead is generated during the process of
key. Thus, illegal DR isn’t able to collude with CS to access data generation, keyword search, and data access. At the data
the data. generation phase, the communication overhead between DP
and CS comes from data packet ϑ1 . The packet ϑ1 is made
VIII. IMPLEMENTATION AND PERFORMANCE
up of Cm , Cw and Ai , the total length is (n + 4) |G1 | +
EVALUATION
(n + 1) |G2 | + 3 |Q| +32 bytes. Additionally, the communi-
In this section, we firstly illustrate the parameters setting cation overhead between DP,DO, and DR is caused by ϑ2 ,
and platform setting and compare the security properties of which is composed of Cw , Ai and Ck . The length of ϑ2 is
the proposed scheme with other schemes. Then, we analyze (n + 2) |G1 | + n |G2 | + |σ | +32 bytes. During the process
the communication overhead of the proposed protocol and of keyword search, the communication overhead of DR is
compare it with another scheme. Finally, we implement the 2 |G1 | + |G2 | bytes. At the data access phase, the commu-
proposed scheme on Ethereum platform and evaluate its per- nication overhead is 6 |G1 | + 3 |G2 | + 2 |Q| + 64 bytes, which
formance. is caused by ϑ3 , ϑ4 , rk and Cm0 , as shown in Table 9.
A. PARAMETERS AND PLATFORM SETTING We compare our communication overhead with Zhang [29].
The system parameter k = 128. We use Type A pairing on From Table 9, we can find that our communication costs
the elliptic curve y2 = x 3 + x over the field Fp for some in the process of data access is higher than in Zhang [29].
prime p = 3 mod 4, the same setting as [29].The crypto- Nevertheless, in the process of data generation and keyword
graphic primitives are implemented using Java language on search, our communication overhead is lower. This is because
a computer with Intel(R)Core(TM)i5-6500 CPU @ 3.20GHz we use account on the blockchain in replace of pseudo iden-
3.19GHz, 4.00 GB RAM, Windows 10 operating system. tity. Moreover, our scheme store EHR ciphertext in cloud that
We use Ganache(client version) to build a private test avoids the communication overhead of proof of conformance
blockchain on macOS system. The data is written into in the private blockchain.
smart contracts by using solidity language and uploaded
to the Ethereum blockchain. The solidity compiler is D. IMPLEMENTATION AND COMPUTATIONAL OVERHEAD
solc@ 0.4.25 and the smart contracts test framework is In order to quantify the operation time, we evaluate the per-
[email protected]. Since solidity can not output the time cost of formance of cryptographic primitives on the platform shown
publishing smart contracts to blockchain, the Web3js library in section VIII.A. We record the computational overhead of
of Nodejs(Node is a development platform that lets JavaScript algorithms by setting different keyword amounts in Table 10.
run on the server side) is used to interact with smart contracts In our protocol, the system setup and registration phase
on the blockchain and test the time cost of sending transac- are simulated by the algorithm BuildSystem. The DataGen
tions. The specific configurations are shown in Table 7. algorithm is used to encrypt original EHRs and gener-
ate ciphertext Cm . The KeyInGen algorithm is responsi-
B. COMPARISONS OF SECURITY PROPERTIES ble for generating searchable keyword ciphertext Cw . The
We compared the security properties of the proposed scheme DR gets keyword searching trapdoor TQ from DP, searches
with cloud-based schemes Liu [3], Wang [7], and blockchain- the expected keyword and the matching test is executed in
based schemes Sandro [10], Liu [18]. From the table 8, we can KeywordSearch algorithm. The re-encryption key rk and

VOLUME 7, 2019 136715

 Y. Wang et al.: Cloud-Assisted EHR Sharing With Security and Privacy Preservation via Consortium Blockchain

TABLE 8. Comparison of security properties.

TABLE 9. Comparison of the communication overhead among different schemes.

TABLE 10. Computational overhead of cryptographic algorithms(in ms).

re-encrypted ciphertext Cm0 are generated by algorithms TABLE 11. Time cost and gasUsed of transactions.
ReKeyGen and ReEnc respectively. The ciphertext Cm0 is
decrypted by Dec algorithm.
Due to the fact that computational overhead of some algo-
rithms are related to keyword amounts, we implement the
algorithms by setting n = 10, n = 50, and n = 100,
respectively. From table 10, we can find out that the time
cost of DataGen, KeyInGen, KeywordSearch and ReKey-
Gen algorithms increase with the size of keyword amounts. of data package. So, the amounts of the keyword set should
Because these algorithms contain keyword information and not be too large to improve the efficiency of the transactions.
carry out some calculation about hash function of keyword. Furthermore, the gas consumption increases with the increase
However, the BuildSystem, ReEnc and Dec algorithms are of the length of data package. But, the consumption of gas is
not affected by keyword set. small and acceptable.
The length of data package is a critical factor affecting the
time cost of sending a transaction in the blockchain. Accord- IX. CONCLUSION
ing to section VIII.C, the length of data package ϑ2 in key- In our work, we have proposed a blockchain-based EHR shar-
word index generation phase is (n+2) |G1 |+n |G2 |+|σ | +32 ing scheme with conjunctive keyword searchable encryption
and ϑ3 , ϑ4 in data sharing phase is 6 |G1 |+3 |G2 |+2 |Q|+64. and conditional proxy re-encryption to realize data security
The |G1 |, |G2 |, |σ |, |Q| are 64 bytes, 384 bytes, 32 bytes, and privacy preservation of data sharing between different
and 32 bytes respectively. Thus, the size of transactions medical institutions. Firstly, we present a framework for EHR
Tx1 = 448n + 192 bytes and Tx2 = 1664 bytes. As the Tx1 is sharing among different entities based on cloud-assisted stor-
related to keyword amounts n, we implement the transactions age and blockchain. The cloud is in charge of storing EHR
on Ethereum platform by setting n = 10, n = 50, and ciphertext while EHR indexes are kept on EHR consortium
n = 100. The time cost are shown in table 11. blockchain. Secondly, the network model, data structure and
From table 11, we can know that the time cost of sending consensus mechanism for EHR consortium blockchain are
transactions to the blockchain is proportional to the length designed to guarantee efficient operations of the system.

136716 VOLUME 7, 2019

Y. Wang et al.: Cloud-Assisted EHR Sharing With Security and Privacy Preservation via Consortium Blockchain

Moreover, we use keyword searchable encryption to ensure 1) C executes the above algorithms for responding H1 ,
data security with searchability and employ conditional proxy H2 queries to get two lists (wi,j , ci,j , hi,j , ui,j ) and
re-encryption to realize data sharing with privacy preserva- (wi,j , ci,j , fi,j , vi,j ).
tion. Furthermore, we conduct security analysis and proof 2) if there is any ci,j = 1 for 1 ≤ j ≤ n, then
security of the proposed protocol, which demonstrates that C aborts. Otherwise, it picks a random number
our scheme can achieve the designed security goals. We also zi ∈ Zq∗ and computes TQi = (TQi,1 , TQ!i,2 , TQi,3 )
implement the scheme on Ethereum platform and evaluate the P t
performance of computational overhead and communication where TQi,1 = zi P1 , TQi,2 = zi ui,j P1 and
j=1
overhead. !
t
For future work, we will implement the scheme on Hyper- TQi,3 = zi
P
vi,j P1 .
ledger Fabric and perfect smart contracts for running the j=1
algorithms of data sharing. • Challenge: A outputs a target keyword set W ∗ and sends
it to C. C performs as follows:
APPENDIX
1) It chooses a keyword set W 0 randomly and sets
A. SECURITY PROOF OF THEOREM 1
W0 = W ∗ and W1 = W 0 where W0 = {0,1 ,
Suppose that A is an outsider adversary with advantage ε in · · · , 0,n }, W1 = {1,1 , · · · , 1,n }. The only
attacking the proposed protocol against IND-CR-CKA and restriction is that the previous trapdoors can’t dis-
H1 (·), H2 (·) the role of random oracles. We build a challenger tinguish W0 and W1 .
C who can compute the solution of the DLDH problem by 2) It picks a random number β ∈ {0, 1} and queries
playing game with A as follows. all keywords of Wβ to H1 , H2 oracles. Then it gets
• Setup: Given the DLDH parameters (P1 , P2 , P3 , Q1 , lists (wβ,i , cβ,i , hβ,i , uβ,i ) and (wβ,i , cβ,i , fβ,i , vβ,i ).
Q2 , Q3 ) where Q1 = a1 P1 , Q2 = a2 P2 and 3) If there is any cβ,i = 1 for all i, it computes a
Q3 = (a1 + a2 )P3 or z. Challenger C randomly chooses challenge ciphertext Cw0 = (A, B, Cβ,1 , · · · Cβ,n )
x ∈ Zq∗ as the DP’s private key and computes y = xP1 . where A = a1 P1 , B = αa2 P2 and Cβ,i = uβ,i Q1 +
Additionally, it picks a number α ∈ Zq∗ randomly and αvβ,i Q2 (if cβ,i = 0) or Cβ,i = uβ,i Q3 (if cβ,i = 1).
keeps it secretly. Then, it sends A the system parameters Otherwise, it aborts.
params = (G1 , G2 , ê, H1 (·), H2 (·), P) and the public 4) Returns (W0 , W1 , Cw0 ) to A.
key pk = y while the x is unknown for A. • Phase 2: A performs trapdoor queries as in phase 1. The
H1 queries: C maintains a list of tuples (wi , ci , hi , ui ) restriction is that the generated trapdoor is indistinguish-
called H1−list for responding the queries of H1 . A able for W0 and W1 .
queries the random oracle H1 at most qm keyword. When • Guess: A outputs a guess β 0 ∈ {0, 1}. The challenger C
receiving the queries, challenger C responds as follows: will win the game if β = β 0 , which means Q3 = (a1 +
1) If the query wi already in H1−list , C responds a2 )P3 . Otherwise, it will lose, which means Q3 = z.
hi = H1 (wi ). Otherwise, it generates a random In the guess phase, if Q3 = (a1 +a2 )P3 , which means the
ci ∈ {0, 1}. challenge ciphertext is a valid encryption of the keyword
2) If ci = 0, C selects a random number ui ∈ Zq∗ and set Wβ . In this case, the view of A is the same as the
computes hi ← ui P1 . Otherwise, it sets hi ← ui P3 . view in a real attack and it must have probability 1/2 + ε
3) C adds the tuples (wi , ci , hi , ui ) to H1−list and at least. Thus, the challenger C’s advantage to solve the
returns hi to A. DLDH problem is ε1 ≥ ε.
H2 queries: C maintains a list of tuples (wi , ci , fi , vi )
called H2−list for responding the queries of H2 . When B. SECURITY PROOF OF THEOREM 2
A queries the random oracle H2 , challenger C responds Suppose that A is an adversary with advantage ε0 in attack-
as follows: ing the proposed protocol against IND-CCA. We build a
1) If the query wi is already in H2−list , C responds challenger C who can compute the solution of the m-DBDH
fi = H2 (wi ). Otherwise, it generates a random problem by playing game with A as follows.
ci ∈ {0, 1}. • Setup: Given a security parameter k, challenger C
2) If ci = 0, C selects a random number vi ∈ Zq∗ and generates the system parameters params = (q, P, G1 ,
computes fi ← vi P2 . It computes vi = uαi and sets G2 , ê, ĥ, t1 , t2 , t3 , H ) and sends it to A, where
fi ← vi P3 . ĥ = ê(P, P), t1 = r1 P, t2 = r2 P, t3 = r3 P
3) C adds the tuples (wi , ci , fi , vi ) to H2−list and for randomly choosing three numbers r1 , r2 , r3 ∈ Zq∗ ,
returns fi to A. H : {0, 1}∗ → Zq∗ is a one-way collision-resistant hash
• Phase 1: A queries some keyword set to trapdoor oracle. function.
Trapdoor queries: A adaptively queries a keyword set • Phase 1: A makes some queries.
Qi = (i,1 , · · · , i,t ) to get a trapdoor TQi . C responds Public key queries: challenger C randomly picks
as follows: xk ∈ Zq∗ and dk ∈ {0, 1}. If dk = 1, C chooses skk = xk

VOLUME 7, 2019 136717

 Y. Wang et al.: Cloud-Assisted EHR Sharing With Security and Privacy Preservation via Consortium Blockchain

as the DP’s private key and computes pkk = xk P as • Guess: A outputs a guess γ 0 ∈ {0, 1}. The chal-
public key. Otherwise, it computes pkk = xk r1 P which lenger C will win the game if γ = γ 0 , which means
means the private key is r1 xk and unknown to C. Then, C T = ê(P, P)d/c . Otherwise, it will lose, which means
sends pkk to A and stores (pkk , xk , dk ) in table Tk , where T ∈ G2 is a random number.
all public keys are recorded in Tk during the game. Obviously, if T = ê(P, P)d/c , which means the adver-
Private key queries: C visits the table Tk and responds as sary can break the scheme with the advantage ε0 . In this
follows: if dk = 1, it returns skk = xk to A. Otherwise, case, the view of A is the same as the view in a real
it outputs a random number in Zq∗ and aborts. attack and it must have probability 1/2+ε at least. Thus,
Re-encryption key queries: C visits the table Tk to find the challenger C’s advantage to solve the DLDH problem
DP’s public key (Xk , xk , dk ), DO’s public key (pki , xi , di ) is ε2 ≥ ε0 .
and DR’s public key (pkj , xj , dj ). Additionally, it receives
the data packet ϑ4 = (H3 (i ) k Fi ) and responds to A REFERENCES
as follows: [1] H. K. Patil and R. Seshadri, ‘‘Big data security and privacy issues in
1) If dk = 1, it computes the re-encryption key healthcare,’’ in Proc. IEEE Int. Congr. Big Data, Anchorage, AK, USA,
t Jun./Jul. 2014, pp. 762–765.
rk = (rk1 , rk2 ) = ( x1i ( H3 (i ))Xk , x1i pkj H3 (Fi )).
P
[2] J. Li and X. Li, ‘‘Privacy preserving data analysis in mental health researc,’’
i=1 in Proc. IEEE Int. Congr. Big Data, New York, NY, USA, Jun./Jul. 2015,
2) If (dk , di , dj ) = (0, 0, 0), it computes the pp. 95–101.
x
re-encryption key rk = (rk1 , rk2 ) = ( xxki P, xji P). [3] J. Liu, X. Huang, and J. K. Liu, ‘‘Secure sharing of Personal Health
Records in cloud computing: Ciphertext-policy attribute-based signcryp-
3) If dk = 0 and (di , dj ) 6 = (0, 0), it aborts. tion,’’ Future Gener. Comput. Syst., vol. 52, pp. 67–76, Nov. 2015.
Re-encryption queries: According to the result of re- [4] X. Liu, Y. Xia, W. Yang, and F. L. Yang, ‘‘Secure and efficient query-
encryption key queries, C generates the re-encryption ing over personal health records in cloud computing,’’ Neuro Comput.,
vol. 274, pp. 99–105, Jan. 2018.
ciphertext as in the section protocol description or
[5] X. Liu, Q. Liu, T. Peng, and J. Wu, ‘‘Dynamic access policy in cloud-
aborts. based personal health record (PHR) systems,’’ Inf. Sci., vol. 379, pp. 62–81,
Decryption queries: C parses Cm0 as (c01 , c02 , c03 , c04 , c05 , c06 ) Feb. 2017.
at first. Then, it visits the table Tk to find (pkj , xj , dj ). [6] Z. Liu, J. Weng, J. Li, J. Yang, C. Fu, and C. F. Jia, ‘‘Cloud-based electronic
c0 health record system supporting fuzzy keyword search,’’ Soft Comput.,
If dj = 1, it computes m = 0 1/sk2j H3 (Fi ) and checks vol. 20, pp. 3243–3255, Aug. 2016.
(c3 ) [7] X. Wang, A. Zhang, X. Ye, and X. Xie, ‘‘Secure-aware and privacy-
the equalities ê(c04 , P) = ê(c06 , H3 (m)P1 + P2 ) and preserving electronic health record searching in cloud environment,’’ Int.
t J. Commun. Syst., vol. 32, p. e3925, May 2019. doi: 10.1002/dac.3925.
ê(c01 , P) = ê(c06 ,
P
H3 (wi )P). If the equalities hold, C [8] M. H. Au, T. H. Yuen, J. K. Liu, W. Susilo, X. Huang, Y. Xiang, and
i=1 Z. L. Jiang, ‘‘A general framework for secure sharing of personal health
returns m to A. Otherwise, it returns ⊥. records in cloud system,’’ J. Comput. Syst. Sci., vol. 90, pp. 46–62,
• Challenge: A presents two messages m0 , m1 ∈ G2 , Dec. 2017.
a target DP’s public key pkk0 and a target DR’s public [9] G. Zyskind, O. Nathan, and A. S. Pentland, ‘‘Decentralizing privacy:
Using blockchain to protect personal data,’’ in Proc. IEEE Secur. Privacy
key pkj0 . The restrictions are that A can’t do any private Workshops, vol. 90, May 2015, pp. 180–184.
key queries either on pkk0 or pkj0 in phase 1 and A can’t [10] S. Amofa, E. B. Sifah, K. O.-B. Agyekum, S. Abla, Q. Xia, J. C. Gee, and
do any re-encryption key queries. J. B. Gao, ‘‘A blockchain-based architecture framework for secure sharing
of personal health data,’’ in Proc. IEEE 20th Int. Conf. e-Health Netw.,
C picks a random number γ ∈ {0, 1} and searches Tk Appl. Services (Healthcom). Ostrava, Czech Republic, 2018, pp. 1–6.
to get (pkk0 , xk0 , dk0 ) and (pkj0 , xj0 , dj0 ). Then, it computes [11] X. Zheng, R. R. Mukkamala, R. Vatrapu, and J. Ordieres-Mere,
challenge ciphertext as follows: ‘‘Blockchain-based personal health data sharing system using cloud stor-
age,’’ in Proc. IEEE 20th Int. Conf. e-Health Netw., Appl. Services (Health-
Cm∗ = (c∗1 , c∗2 , c∗3 , c∗4 , c∗5 , c∗6 ) com). Ostrava, Czech Republic, Sep. 2018, pp. 1–6.
t 1 [12] T. Mikula and R. H. Jacobsen, ‘‘Identity and access management with
0 x0
= (b( H3 (wi ))P, mγ T xk , x 0j c∗6 , (r1 H3 (mγ ) + r2 )c∗6 ,
P
blockchain in electronic healthcare records,’’ in Proc. 21st Euromicro Conf.
i=1 k Digit. Syst. Design (DSD), Prague, Czech Republic, 2018, pp. 699–706.
(r1 H3 (c∗1 ) + r2 H3 (c∗1 k c∗2 k c∗4 ) + r3 )c∗6 , bP) [13] S. Cao, G. Zhang, P. Liu, X. Zhang, and F. Neri, ‘‘Cloud-assisted secure
eHealth systems for tamper-proofing EHR via blockchain,’’ Inf. Sci.,
Finally, C returns challenge ciphertext Cm∗ to A. vol. 485, pp. 427–440, Jun. 2019.
[14] R. Guo, H. Shi, Q. Zhao, and D. Zheng, ‘‘Secure attribute-based signa-
• Phase 2: A performs more queries as in phase 1. The ture scheme with multiple authorities for blockchain in electronic health
restriction are as follows: records systems,’’ IEEE Access, vol. 6, pp. 11676–11686, 2018.
[15] T. T. Thwin and S. Vasupongayya, ‘‘Blockchain based secret-data shar-
1) A can’t do any private key queries either on pkk0 or ing model for personal health record system,’’ in Proc. 5th Int. Conf.
pkj0 as in phase 1. Adv. Inform., Concept Theory Appl. (ICAICTA), Krabi, Thailand, 2018,
2) If A has made re-encryption key queries or re- pp. 196–201.
encryption queries, it can’t do private key queries [16] A. Theodouli, S. Arakliotis, K. Moschou, K. Votis, and D. Tzovaras,
‘‘On the design of a blockchain-based system to facilitate healthcare data
anymore. Perhaps, if A has made a private key sharing,’’ in Proc. 17th IEEE Int. Conf. Trust, Secur. Privacy Comput.
queries, then it can’t make re-encryption key Commun., 12th IEEE Int. Conf. Big Data Sci. Eng. (TrustCom/BigDataSE),
queries or re-encryption queries. New York, NY, USA, Aug. 2018, pp. 1374–1379.
[17] L. X. Chen, W.-K. Lee, C.-C. Chang, K.-K. R. Choo, and N. Zhang,
3) A can’t launch a decryption queries on target ‘‘Blockchain based searchable encryption for electronic health record shar-
challenge ciphertext. ing,’’ Future Gener. Comput. Syst., vol. 95, pp. 420–429, Jun. 2019.

136718 VOLUME 7, 2019

Y. Wang et al.: Cloud-Assisted EHR Sharing With Security and Privacy Preservation via Consortium Blockchain

[18] J. Liu, X. Li, L. Ye, H. Zhang, X. Du, and M. Guizani, ‘‘BPDS: AIQING ZHANG received the M.S. degree in cir-
A blockchain based privacy-preserving data sharing for electronic medical cuits and systems from Xiamen University, China,
records,’’ in Proc. IEEE Global Commun. Conf. (GLOBECOM). Abu in 2006, and the Ph.D. degree in signal and infor-
Dhabi, United Arab Emirates, Dec. 2018, pp. 1–6. mation processing from the Nanjing University of
[19] Y. Chen, S. Ding, Z. Xu, H. D. Zheng, and S. L. Yang, ‘‘Blockchain-based Posts and Telecommunications, China, in 2016.
medical records secure storage and medical service framework,’’ J. Med. She is currently a Professor with Anhui Normal
Syst., vol. 43, no. 5, Jan. 2019. doi: 10.1007/s10916-018-1121-4. University, China. She has authored more than
[20] Y. H. Hwang and P. J. Lee, ‘‘Public key encryption with conjunctive
30 articles, and holds more than ten inventions.
keyword search and its extension to a multi-user system,’’ in Pairing-Based
Her research interests include blockchain, applied
Cryptography—Pairing (Lecture Notes in Computer Science), vol. 4575.
Berlin, Germany: Springer, 2007, pp. 2–22. cryptography, and wireless network security.
[21] P. Zeng and K.-K. R. Choo, ‘‘A new kind of conditional proxy
re-encryption for secure cloud storage,’’ IEEE Access, vol. 6,
pp. 70017–70024, 2018.
[22] U. Mukhopadhyay, A. Skjellum, O. Hambolu, J. Oakley, L. Yu, and
R. Brooks, ‘‘A brief survey of Cryptocurrency systems,’’ in Proc. 14th
Annu. Conf. Privacy, Secur. Trust (PST), Auckland, New Zealand, 2016, PEIYUN ZHANG received the B.S. degree in
pp. 745–752. applied electronics from Anhui Normal Univer-
[23] D. Patel, J. Bothra, and V. Patel, ‘‘Blockchain exhumed,’’ in Proc. ISEA sity, Wuhu, China, in 1998, the M.S. degree in
Asia Secur. Privacy (ISEASP), Surat, India, 2017, pp. 1–12.
computer science and technology from Northwest
[24] Z. Zheng, S. Xie, H. Dai, X. Chen, and H. Wang, ‘‘An overview of
University, Xi’an, China, in 2005, and the Ph.D.
blockchain technology: Architecture, consensus, and future trends,’’ in
Proc. IEEE Int. Congr. Big Data (BigData Congr.), Honolulu, HI, USA, degree in computer science and technology from
Jun. 2017, pp. 557–564. the School of Computer Science and Technology,
[25] W. B. Wang, D. T. Hoang, P. Z. Hu, Z. H. Xiong, D. Niyato, P. Wang, Nanjing University of Science and Technology,
and Y. G. Wen, ‘‘A survey on consensus mechanisms and mining Nanjing, China, in 2008. She was a Postdoctoral
strategy management in blockchain networks,’’ IEEE Access, vol. 7, Researcher with the University of Science and
pp. 22328–22370, 2018. doi: 10.1109/ACCESS.2019.2896108. Technology China, Hefei, China, from 2010 to 2013, and a Visiting Scholar
[26] Y. Luo, Y. Chen, Q. Chen, and Q. Liang, ‘‘A new election algorithm for with the New Jersey Institute of Technology, Newark, NJ, USA, in 2016. She
DPos consensus mechanism in blockchain,’’ in Proc. 7th Int. Conf. Digit. is currently a Professor with the School of Computer and Information, Anhui
Home (ICDH), Guilin, China, 2018, pp. 116–120. Normal University. Her current research interests include blockchain, cloud
[27] T. Crain, V. Gramoli, M. Larrea, and M. Raynal, ‘‘DBFT: Efficient computing, big data, trust computing, Petri nets, web service, and intelligent
byzantine consensus with a weak coordinator and its application to information processing. She has published over 50 articles in the above areas.
consortium blockchains,’’ 2017, arXiv:1702.03068. [Online]. Available:
https://arxiv.org/abs/1702.03068
[28] K. Li, H. Li, H. Hou, K. Li, and Y. Chen, ‘‘Proof of vote: A high-
performance consensus protocol based on vote mechanism & consortium
blockchain,’’ in Proc. IEEE 19th Int. Conf. High Perform. Comput. Com-
mun., IEEE 15th Int. Conf. Smart City, IEEE 3rd Int. Conf. Data Sci. Syst.
(HPCC/SmartCity/DSS), Bangkok, Thailand, Dec. 2017, pp. 466–473.
[29] A. Zhang and X. Lin, ‘‘Towards secure and privacy-preserving data sharing
in e-health systems via consortium blockchain,’’ J. Med. Syst., vol. 42,
p. 140, Aug. 2018. doi: 10.1007/s10916-018-0995-5.

HUAQUN WANG received the B.S. degree in

YONG WANG received the B.E. degree in elec- mathematics education from the Shandong Nor-
tronic and information engineering from Anhui mal University, China, the M.S. degree in applied
Normal University, Wuhu, China, in 2013, where mathematics from the East China Normal Univer-
he is currently pursuing the M.S. degree in Internet sity, China, in 1997 and 2000, respectively, and
of Things technology with the School of Physi- the Ph.D. degree in cryptography from the Nan-
cal and Electronic Information Engineering. His jing University of Posts and Telecommunications,
research interests include applied cryptography in 2006, where he is currently a Professor. His
and healthcare blockchain. research interests include applied cryptography,
network security, and cloud computing security.

VOLUME 7, 2019 136719