AbstractElectronic health record sharing can help to improve the accuracy of diagnosis, where security and privacy preservationare critical issues in the systems. In recent years, blockchain has been proposed to be a promising solution to achievepersonal health information (PHI) sharing with security and privacy preservation due to its advantages of immutability. Thiswork proposes a blockchain-based secure and privacy-preserving PHI sharing (BSPP) scheme for diagnosis improvementsin e-Health systems. Firstly, two kinds of blockchains, private blockchain and consortium blockchain, are constructed bydevising their data structures, and consensus mechanisms. The private blockchain is responsible for storing the PHI whilethe consortium blockchain keeps records of the secure indexes of the PHI. In order to achieve data security, access control,privacy preservation and secure search, all the data including the PHI, keywords and the patients’ identity are public keyencrypted with keyword search. Furthermore, the block generators are required to provide proof of conformance for addingnew blocks to the blockchains, which guarantees the system availability. Security analysis demonstrates that the proposedprotocol can meet with the security goals. Furthermor, we implement the proposed scheme on JUICE to evaluate theperformance.
Keywords Blockchain · Security · Privacy preservation · e-Health · Personal Health Information (PHI)
Introduction
Provision of health services using digital technology has beentermed as e-Health. Research trend in the e-Health area isfocusing on utilizing the electronic health records for patientmonitoring and diagnosis. Usually, a patient may havemany healthcare service providers, including primary carephysicians, specialists, and therapists [1]. Consequently,health record sharing and exchanging is drawing increasingattentions in industry and research community, where data
This article is part of the Topical Collection on Blockchain-based Medical Data Management System: Security and PrivacyChallenges and Opportunities
1 College of Physics and Electronic Information, Anhui NormalUnivresity, Wuhu, Anhui, 241000 China
2 Faculty of Science, Wilfrid Laurier University, 75 UniversityAvenue West, Waterloo, ON, N2L 3C5 Canada
security and privacy preservation are critical topics in thisarea.
For a patient, one disease may be caused by or relatedwith another pathema(s). In this case, the precision of thediagnosis is affected by the amount and accuracy of patient’sother health information that the doctor gets. The doctormay be provided with some information about the relatedillness by querying the patient. However, this method isnot effective enough to assist the diagnosis because of tworeasons: i) If things happened long before, the patient mayforget some of the details, such as the medicines or medicalexaminations he/she had taken, which affects the precisionof the diagnosis or treatments he/she had got. ii) The patientcannot professionally describe the diagnosis or treatmentsdue to his/her limited medical knowledge, which affects thejudgment of the current doctor. Thus, the current doctormay not be able to deduce correct information for his/herdiagnosis.
One promising solution of this problem is to share thepatient’s health record such that the intended doctor can accessthe related data for diagnosis improvement. If the patienthad visited another doctor in the same hospital or medicalinstitution, and the related health record was generated by
this institution, the doctor may access the record directlyin the area network under the consent of the patient.However, in practice, the patient may visit different doctorsin different medical institutions for different symptoms.Under this circumstance, the doctor will be rejected toprovide the data by other institutions without an additionalagreement for personal health information (PHI) sharing.
In order to address these issues, cloud-assisted healthrecord sharing has been put forward in the e-Health sys-tem as a promising paradigm for health data storage andmanagement [1–6]. These works provide promising solu-tions to realize PHI sharing among medical institutions ine-Health systems, where security and privacy-preservationare critical concerns. Although all the above works focus onachieving security properties in cloud environments, thereremains one challenge: The cloud is expected to be a trustedcenter to store and manage the data, which is exposed topossible abuse, loss, leakage, or theft if the cloud is underattacks or inadequately supervised. Countermeasures areproposed by employing various cryptographic primitives orother techniques [1–4]. Unfortunately, these security threatsremain due to the centralization characteristics of cloudenvironment.
Blockchain is proposed to be an advantage solutionto address the security issues inherited in cloud-basedsystems because it can maintain a continuously growinglist of records, which are distributed and immutable [7–11].Generally, blockchain is treated as a distributed ledgerto store health records for sharing, exchanging or otherpurposes among stakeholders [12]. In e-Health systems,the patient may visit different medical institutions andeach institution manages their own database. PHI sharingsystems built on the blockchain technology is expectedto achieve secure distribution of health records. Albeitits advantages of immunity and distribution, blockchainbased health record sharing system still faces followingchallenges: i) How to design the consensus mechanismsuch that blocks are verified without violating the patient’sprivacy? ii) How to ensure unlinkability while the user’sidentity is searchable? In other words, unauthorized entitycan not link different health records to the same patient. iii)How to guarantee that the authorized doctor is only allowedto access the intended PHI?
In order to address the above issues, we propose toconstruct a consortium blockchain for secure and privacy-preserving PHI sharing among the hospitals. Each hospitalstores the PHI in its private blockchain, which has theadvantages of fast transaction, better privacy preservation,low cost, and better security performance. Furthermore,the hospitals are organized to formulate a consortiumblockchain, which stores searchable indexes of the PHI.The doctor can search the consortium blockchain for theindexes of interested records and access the original records
by visiting the private blockchain of the correspondinghospital.
In summary, the contributions of this work are threefold.
– We propose a framework for blockchain based PHIsharing with security and privacy preservation fordiagnosis improvements in e-Health system. Twoblockchains are introduced. The private blockchain ofthe medical service provider stores the patient’s originalPHI (encrypted for security)1 while the consortiumblockchain keeps records of the secure indexes of thePHI.
– We design core components for the blockchains, includ-ing data structure and consensus mechanism. Differentblock structures are devised for both private blockchainand consortium blockchain. Furthermore, we proposeproof of conformance as the consensus mechanism forthe blockchains and design an implementation method.
– We propose a secure and privacy-preserving PHI sharing(BSPP) protocol based on the proposed e-Healthblockchain. The patient’s PHI and the correspondingkeywords are encrypted for data security while theyare searchable by authorization for diagnosis improve-ments. Meanwhile, the patients’ identities are encryptedfor identity privacy preservation. The protocol is care-fully designed in such a way that the authorized doctorcan search the pseudo identities for the indexes ofinterested patients. Also, the authorized doctor is onlyallowed to access the patient’s history records whileprohibiting from searching for the future records.
The remainder of the paper is organized as follows. Anoverview on the related work is conducted in “Related Work”.Preliminaries are presented in “Preliminaries”. Section“System Model” illustrates the system architecture as wellas the threat model and design goals of the work. Section“PHI Blockchain Design” designs the PHI blockchain interms of data structure and consensus mechanism. Based onthe proposed blockchain, Section “Blockchain Based PHISharing” proposes the PHI sharing protocol in details. Later,Section “Security Analysis” analyses how the protocolachieves the security goals. Section “Implementation andPerformance Evaluation” implements the proposed schemeon JUICE and evaluates its performance. Finally, Section“Conclusions” concludes this work.
RelatedWork
Recent years have witnessed increasing interests of blockchainfor security and privacy in e-Health due to its advantages in
1The hash value of the encrypted PHI is uploaded to the chain whilethe original ciphertext is stored in the local computer client.
J Med Syst (2018) 42: 140 Page 3 of 18 140
data management, i.e., immutability and built-in autonomyproperties of the blockchain.
Q. Xia et al. [11] proposes a blockchain-based health datasharing framework that sufficiently addresses the accesscontrol challenges associated with sensitive data storedin the cloud. The system is based on a permissionedblockchain which allows access to only invited, and henceverified users. Furthermore, in order to provide dataprovenance, auditing and secured data trailing on medicaldata, the authors employ smart contracts and an accesscontrol mechanism in their another work [13] to effectivelytrack the behavior of the data and revoke access to offendingentities on detection of violation of permissions on data .
Yue et al. [14] also proposes a three-layer system: Datausage layer, data management layer and data storage layer.Different from the aforementioned works where cloud is astorage infrastructure, this work proposes that the privateblockchain plays the role of cloud. In [15], transactionsare used to carry instructions, such as storing, queryingand sharing data. The authors combine blockchain and off-blockchain storage to construct a personal data managementplatform focused on privacy. Kuo et al. [12] review thelatest biomedical/health care applications of blockchaintechnologies. They also discuss the potential challenges andproposed solutions of adopting blockchain technologies inbiomedical/health care domains.
Smart contract is constructed in [16] to contain metadataabout the record ownership, permissions and data integrity.The contract’s state-transition functions carry out policies,enforcing data alternation only by legitimate transactions.Rather than storing the health record in the block, [17] addsaddresses of sensors and mobile devices to a healthcareblockchain for pervasive social network (PSN) nodes.Through the addresses stored in the blockchain, a PSNnode can visit other nodes in the network and access thehealth data. This work has the merit of reducing the storageoverhead of devices while it did not consider the security ofthe addresses.
Much like the Bitcoin approach, the block of [18] is aMerkle tree-based structure. The leaf nodes of this tree rep-resent patient record transactions, and describe the additionof a resource to the official patient record. However, trans-actions do not include the actual record document. Instead,they reference Fast Healthcare Interoperability Resources(FHIR) via Uniform Resource Locators (URLs). Notably,a new consensus algorithm, proof of interoperability, isdesigned to facilitate data interoperability in this work.
Different from the above works which focus on healthdata sharing, [19] and [20] focus on different issues. [19]proposes a blockchain platform architecture for clinical trialand precision medicine. This work investigates the design ofthe blockchain platform starting from the medical domain,particularly the clinical trial and precision medicine.
Regarding few studies have been done on key managementschemes for blockchain, [20] attempts to develop keynegotiation in this area. It uses body sensor networks todesign a lightweight backup and efficient recovery schemefor keys of health blockchain. This is pioneering work in keymanagement for blockchain while its performance is greatlyinfluenced by the hardware condition and environment.
The existing works provide diverse frameworks for PHIsharing in e-Health systems with blockchain. Actually, theytake the blockchain as an assisted tool for data sharinginstead of taking it as a main tool for data storage, datamanagement and data sharing. Additionally, these works donot give a detail solution for a specific application. In thiswork, We design private and consortium blockchains forPHI sharing without violating the patients’ privacy. Also,we propose a PHI secure searching protocol in the system.
Preliminaries
In this section, we give the background and preliminariesrequired in this paper.
Blockchain
The blockchain is a distributed database that contains anordered list of records linked together through a chainon blocks [7]. A block usually consists of hash value ofprevious block, payload, signature of the contributor, andtimestamp. The hash value of previous block makes theblockchain immutable to modification. Payload in the blockvaries with the applications. It can be an address pointer ofthe original data or the content of the transaction or someother information. Contributor signature and timestampshow the generator and generation time of the block.
In blockchain network, there are two important entities:Miners and verifiers. Miners refer to the nodes who producenew blocks for the blockchain. Different applicationscenarios may define different nodes as the miners. Forexample, In the Bitcoin blockchain, the nodes that provideproof of works are provided as the miners to keep recordsof the transactions. New blocks are accepted only afterbeing verified by verifiers, who are responsible for verifyingthe validity of new blocks. The processes of generating,verifying and adding new blocks to the blockchain arenamed mining. In order to guarantee security and reliabilityof the mining processes, consensus mechanism is critical inblockchain network. It determines who keeps records andhow to check the validity of the new block.
As blockchain is originally applied in Bitcoin, trans-action is widely used in the network to present thenew generated data. In this work, transactions denote thesecure indexes of the new emerging health records in the
140 Page 4 of 18 J Med Syst (2018) 42: 140
system. Generally, blockchain can be classified into threecategories: Permissionless blockchain (public blockchain),private blockchain and consortium blockchain. In permis-sionless blockchain, anyone in the world can enter into thesystem to access the data and send transactions, for example,Bitcoin system. In private blockchain, an organization con-trols the access right of the system. Consortium blockchainis managed by several organizations. Only the organizationsin the system are allowed to access the blockchain.
In relation to our work, private blockchain and consor-tium blockchain are introduced in the e-Health system tostore and manage the user’s PHI, which helps improvingthe diagnosis. Each hospital operates a private blockchainwhich stores the patient’s PHI. The hospitals negotiate tomanage a consortium blockchain, which keeps records ofthe secure indexes for the health records.
Bilinear maps and complexity assumptions
Bilinear maps Let G1 and G2 be two cyclic groups of thesame prime order p. A mapping e : G1 × G1 → G2 iscalled an admissible bilinear map if it satisfies the followingproperties:
1. Bilinear: For all V,Q ∈ G1 and a, b ∈ Z∗p, we have
e(aV , bQ) = e(V , Q)ab.2. Symmetric: e(V ,Q) = e(Q, V ).3. Non-degenerate: e(V , Q) �= 1G2 ,where V,Q �= 1G1 .4. Computable: e is efficiently computable.
Complexity assumption Let P be the generator for thegroups G1 and G2 defined above. The q-BDHI prob-lem is defined as follows: Given the q + 1-tuple(P, xP, x2P, . . . , xqP ) ∈ G
∗q+11 as input, compute
e(P , P )1/x ∈ G∗2. An algorithm A has advantage ε in
solving q-BDHI in G1 ifPr[A(P, xP, x2P, . . . , xqP ) = e(P , P )1/x] ≥ ε
where the probability is over the random choice of x ∈Z
∗p and random bits of A.
Definition 1 q-BDHI assumption. The q-BDHI assump-tion holds in G1 and G2 if all polynomial time algorithmshave a negligible advantage in solving the q-BDHI problem.
Keyword Search
Public encryption with keyword search (PEKS) is putforward by Bonth ea al. [21] to achieve search over theencrypted data in asymmetric settings. Usually, a keywordw is extracted from a message m. The keyword is publickey encrypted and then searched by using a trapdoor, whichis generated by the entity corresponding to the public key.
Firstly, we review the definition of PEKS. It consists of fourpolynomial time randomize algorithms.
KeyGen(λ): Input a security parameter λ and output apublic/private key (pk, sk).
PEKS(pki, w): Given entity i’s public key and akeyword w, it produces a searchable encryption cw for w.
Trapdoor(ski, w′): Take i’s private key ski and a
keyword w′ as input, output a trapdoor Tw′ .Test(pki, cw, Tw′): Given i’s public key pki , a search-
able encryption cw and a trapdoor Tw′ , output “yes” if w =w′ and “no” otherwise.
Afterwards, various keyword search algorithms areproposed to provide diverse search functions by combiningPEKS with other cryptographic primitives. In order toenhance the search security, PEKS schemes with designedtester is proposed in [22, 23]. Combined with proxy re-encryption [24, 25], the keyword search mechanisms allowa delegatee to search for the interested keywords from thedelegator’s data. Keyword search with oblivious transferis introduced in [26] to address the user privacy issue.The oblivious keyword search prohibits the data supplierfrom knowing the chosen keywords and the correspondingciphertext. Regarding some applications require more thanone keyword to be searched for, pubic key encryption withconjunctive field keyword search is presented in the works[27–29]. The above PEKS schemes may be mixed togetherto achieve the required security objectives. [3] proposes aconjunctive keyword search with designed tester and proxyre-encryption function.
In this work, based on the keyword search algorithm[30], we propose a secure and privacy preserving keywordsearch protocol for blockchain-based health record system.By introducing a polynomial constructed on the keywordset, the proposed protocol is able to provide proof ofconformance for the blockchain, which works as theconsensus mechanism.
SystemModel
In this section, we present the system architecture for theblockchain based health record sharing system. And then,we illustrate the threat model and design goals.
System Architecture
Assume that several hospitals in a city agree to form aleague to share their patients’ health record. In order toenhance security of the data, two kinds of blockchainsare constructed in the system: Private blockchain of eachhospital and consortium blockchain of the hospitals inthe coalition. The private blockchain stores the originalPHI of the patients that had visited the hospital while
J Med Syst (2018) 42: 140 Page 5 of 18 140
the consortium blockchain stores keywords of the PHIgenerated by all the hospitals in the alliance. Basically, theframework of the proposed secure and privacy-preservingPHI sharing system is shown in Fig. 1. There are threeentities in the system: System manager, medical serviceproviders (hospitals), and users (patients).
System manager. System manager charges the wholesystem. All the users and doctors are required to registerto the system manage. It generates system parametersand keeps a public key tree for the doctors and users. Italso generates consensus vector a (it will be described in“PHI Blockchain Design”) for the consortium blockchain.
Medical service providers.Medical service providers aremedical institutions which provide medical services for theusers. In this work, we refer to hospitals for simplificationof expression. Usually, each hospital poses a server andmany computer clients. Each computer client is operated bya doctor to record his/her patients’ health information. Thenthe clients generate blocks for the patients’ health recordsand broadcast them to the private blockchain of the hospital.Moreover, the selected computer client is responsible forverifying the new coming blocks. The server is responsiblefor the registrations of the users by keeping a register tablefor the users and doctors. It also takes the responsibilityof collecting new blocks in the private blockchain at apredefined interval and formulating new blocks for theconsortium blockchain. Also, the selected server shouldverify new blocks for the consortium blockchain. Notably,
the server authenticates the doctors outside the privateblockchain for their accessing of the user’s PHI in theprivate blockchain.
Users. Users refer to the patients who visit hospitals forservices. They must register to the server of the hospitalbefore seeing the doctor. Each patient will get a token fromthe server after registration. The patient should keep thetoken secret and show it to the doctor when coming to thedoctor. The beacon works as an evidence for the interactionof the doctor and the patient, which authorizes the doctorto generate PHI for the patient. The PHI is stored in theprivate blockchains of the hospital. As one patient mayvisit different doctors in different hospitals for differentillnesses, his/her PHI is stored in the private blockchains ofthe corresponding hospitals. Furthermore, the hospitals sendsearchable keywords of blocks in their private blockchainsto the consortium blockchain. In this way, PHI is stored withdistribution and immutability, and they are searchable. Inthis work, “user” and “patient” are interchanged.
Usually, current hospitals own servers. They can also pro-vide computer clients for the doctors. Consequently, privateblockchains and consortium blockchain can be constructedbased on the existing infrastructures of the hospitals with-out additional instruments. Notably, softwares are requiredto be installed in the servers and computers for establishingprivate blockchains and consortium blockchain.
The notations used throughout the paper are listed inTable 1.
Fig. 1 System architecture
Hospital 1
Users
(patients)
Consortium blockchain of
hospitals
Server
Computer clients
Doctor
Doctor
Hospital k
Server
Computer clients
Doctor
Doctor
Secure
indexes
Secure
indexes
Private blockchain
of hospital k
System
manager
140 Page 6 of 18 J Med Syst (2018) 42: 140
Table 1 Notations and description
Notation Description Notation Description
W Keyword set IDi User i’s identity
U User set IDj Doctor j ’s identity
D Doctor set IDb The identity of a block
H Hospital set Tw Keyword searching trapdoor
T xi Secure index Td Identity searching trapdoor
σj j ’s signature pki, ski Public key and private key of i
di i’s pseudo identity ce, η Evidence for proof of conformance
Threat Model and Design Goals
The hospital servers and computer clients are deemed assemi-trusted. They are honest to perform the protocol butcurious to access or deduce the user’s health informationwithout authorization. The outsider attackers can eavesdropthe transmissions in the public channel, such as secureindexes, encrypted PHI, and trapdoors. The computerclients are not allowed to collude with the server to infer thereal identity of the user.
Based on the above threat models, we aim to achieve thefollowing goals:
Data security and access control. As PHI is privacysensitive, it is critical to achieve data security, includingdata confidentiality and integrity, data auditing, and accesscontrol. Usually, data confidentiality and integrity areguarantee by encryption and signature. Data auditabilityand access control should be achieved to ensure that allthe data access activities are monitored under the dataowners (patients) and the data generators (hospitals). Theycan be achieved through identification, authentication andauthorization by using cryptographic primitives. In thiswork, data security can be enhanced by combination ofprivate blockchain and consortium blockchain, which storethe PHI and the corresponding keywords respectively.
Privacy-preservation. Albeit privacy preservation canbe achieved partly through data confidentiality and accesscontrol, user’s identity leakages some privacy-sensitiveinformation in e-Health systems. Consequently, it is vitalimportant to keep the user’s identity information secret.Generally, anonymity and unlinkability are required torealize identity privacy. Here, unlinkability means that theeavesdroppers are not able to judge whether two or moreflows of PHI come from the same source.
Secure search. In this system, the doctor is authorizedby a patient to search for his/her history PHI in orderto improve diagnosis. During this process, only theauthorized doctor is allowed to access the interested content.The eavesdroppers are not able to guess the keywords.Moreover, as the doctor has to search the pseudo identities
for the intended patient, the eavesdroppers are also notallowed to deduce the real identities of the users.
Time controlled revocation. After getting keywordsearching trapdoor and identity searching trapdoor fromthe patient, the doctor is authorized to access the user’shistory record. However, he/she should not be able to accessthe user’s future health records using the same searchingtrapdoors. In other words, access right should be timecontrolled.
System availability. In this work, system availabilityincludes two aspects: i) The secure keywords stored inthe consortium blockchain should be selected from theallowable keyword set such that they are searchable. ii) Thepseudo identities for the same patients should be able to befigured out by the authorized doctors to search for their PHIkeywords.
PHI Blockchain Design
In this section, we design the blockchain for the PHI sharingsystem from the aspects of data structure, and consensusmechanism.
Data Structure
As private blockchain and consortium blockchain storedifferent contents in the system, the blocks of the twokinds of blockchains have different structures. The datastructure of the private blockchain is shown in Fig. 2.It consists of block header, payload, signature of thecontributor, and timestamp. Block header concludes threecomponents: Block ID, block size, and hash value ofprevious block. Payload is composed by four parts: Identityof the PHI generator (doctor), pseudo identity of the PHIowner (patient), encrypted PHI hash and its keyword.Notably, all the PHI related information is stored in theformat of ciphertext for privacy preservation of the patient.Specifically, the block stores the pseudo identity of the dataowner, which is derived from the true identity; the PHI
J Med Syst (2018) 42: 140 Page 7 of 18 140
Block size
Previous block hash
PHI generator ID
PHI owner pseudo ID
PHI secure keyword
Encrypted PHI hash
Timestamp
Block
header
Contributor signature
Payload
Block ID
Fig. 2 Structure of a block in the private blockchain of a hospital
and its keyword are encrypted in the block. Contributorsignature helps to track the generator (doctor) of the block.Timestamp shows the generation time of the block.
Similarly, the block in the consortium blockchain iscomposed of block header, payload, signature of thecontributor, and timestamp, as shown in Fig. 3. The blockgenerator (hospital server) creates a block at an interval,during which the server collects the health records generatedin the time period. The block only stores secure indexesin the payload on the consortium blockchain instead ofkeeping the original PHI. A secure index is composed byl(l � 1) transactions T x1, T x2, . . . , T xl . Each transactionrecords a secure index for a patient’s PHI, including threeitems: Block ID, PHI owner pseudo ID and PHI keyword.
Consensus Mechanism
Consensus mechanism is the core technology for blockchainas it determines whether the new block is validated and whokeeps the record. Thus, it influences the security and reliabilityof the whole system. We propose proof of conformance as
Block size
Previous block hash
Block generator ID
PHI owner pseudo ID
PHI secure keywordTimestamp
Block
header
Contributor signature
PayloadSecure indexes
(Tx1,Tx2,...Txl)Tx1 Tx2 ... Txl
Block ID
Block ID
Fig. 3 Structure of a block in the consortium blockchain
the network consensus mechanism in the system for bothprivate blockchain and consortium blockchain.
Remark 1 As discovered in [31], after 2/3 of all theparticipates verifying the replicas in a distributed system,the system is fault tolerance. Consequently, we define thata new block is acceptable if it is verified by 2/3 of all thenodes in the blockchain.
Consensus mechanism for private blockchain. When auser (patient) goes to a hospital searching for medicalservice, he/she will register to the hospital server andselect a doctor as his/her service provider. After interactionbetween the patient and the doctor, the patient’s PHI willbe generated by the doctor. The doctor encrypts the PHIwith the user’s public key and generates a pseudo identitydi for the user. The di is appended with the encryptedPHI to label the owner of the PHI. A new transaction forthis PHI is sent to the private blockchain of the hospital.Then, the verifiers verify the block by checking whether thePHI is generated by the authorized doctor. This consensusmechanism is defined as proof of conformance, i.e., onlythe block generated by the doctor, whom the user withpseudo identity di has visited, is validated. This consensusmechanism can be achieved by generating a secure token forthe user after he/she registers to the hospital. When arrivingat the doctor, the user shows the doctor the token. Then thedoctor can computer a pseudo identity for the user by usingthe secure token.
After receiving a new transaction generated by this client,the other clients check whether the doctor is authorized bythe patient to generate the data. If more than 2/3 of clientsverify the new transaction, it is accepted as a new validate blockin the private blockchain. Section “Protocol description”presents this consensus scheme in details.
Consensus mechanism for consortium blockchain. Sim-ilar to the private blockchain, proof of conformance alsoplays the role of consensus mechanism in the consortiumblockchain in the system. However, it requires confor-mance of different contents. Specifically, the consortiumblockchain provides keyword search for the users, thus thekeywords stored in the blockchain should be interoperabil-ity. In the system, as the keywords describe the symptomsor diagnosis of the patients, they conform to standard medi-cal statements, such as FHIR profiles [32, 33]2. Usually, the
2Fast Healthcare Interoperability Resources is a standard describingdata formats and elements for exchanging electronic health records. Itsgoals is to facilitate interoperation between legacy health care systems.This resource makes it easy to provide health care information tohealth care providers and individuals on a wide variety of devicesfrom computers to tablets to cell phones. It also allows third-partyapplication developers to provide medical applications which can beeasily integrated into existing systems.
140 Page 8 of 18 J Med Syst (2018) 42: 140
keywords are constrained in a predefined set for the usersto search in the blockchain. The consortium blockchainreaches network consensus: Verify that keywords of thesecure indexes in the incoming blocks are selected fromW ,where W denotes the predefined keyword set.
In order to implement proof of conformance in theconsortium blockchain, the system constructs a polyno-mial based on the keywords. We assume that W ={w1, w2, . . . , wn}, where n is the size ofW . The polynomialis constructed as follows:
Compute H1(w1), H1(w2), . . . , H1(wn) and construct apolynomial f (x) with order n, satisfying f (H1(wi)) =0, i ∈ {1, 2, . . . , n}. The polynomial can be denoted as
where [1, bn−1, bn−2, . . . , b0] � b are the coefficients ofthe polynomial. The equation f (x) = 0 is transformed into
xn + bn−1xn−1 + . . . + b1x = −b0. (2)
Subdivide −b0 at both sides of Eq. 2, then it turns to be
−1
b0xn + −bn−1
b0xn−1 + . . . + −b1
b0x = 1. (3)
Let an = −1b0, an−1 = −bn−1
b0,. . . ,a1 = −b1
b0. Construct a
new polynomial
g(x) = anxn + an−1x
n−1 + . . . + a1x. (4)
It can be deduced that g(H1(wi)) = 1, where wi ∈W . Define vector a = [a1, a2, . . . , an−1, an] and vectorhi = [H1(wi), (H1(wi))
2, . . . , (H1(wi))n−1, (H1(wi))
n].Then, the inner product of vector a and vector hi , a ·hi = 1.The vector a, named consensus vector, helps to check thevalidity of the secure indexes in the new appearing blocksin the consortium blockchain.
If more than 2/3 of hospital servers verify the new transac-tions, it is accepted as a new validate block in the consor-tium blockchian. Section “Protocol description” designs thedetailed consensus mechanism for consortium blockchain.
Blockchain Based PHI Sharing
In this section, we firstly present an overview of the proposedprotocol for a comprehensive understanding of the scheme.Then, we describe the protocol in details.
Overview of the Scheme
Fig. 4 describes the procedure of the proposed protocol. Theprotocol can be divided into three layers: Data generationlayer, data storage layer, and data service layer.
Fig. 4 The proposed protocol
Data generation layer
Service request
Hospital k
Users
Encrypted
PHI
Searchable indexes
Hospital 2IDk
Private blockchain
of hospital 2
IDj
Consortium blockchain of
hospitals
User i
Service
request
Service request
Encrypted
PHI
Hospital 1ID2
Private blockchain
of hospital 1
ID1
Data storage layer
Searchable indexes
Service layer
Trapdoors
Results
PHI request
J Med Syst (2018) 42: 140 Page 9 of 18 140
Without loss of generality, we assume that a patienti ∈ U registers to hospital k ∈ H to see the doctorj ∈ D, the server of hospital k generates an evidence β
for the user and sends it to the user. Meanwhile, it storesμ = H1(β) in the server register table for doctor j . Here,β works as an authorization for the doctor to generatePHI for the user i. After the patient i physically visitsthe doctor, he/she gives β to the doctor as a consent forgenerating his/her PHI and accessing his/her history healthrecord. Suppose that the doctor generates health record m
for user i by the interaction. For safely storing the data withinteroperability, the doctor extracts a keyword w ∈ W forthe PHI. Then, it encrypts m and w with the user’s publickey pki . The ciphertext c = [ci0, ci1, ci2] is composed bythree components: ci0 is the ciphertext of PHI m, which isstored in the private blockchain; ci1 is the ciphertext of thekeyword w, which is stored in the private and consortiumblockchain for searching purposes; ci2 is a promise for proofof conformance sent to the consortium blockchain.
Furthermore, the doctor computes a pseudo identity di
for the user. The pseudo identity should satisfy the followingrequirements: i) It can not be linked with the user’s realidentity by the other entities without the user’s authorizationfor privacy preservation. Meanwhile, a doctor can find outthe real identity under the authorization of the user. ii) It isdifferent from the user’s other pseudo identities generatedby other doctors to achieve unlinkability. In order to achievethese goals, the doctor encrypts the user’s identity by usingsearchable encryption. The ciphertext works as the pseudoidentity. Finally, a new transaction is formulated by theclient in the formate of T X in Table 2 for the privateblockchain, where hash denotes the hash value of theprevious block, σj denotes the doctor’s signature, and t
denotes the timestamp. Notably, for proof of conformancein the private blockchain of the hospital, the client outputsa token η, which is a function of β and her/his private keyskj . The validity of the block is checked by using μ and thepublic key pkj .
The server of a hospital k will collect all the new blocksand send the secure indexes to the consortium blockchain. Inthis work, we assume that after 8 new blocks are generated3
in the private blockchian, the server will extract blockidentity, user pseudo identity, and secure keywords fromeach block to formulate a new transaction for the consortiumblockchain, as shown in transaction TX of Table 3. Whena new transaction arrives, the verifiers in the consortiumblockchain extract T xi, i ∈ {1, 2, . . . , 8} and checks itsvalidity. The detailed steps of verification will be describedin subsection 2. If all the secure indexes are validated, thenew blocks are added to the consortium blockchain.
3 To avoid the case that less than 8 new blocks are generated in a longperiod, a time interval can be predefined in the system.
Table2
Block
generatedby
doctor
jforuser
iin
privateblockchain
Block
header
Transactio
nTX
Tim
estamp
Block
identity
Block
size
Previous
blockhash
Datagenerator
IDUserpseudo
identity
Secure
keyw
ords
Encrypted
PHIhash
Con
tributor
signature
ID
bsiz
ehash
ID
jdi
(ci1
,c i2)
hash(c
i0)
σj
t
32Bytes
4Bytes
32Bytes
9Bytes
(3|G
1|+
|Q|)B
ytes
((n
+3)
|G1|+
|G2|+
|Q|)B
ytes
32Bytes
9Bytes
9Bytes
140 Page 10 of 18 J Med Syst (2018) 42: 140
Table3
Block
generatedby
hospitalk
forconsortiu
mblockchain
Block
header
Transactio
nTX
Tim
estamp
Block
identity
Block
size
Previous
blockhash
DatageneratorID
Secure
indexes
Contributor
signature
ID
bsiz
ehash
ID
k(T
x1,T
x2,..
.,T
xl)
σk
t
32Bytes
4Bytes
32Bytes
9Bytes
8(9
+6|G
1|+
2|Q|)B
ytes
9Bytes
9Bytes
Let T xi denote the secure index for the data generatedby doctor j for user i. Then, T xi = (IDb, di, ci1). A newblock generated by the hospital k for consortium blockchainis shown in Table 3.
If the doctor j thinks it is necessary to search for theuser i’s history health record related with keywordw′ beforegenerating his/her PHI m, it comes to the second stage:Data search. After achieving an agreement, the user i sendsthe doctor an identity searching trapdoor Td and a keywordsearching trapdoor Tw′ . The Td helps the doctor to find outall the secure indexes of the user’s history records in theconsortium blockchain. Furthermore, the doctor can find outthe intended secure index T xi which concludes keyword w′by using Tw′ .
In order to recover the PHI related with keyword w′,the doctor parses T xi = (IDb, di, ci1). By checking IDb,the doctor can access the corresponding private blockchainto extract the ciphertext ci0. The doctor obtains the user’soriginal PHI m through decrypting ci0. The followingsubsection describes the detailed constructions.
Protocol description
The proposed scheme is composed by three phases: Systemsetup, data generation and storage, data search and access.
Phase 1: System setup.
In this step, the system generates the system parameterGP by implementing the function GlobalSetup(λ), whereλ is the security parameter. All the users i ∈ U and doctorsj ∈ D generate their private keys and public keys byoperating the function KeyGen(GP).
– GlobalSetup(λ): Choose two bilinear groups (G1,G2)of prime order p and a bilinear map e. Pick two differentgenerator P1, P2 of G1 and set g = e(P1, P1), h =e(P1, P2). Pick seven hash functions H0 : G2 →{0, 1}∗, H1 : {0, 1}∗ → Z
∗p, H2 : G1 → M (the
message space), H3 : M × G1 → Z∗p, H4 : G1 ×
Z∗p × G1 → Z
∗p, H5 : {0, 1}∗ × G1 → Z
∗p, H6 :
{0, 1}∗ × Z∗p → Z
∗p. The system parameter GP =
(P1, P2, e, H0, H1, H2, H3, H4, H5, H6).– KeyGeni(GP ): Each user i ∈ U randomly chooses
numbers (yi1, yi2, yi3) ∈ Z∗p as its private key ski . It
outputs the public key pki = (Yi1 = yi1P1, Yi2 =yi2P1, Yi2 = yi2P1).
– KeyGenj (GP ): Each doctor j ∈ D randomly choosesnumbers yj ∈ Z
∗p as its private key skj . It outputs the
public key pkj = (Yj = yjP2).
Phase 2: Data generation and storage.
When user i registers to hospital k, the server of thehospital randomly selects β ∈ {0, 1}∗ and sends β to the
J Med Syst (2018) 42: 140 Page 11 of 18 140
user securely. Meanwhile, the server chooses a doctor j forthe user4. The server computes μ = H1(β) and stores itin the system with the doctor. As the user comes to thedoctor j , he/she will show the doctor β, which works asan evidence for the user’s authorization to the doctor forgenerating his/her PHI.
After interaction with patient i, the doctor j generateshealth record m ∈ {0, 1}∗ as the patient’s PHI and selectsthe keyword w ∈ {0, 1}∗ from the standard keyword set.The doctor encrypts m and w with the user’s public key pki
by implementing the following operations.
– Randomly chooses r1 ∈ Z∗p and computes B = r1Yi2,
r0 = H3(m, B), A = r0(Yi1+H1(w)P1)+r1H1(w)P1,E = r0Yi3, F = H4(h
r0 , A, B).– Computes J = gr0(yi1+H1(w)) and vector X =
The output of the encryption algorithm is c =(ci0, ci1, ci2), where ci1 = (A, B, E, F ) and ci2 = (J,X).Here, (A, B, E, F ) is the searchable keyword ciphertext andce = (A, J,X) is the evidence for proof of conformance inthe consortium blockchain. Notably, A can resist keywordcheating as it exists both in the keyword ciphertext ci1 andthe evidence ce. The ciphertext ci0 is stored in the hospitaland the blockchain stores the hash value of ci0.
Moreover, the doctor generates a pseudo identity di forthe user by encrypting IDi (IDi ∈ {0, 1}∗) with IDi as thekeyword. Similar to the encryption for m and w, the doctorperforms the following operations:
r0 = H5(IDi, Bd), Ad = r0(Yi1+H1(IDi)P1)+r1P1.– Computes Ed = r0Yi3, Fd = H4(h
r0 , Ad, Bd).
Then di = (Ad, Bd, Ed, Fd). Additionally, in order toprovide a proof of conformance in the private blockchain,the doctor generates a proof η = (α, β ′) based on β and hisprivate key skj , where α and β ′ are computed by doctor j
as follows:
– Randomly chooses r ∈ Z∗p, computes α = r
yj +H1(β).
– Computes β ′ = H0(rP2) ⊕ β.
Finally, the doctor formulates the transaction T X ofTable 2 and broadcasts it to the private blockchain ofhospital k. Upon receiving a new transaction, the verifiersof the private blockchain verify it as follows:
– Extracts IDj , η = (α, β ′) from the block and searchesμ for IDj in the system.
4The doctor can also be chosen by the user in practical applications.
If the equation holds, the transaction is validate. The verifierbroadcasts a validation confirmmessage. After receiving 2
3npvalidation confirm messages, the new transaction is accepted.Here, np denotes the amount of nodes in the private blockchain.It is structured as Table 2 and added to the blockchain.
In each private blockchain, the system server extracts theblock identity, user pseudo identity and secure keyword of eachnew blocks. Let T xi = (IDb, di, ci1), i ∈ {1, 2, . . . , 8}. Theserver composes secure indexes of all the new emerging 8blocks. These secure indexes are formulated as a new trans-action in the format of Table 3. The server broadcasts thenew transactions with the ciphertext ci2, i ∈ {1, 2, . . . , 8} tothe consortium blockchain. When a new transaction arrives,the verifiers of consortium blockchain verify each secureindex T xi, i ∈ {1, 2, . . . , 8} in the block as follows:– Parses A from ci1 and ci2 = (J,X). Checks whether
During the interaction processes of a doctor and a user,the doctor may find it is necessary to access the user’shistory record for more precise diagnosis. In this case, thedoctor (assume doctor j ) will ask for an identity searchingtrapdoor and a keyword w searching trapdoor from the user.The user (assume user i) generates the identity searchingtrapdoor Td and keyword trapdoor Tw for the doctor.
140 Page 12 of 18 J Med Syst (2018) 42: 140
Remark 2 Generally, the doctor is only authorized to accessthe user’s history record. He/she is prohibited to accessthe future record without authorization. Consequently, thesearching doors should be designed in such a way that theyonly work when the doctor searches the data within theallowable time window. In order to achieve this securitygoal, we define an enable function f (x) which has thefollow properties:
f (x1)/f (x2) ={1 x1 ≥ x20 x1 < x2
(5)
In the system, the current timestamp ts can be expressed asan integer. For example, the current time “2:00 PM, Dec. 27,2017” can be denoted as “ts = 2017122714”. The historyrecord refers to the record generated before “2:00 PM, Dec.27, 2017”, i.e., the data generation time t0 ≤ ts .
Assume that the current timestamp is ts . The userperforms the following operations to generate Td = (T d
After getting the searching trapdoors, the doctor firstsearches the pseudo identity in the secure indexes ofconsortium blockchain to find out the indexes for user i.Specifically, the doctor extracts secure indexes (T x1, T x2,
. . . , T x8) and the timestamp t0 of the blocks. For eachT xi = (IDb, di, ci1), i ∈ {1, 2, . . . , 8}, parse di as di =(Ad, Bd, Ed, Fd). The doctor j checks whether di is thepseudo identity of IDi as follows:
Remark 3 A dishonest doctor may input false t0, i.e. t ′0 <
t0 to achieve t0 < ts such that H6(β, rdf (ts)/f (t0)) =H6(β, rd). In this way, the doctor may use the trapdoor to
access the patient’s future health record. In order to addressthis issue, we propose that the value of f (t0) should begenerated by the block sender.
If the equation holds, T xi is the user i’s secure index,the doctor goes on implementing the following operationsto check whether the index is for keyword w. Otherwise, itaborts.
– Parses ci1 = (A, B, E, F ) and computes U1 = e(A +H6(β, T3/f (t0))E, T1)
1/yj , U2 = e(B, T2)1/(yj H1(w)).
– Computes V = U1/U2, checks whetherH4(V , A, B) = F .
Correctness. The proof of the correctness is similar withEq. 6.
If the equation does not hold, ci1 is not keyword w’ssecure index. The doctor aborts. Otherwise, the doctortemps to access the original PHI by accessing the privateblock which generates this secure index. In specific, thedoctor checks the block identity IDb and finds out thecorresponding private blockchain, denoted hospital k’sprivate blockchain. Then, the doctor logins in the serverof hospital k for accessing the block IDb. The serverauthenticates the doctor and locates the block IDb inthe blockchain. It parses hash(ci0) from the block, andsends the ciphertext ci0 to the requesting doctor. Then,The original PHI m can be obtained by the doctor throughdecrypting ci0 as follows:
– Computes m′ = ci0 ⊕ H2(V ), and r ′0 = H3(m
′, B).
Checks whether hr ′0 = V .
If the equation holds, m is accepted as the valid PHI.
Security Analysis
In this section, we analyze how the proposed schemecan effectively meets with the design goals presented in“System Model”.
The proposed protocol achieves data security and accesscontrol. The essential characteristics of blockchain guaran-tees immunity of the proposed protocol. In other words,the data stored in the blockchain are unchangeable unless51% attack5 happens [12]. This ensures that the data cannot be modified. Additionally, the PHI is encrypted underthe data owner’s public key. So it can only be decryptedby the data owner. Then, the encrypted PHI is storedin the private blockchain. Only authenticated accessors areallowed to obtain the ciphertext, which enhances security
551% attack brings the attacker more cost than benefits thus it rarelyhappens [12].
J Med Syst (2018) 42: 140 Page 13 of 18 140
of the data. Moreover, data integrity can be achieved by thesignature of the block generator in each block.
Furthermore, in order to efficiently utilize the data, thedata owner may allow the authorized doctor to access theoriginal PHI by sending a keyword trapdoor Tw to thedoctor, as described in “Protocol description”. Note that inTw = (T1, T2, T3), T1 = Yj/(yi1 + H1(w) + yi3H6(β, r))
is related with the public key Yj of the intended doctor j .Only doctor with private key yj is able to compute U1 =e(A + H6(β, T3)E, T1)
1/yj and U2 = e(B, T2)1/(yj H1(w)),
which are used to search for the keyword w and decryptthe original PHI. By this method, the data owner control theaccess of his/her PHI.
On the other hand, the hospital can also control its dataaccess. As described in Phase 3, the doctor is required tologin in the server of hospital for accessing the block IDb
in the private blockchain, which contains the requestingencrypted PHI. Consequently, the hospital is able to controlthe access of the data.
The proposed protocol achieves privacy preservation.Apart from data security, the proposed scheme achievesprivacy preservation by anonymity. The encrypted PHIis appended with data owner’s pseudo identity, which isgenerated by the data generator (doctor). Recall that thepseudo identity di = (Ad, Bd, Ed, Fd), where Ad =r0(Yi1 + H1(IDi)P1) + r1P1 and Bd = r1Yi2. The randomnumbers r0 and r1 ensure that eavesdroppers can not deducethe owners of the PHI. Also, they can not link different flowsof data with the same patients.
The proposed protocol achieves secure search. In Phase2 of the protocol, health record is encrypted with keywordsearch. In Phase 3, a doctor may get a searching trapdoorfrom a patient in order to searching for his/her historyhealth record for diagnosis improvement. Recall that insearching trapdoor Tw = (T1, T2, T3), the term T1 =Yj/(yi1 + H1(w) + yi3H6(β, r)) includes the public key Yj
of the authorized doctor j . Therefore, only doctor j withprivate key yj is able to calculate U1. Also, as Tw is afunction of the keyword w, the doctor is only authorized toaccess the health record with intended keyword w withoutrevealing user’s other health information. Even though aneavesdropper eavesdrops the trapdoor, he cannot guess thekeyword. This is because Tw involves the secret key of thepatient and the doctor, which helps to resist the keywordguess attack.
The proposed protocol achieves time controlled revoca-tion. As described in Phase 3 of the protocol, an enablefunction f (x) is introduced in the trapdoor to control theaccess right of the doctor within an allowable time win-dow. The function (5) determines that only when x1 ≥x2 the value of f (x1)/f (x2) = 1, where x1 and x2 canbe set as the timestamp. Specifically, in U1 = e(A +H6(β, T3/f (t0))E, T1)
1/yj , the term H6(β, T3/f (t0)) =
H6(β, rf (ts)/f (t0)) = H6(β, r) holds if the block genera-tion time t0 < ts , which means that the data is generatedbefore the trapdoor generation time. In other words, the doc-tor is only allowed to find out the user’s records that aregenerated before the time ts (current time).
The proposed protocol achieves system availability.In the consortium blockchain, the consensus mechanismrequires that the transaction senders provide an evidenceto show that the secure keywords are selected from theallowable set. The evidence ce = (A, J,X) concludesthe keyword ciphertext A and the verification vector X.By checking e(A, P1) = e(X1, P1) · J , it guaranteesthat the keyword contained in X and A is identical. Theverification equation e(a·X, X2) = e(X1, X1)means a·X =r1P1, which ensures that the keyword is selected from thepredefined set. Moreover, e(r1P1, X2) = e(X1, X1) makessure that X2 = H1(w)X1. Similarly, by checking whethere(Xi, Xl−i ) = e(Xk, Xl−k), 1 ≤ i, k, l ≤ n, the verifierscan find out whether Xl = (H1(w))l−iXi (Let l > i).
In the private blockchain, the pseudo identity for eachpatient is generated by the doctor from the real identity. Takethe pseudo identity di of IDi as an example, the identityIDi is encrypted with IDi itself as the keyword in order toensure that the ciphertext di is searchable by the intendeddoctor. The user i can authorize his/her doctor to search forthe secure indexes from his/her pseudo identities by sendingan identity searching trapdoor to the doctor. In this way,the doctor can find out which secure keywords belong tothe interested patients. Notably, in the identity searchingtrapdoor Td = (T d
1 , T d2 , T d
3 ), T d1 = Yj/(yi1 + H1(IDi) +
yi3H6(β, rd)) is related with the public key Yj of the doctor.Therefore, only the authorized doctor j with Td is allowedto find out the pseudo identities of the user.
Implementation and PerformanceEvaluation
In this section, we implement the proposed BSSP onJUICE6, which is an open service platform serving forthe study of designing smart contract and blockchain-basedapplications. This platform supports Solidity (designed forwriting contracts) as Ethereum. It also provides friendlyweb/client management and monitoring tools based on Javaand Javascript. Firstly, we illustrate the parameter settingsand platform. Then, we compare the security propertiesamong the proposed protocol and several other protocols.Later, the storage overhead and communication overheadare analyzed. Finally, the proposed BSPP is implemented onJUICE platform to evaluate its performance.
The system parameter λ = 128. We use Type A pairingon the elliptic curve y2 = x3 + x over the field Fp forsome prime p = 3 mod 4. The cryptographic primitives areimplemented on a computer with Intel (R) Core (TM) i7-6700 CPU@ 3.40 GHZ, 3 GB RAM, Microsoft Windows 7operating system, using Java language, as shown in Table 4.JPBC library 7 is used for the simulation.
We utilize JUICE (client version) to build a private testchain comprising only permission nodes in three servers.The configurations are shown in Table 5. In the mainnode, nginx-1.11.3 (a high performance HTTP and reverseproxy server), truffle-2.1.1 (a development framework forthe Ethereum) and JUICE-client (a client version of JUICE)are deployed. The other two nodes only need to deploytruffle-2.1.1 and JUICE-client. The JUICE-client Software(Microsoft Windows Version) is installed for managing andmonitoring transactions in the chain. We skip the details ofthe deployment process due to space limitations.
Note that transactions are published in the local computer(see Table 4 for the configuration) via a permission node(No.1 is chosen in our simulation). The transaction canbe easily put on the test chain without writing additionalintegration codes for Java and Solidity because of Web3j(a lightweight library for Java applications). Since Solidityonly provides now8 accuracy of one second, the timecost is obtained by using shell script and javascriptinstead. All simulations are implemented 500 times foraverage.
Comparisons of Security Properties
Due to the fact there is no blockchain-based PHI sharingscheme for diagnosis improvements up to this end, wechoose recently proposed medical record sharing protocols[3, 11, 13, 17, 18] as benchmarks.
Table 6 compares the security properties of the proposedscheme with blockchain based schemes Xia-I [11], Xia-II [13], Peterson [18], and non-blockchain based schemesYang [3], Zhang [17]. From the table we can find thatonly the proposed scheme and Yang [3] achieve bothsearchability and time controlled revocation. Notably, all theschemes have the properties of access control, data auditingand privacy preservation, which are the critical securityobjectives in health record sharing systems.
Storage Overhead and Communication OverheadAnalysis
Storage overhead. The computer clients in a hospital storethe blocks for the private blockchain of the hospital.The hospital servers store the blocks for the consortiumblockchain. The overall storage overhead is in proportion tothe number of the transactions, which is dynamic increasingwith the time. In this subsection, we analyze the size ofeach kind of block, which is the storage overhead of eachtransaction.
We denote |G1| and |G2| the size of an element ingroup G1 and G2 respectively, |Q| the size of an elementin Zp. The size of β, IDj , j ∈ D, signature, timestampis 9 bytes, respectively. The size of block size is 4 Bytes.The size of previous block hash value, encrypted PHI hashvalue, block identity is 32 Bytes, respectively. As shown inTable 2, the user pseudo identity di = (Ad, Bd, Ed, Fd),where Ad, Bd, Ed are elements in group G1. They have thesize of 3|G1|. Fd is an element in Zp. They totally havethe size of 3|G1| + |Q|. In the secure keyword (ci1, ci2, ).the term ci1 has the same size with user pseudo identity,i.e.,(3|G1| + |Q|). For ci2 = (J,X), J is an element in G2
and X is a vector with n elements in G1. Thus, the size ofci2 is n|G1| + |G2|. Based on the above analysis, the size ofeach block in the private blockchain is (n + 6)|G1 + |G2| +2|Q| + 127.
Regarding the blocks in consortium blockchain, the blockgenerator ID IDk is 9 Bytes. In the secure indexes, eachindex T xi = (IDb, di, ci1) has the size of 6|G1|+2|Q|+9.Therefore, the storage overhead of each block in consortiumblockchain is 8(6|G1| + 2|Q| + 9) + 95. Table 7 illustratesthe storage overhead of per block in computer client and theserver.
Communication overhead. According to Fig. 4, thecommunication overhead comes from two stages: Datageneration stage, data search and access stage. At datageneration stage, the overall communication overhead isin proportion to the number of blocks generated by thedoctors. This number is also dynamic, thus we analyze thecommunication overhead for each block generation step.Firstly, the computer client broadcasts a new transactionT X with η, where T X is composed by data generator IDIDj , user pseudo identity di , secure key words (ci1, ci2),encrypted PHI hash, and contributor signature σj . It brings
Table 10 Time cost (in ms) forpublishing transactions Blockchains Private blockchain Consortium blockchain
n = 500 n = 1000
Tx length (in Bytes) 3674 32882 64882
Max time 5954 6950 8484
Min time 1134 2315 3277
Average time 5584 6569 8164
(n + 6)|G1| + |G2| + 2|Q| + 50 communication cost.The evidence η = (α, β ′) yields |Q| + 9 communicationoverhead. Thus the total communication overhead is (n +6)|G1| + |G2| + 3|Q| + 59. The transaction is acceptedby the blockchain after getting 2
3np validation confirmmessage. Each validation confirm message contains theblock identity (9 Bytes) and an indication of validation(4 Bytes). Thus, the total communication overhead causedby the verification process is 13 × 2
3np. In theconsortium blockchain, publishing a transaction T X =(IDk, T x1, T x2, · · · , T x8, σk) with the 8 ciphertext ci2
yields 8((n+6)|G1|+|G2|+2|Q|+9)+18 communicationoverhead. Similarly, the verification process causes 13 × 23nc overhead, where np denotes the amount of the nodes
in the consortium blockchain.In the data search stage, the patient sends an identity
searching trapdoor T dw and a keyword searching trapdoor Tw
to the hospital. This transmission generates 6|G1| + 2|Q|communication overhead. After finding out the interestedblock identity IDb, the doctor will access the correspondingprivate blockchain and ask for getting the interestedciphertext ci0. The communication overhead of this processis 32. The communication overhead of different phases isshown in Table 8.
Given the system parameter λ = 128, the lengths of Zp,G1 andG2 are 256 bits, 512 bits, and 3072 bits, respectively.Under these settings, the storage overhead of the computerclient and the server is 2|Q| + (n + 6)|G1| + |G2| +127 = (64 ∗ n + 959) Bytes and 48|G1| + 16|Q| + 167 =3751 Bytes respectively. The communication overhead fordata broadcasting in the private blockchain and consortiumblockchain is (n+6)|G1|+|G2|+3|Q|+59 = (64n+923)Bytes and 8((n+6)|G1|+|G2|+2|Q|)+90 = (512n+6746)Bytes, respectively. From the results we can find out thatthe storage overhead of the computer client is in proportionto the size of the keyword set. Also, the communicationoverheads of data broadcasting in both private blockchainand consortium blockchain grow with n.
Implementation and Time Cost Evaluation
As the JUICE has not yet provided the API of publicencryption with keyword search, we measure the time
cost of cryptographic primitives and transaction publishingseparately.
Implement of cryptographic primitives. The crypto-graphic algorithms in the three phases are implemented onthe platform shown in Table 4. We record the time cost ofthe algorithms in Table 9. The algorithms GlobalSetup andKeyGen in system setup phase are finished by the algorithmbuildSystem in our implementations. In order to generate avalid transaction, a computer client is required to computethe ciphertext c, user pseudo identity di , a proof η9. Thealgorithm encrypt is responsible for this task. As the timecost for calculating vector X varies with the size of keywordset n. We implement the algorithms by setting n = 500and n = 1000. The verification algorithms verPrivate andverConsortium check the validity of the new coming datain the private blockchain and consortium blockchain. Thetrapdoors Td and Tw are generated by algorithm trapdoor-Gen. The algorithms searchID and searchW search for theintended user’s identity and and the intended keyword. Theciphertext ci0 is decrypted by decrypt.
From Table 9, we can find out that the average timeof generating a validate transaction at the computer clientincreases with the size of the keyword set n. It is caused bythe vector X = [X1, X2, · · · , Xn], which requires n timesscalar multiplication in G1. Correspondingly, the verifiersin the consortium blockchain also have to perform n timesscalar multiplication in G1, which brings time overheadgrowing with n. The time cost of the other algorithms arenot effected by n. Notably, the table shows that the averagetime for decrypting the ciphertext is 0. This is becausethis algorithm only requires one hash, one XOR and oneexponentiation operations in G2. The computational timeis far lower than 1ms. Thus, the system outputs 0 for thisalgorithm.
Publishing transactions in the blockchain. The time costof publishing a transaction is effected by the length ofthe package. Therefore, we firstly calculate the size of the
9The computer also needs to compute a signature. As signaturealgorithm is not specified in the scheme, we do not consider its timecost in the system.
J Med Syst (2018) 42: 140 Page 17 of 18 140
transactions in the blockchains. As analyzed in the abovesubsection, the lengths of a transaction in private blockchainand consortium blockchain are lp = (n + 6)|G1| + |G2| +2|Q| + 50 and lc = 8(6|G1| + 2|Q| + 9) + 18, respectively.Substituting |G1|, |G2|, |Q| with 64, 384, 32, we obtainlp = (64n + 882) Bytes and lc = 3674 Bytes. Thetransactions are published by padding the data with lengthlp and lc in the defined transaction format of JUICE. Aslp varies with n, we implement the simulations by settingn = 500 and n = 1000 in the consortium blockchain,respectively. The results are illustrated in Table 10.
In the table, when the TX length jumps from 3674 Bytesto 32882 Bytes, the average time cost does not changethat much, from 5584ms to 6569ms. But when the TXlength is 64882 Bytes, the time cost arrives 8164ms. Thereasons can be found out by analyzing the processes oftransaction publishing. It includes padding the transactioninto a package, signing the package, and broadcasting it.After being verified by other nodes, the TX is acceptedand added to the chain. For each transaction, these stepsyield a basic time cost, which is about 5000ms in oursimulations. The time cost increases slowly with the growthof the package length because the time cost of signature,transmission, and verification processes increase with thepackage length. This result demonstrates that the size of thekeyword set should not be too much large in oder to controlthe efficiency of the transaction. But it should be not toosmall because of system availability.
Conclusions
We have proposed a blockchain based secure and privacy-preserving PHI sharing protocol (BSPP) for diagnosisimprovements in e-Health system. Firstly, two blockchains,i.e., private blockchain and consortium blockchain, areintroduced and designed in the system to realize healthrecord sharing. Furthermore, proof of conformance isdefined and devised for the blockchains as the consensusmechanism to construct validated blocks. Based on theblockchains, the PHI sharing protocol is proposed by usingpublic key encryption with keyword search. After gettingtrapdoors from the patient, the doctor is authorized tosearch and access the intended history health records forimproving the diagnosis. Security analysis demonstratesthat the proposed protocol achieves data security, privacypreservation, secure search and time controlled revocation.Furthermore, we implement the scheme on JUICE andevaluate the performance from the aspects of storageoverhead, communication overhead, and time overhead.
For future work, we will develop a specific miner andverifier election algorithm for the e-Health blockchains.Also, we will consider conjunctive keyword search.
Acknowledgments This work is partly supported by the NationalNatural Science Foundation of China (Grants No. 61601005,No. 61571240), Natural Science Foundation of Anhui Province(Grant No. 1608085QF138, No. 1808085MF164), Anhui ProvincialKey Laboratory of Network and Information Security (Grant No.AHNIS2018003), and Scientific Research Staring Foundation ofAnhui Normal University (Grant No. 2014bsqdjj38).
Compliance with Ethical Standards
Conflict of interests Author Aiqing Zhang declares that she has noconflict of interest. Author Xiaodong Lin declares that he has noconflict of interest.
Ethical approval This article does not contain any studies with humanparticipants or animals performed by any of the authors.
References
1. Abbas, A., and Khan, S. U., A review on the state-of-the-art privacy-preserving approaches in the e-health clouds. IEEEJournal of Biomedical and Health Informatics 18(4):1431–1441,2014.
2. Shen, Q., Liang, X., Shen, X., Lin, X., and Luo, H., Exploitinggeo-distributed clouds for a e-Health monitoring system withminimum service delay and privacy preservation. IEEE Journal ofBiomedical and Health Informatics 18(2):430–439, 2014.
3. Yang, Y., and Ma, M., Conjunctive keyword search withdesignated tester and timing enabled proxy re-encryption functionfor e-Health clouds. IEEE Transactions on Information Forensicsand Security 11(4):746–759, 2016.
4. Zhou, J., Cao, Z., Dong, X., and Lin, X., PPDM: A Privacy-preserving protocol for cloud-assisted e-Healthcare systems. IEEEJournal of Selected Topics in Signal Processing 9(7):1332–1344,2015.
5. Zhang, Z., Dong, M., Zhu, L., Guan, Z., Chen, R., Xu, R., andOta, K., Achieving privacy-friendly storage and secure Statisticsfor smart meter data on outsourced clouds, IEEE Transactions onCloud Computing. https://doi.org/10.1109/TCC.2017.2685583.
6. Chang, S., Zhu, H., Dong, M., Ota, K., Liu, X., and Shen, X.,Private and flexible urban message delivery. IEEE Transactionson Vehicular Technology 65(7):4900–4910, 2016.
7. Esposito, C., De Santis, A., Tortora, G., Chang, H., and Choo,K. K. R., Blockchain: a panacea for healthcare cloud-based datasecurity and privacy?. IEEE Cloud Computing 5(1):31–37, 2018.
8. Novo, O., Blockchain meets IoT: An architecture for scalableaccess management in IoT. IEEE Internet of Things Journal5(2):1184–1195, 2018.
9. Wang, J., Li, M., He, Y., Li, H., Xiao, K., and Wang, C.,A blockchain based privacy-preserving incentive mechanism incrowdsensing applications. IEEE Access 6:17545–17556, 2018.
10. Dorri, A., Steger, M., Kanhere, S. S., and Jurdak, R., Blockchain:A distributed solution to automotive security and privacy. IEEECommunications Magazine 55(12):119–125, 2017.
11. Xia, Q., Sifah, E., Smahi, A., Amofa, S., and Zhang, X., BBDS:Blockchain-Based data sharing for electronic medical records incloud environments. Information 8(44):1–16, 2017.
12. Kuo, T., Kim, H., and Ohno-Machado, L., Blockchain distributedledger technologies for biomedical and health care applications.Journal of the American Medical Informatics Association24(6):1211–1220, 2017.
13. Xia, Q., Sifah, E. B., Asamoah, K. O., Gao, J., and Du, X.,MeDShare: Trust-less medical data sharing among cloud service
providers via blockchain, IEEE Access. https://doi.org/10.1109/ACCESS.2017.2730843.
14. Yue, X., Wang, H., Jin, D., Li, M., and Jiang, W., Healthcaredata gateways: Found healthcare intelligence on blockchain withnovel privacy risk control. Journal of Medical Systems 40(10):218,2016.
15. Zyskind, G., Nathan, O., and Pentland, A., Decentralizing privacy:Using blockchain to protect personal data. IEEE Security andPrivacy Workshops: San Jose, 18–20, 2015.
16. Azaria, A., Ekblaw, A., Vieiraand, T., and Lippmanl, A.,Medrec: Using blockchain for medical data access and permissionmanagement. IEEE International Conference on Open and BigData, 25–30, 2016.
17. Zhang, J., Xue, N., and Huang, X., A secure system for pervasivesocial network-based healthcare. IEEE Access 4(99):9239–9250,2016.
18. Peterson, K., Deeduvanu, R., Kanjamala, P., and Boles, K., Ablockchain-based approach to health information exchange networks.
19. Shae, Z., and Tsai, J., On the design of a blockchain platformfor clinical trial and precision medicine. International Conferenceon Distributed Computing Systems (ICDCS 2017): Atlanta,2017.
20. Zhao, H., Zhang, Y., Peng, Y., and Xu, R., Lightweight backupand efficient recovery scheme for health blockchain keys. IEEEInternational Symposium on Autonomous Decentralized System(ISADS): Bangkok, 22–24, 2017.
21. Boneh, D., Crescenzo, G. D., Ostrovsky, R., and Persiano, G.,Public key encryption with keyword search, EUROCRYPT 2004,LNCS. Vol. 3027, pp. 506–522. Berlin: Springer, 2004.
22. Baek, J., Safavi-Naini, R., and Susilo, W., Public key encryption withkeyword search revisited, International Conference on Computa-tional Sciences and its Applications (ICCSA): Perugia, 2008.
23. Hu, C., and Liu, P., An enhanced searchable public key encryptionscheme with a designated tester and its extensions. Journal ofComputer 7(3):716–723, 2012.
24. Shao, J., Cao, Z., Liang, X., and Lin, H., Proxy re-encryption withkeyword search. Information Science 180(13):2576–2587, 2010.
25. Yau, W., Phan, R., Heng, S., and Goi, B., Proxy re-encryption withkeyword search: New definitions and algorithms. InternationalConference, SecTech and DRBC: Jeju Island, 13–15, 2010.
26. Ogata, W., and Kurosawa, K., Oblivious keyword search. Journalof Complexity 20(2-3):356–371, 2004.
27. Ryu, E., and Takagi, T., Efficient conjunctive keyword-searchableencryption. IEEE 21st International Conference on AdvancedInformation Networking and Applications: Niagara Falls, 21–23,2007.
28. Bethencourt, J., Song, D., and Waters, B., New constructionsand practical applications for private stream searching (extendedabstract). IEEE Symposium on Security & Privacy: Berkeley,21–24, 2006.
29. Boneh, D., and Waters, B., Conjunctive, subset, and range querieson encrypted data, TCC 2007, LNCS. Vol. 4392, pp. 535–554.Berlin: Springer, 2007.
30. Wang, X., Huang, X., Yang, X., Liu, L., and Wu, X., Furtherobservation on proxy re-encryption with keyword search. TheJournal of Systems and Software 85:643–654, 2012.
31. Castro, M., and liskov, B., Practical Byzantine Fault Tolerance, theThird Symposium on Operating Systems Design and Implementa-tion: New Orleans, 1999.
32. HL7. HL7 Fast Healthcare Interoperability Resources (FHIR).https://www.hl7.org/fhir/. Accessed: 2017-11-20.
33. Leftwich, R., The path to deriving clinical value from FHIR- InterSystems, http://www.intersystems.com/library/library-item/path-deriving-clinical-value-fhir/. Accessed: 2017-11-20.
