Future Generation Computer Systems 95 (2019) 511–521

Contents lists available at ScienceDirect

Future Generation Computer Systems

journal homepage: www.elsevier.com/locate/fgcs

Privacy-friendly platform for healthcare data in cloud based on

blockchain environment✩
∗
Abdullah Al Omar a , Md Zakirul Alam Bhuiyan b , , Anirban Basu c ,1 , Shinsaku Kiyomoto d ,
∗
Mohammad Shahriar Rahman e ,
a
Department of Computer Science and Engineering, University of Asia Pacific, Dhaka, Bangladesh
b
Department of Computer and Information Sciences, Fordham University, New York, NY 10458, USA
c
University of Sussex, UK
d
Information Security Laboratory, KDDI Research, Saitama, Japan
e
Department of Computer Science and Engineering, University of Liberal Arts Bangladesh, Dhaka, Bangladesh

highlights

• User-centric EHR systems giving total control of data to users.

• Permissioned Blockchain and other functions restrict intruders from a security breach.
• User data are stored in blocks of the permissioned Blockchain.
• Elliptic Curve Cryptography (ECC) makes data secure from other party (pseudonimity).

article info a b s t r a c t

Article history: Data in cloud has always been a point of attraction for the cyber attackers. Nowadays healthcare data in
Received 20 June 2018 cloud has become their new interest. Attacks on these healthcare data can result in annihilating conse-
Received in revised form 25 August 2018 quences for the healthcare organizations. Decentralization of these cloud data can minimize the effect
Accepted 17 December 2018
of attacks. Storing and running computation on sensitive private healthcare data in cloud are possible
Available online 8 January 2019
by decentralization which is enabled by peer to peer (P2P) network. By leveraging the decentralized or
Keywords: distributed property, blockchain technology ensures the accountability and integrity. Different solutions
Blockchain have been proposed to control the effect of attacks using decentralized approach but these solutions
Decentralization somehow failed to ensure overall privacy of patient centric systems. In this paper, we present a patient
Healthcare data in cloud centric healthcare data management system using blockchain technology as storage which helps to attain
Pseudonymity privacy. Cryptographic functions are used to encrypt patient’s data and to ensure pseudonymity. We
Privacy analyze the data processing procedures and also the cost effectiveness of the smart contracts used in
Security
our system.
Smart contract
© 2018 Published by Elsevier B.V.

1. Introduction changes in healthcare discipline. These changes are affecting pa-

tients’ treatment process hence requiring careful data processing.
A lot of work is going on healthcare and information technology For treatment, healthcare is completely dependent on data which
in an amalgamated manner and these works are bringing a lot of arises some concerns over data security and privacy. Authorization
or private access to the personal data of individual patient refers to
✩ A preliminary version of this paper appears in The 10th International Con- the term Privacy, which means only authenticated parties will be
ference on Security, Privacy and Anonymity in Computation, Communication and able to access the private data. Keeping these personal data safe
Storage, SpaCCS Workshops 2017. This is the full version. from the eavesdroppers or intruders refers to the term Security,
∗ Corresponding authors. which means system will be able to protect users’ private data from
E-mail addresses: [email protected] (A.A. Omar), outsiders. Authenticated parties of healthcare data preservation
[email protected] (M.Z.A. Bhuiyan), [email protected] (A. Basu), process will get the access to store data into cloud and retrieve
[email protected] (S. Kiyomoto), [email protected]
from it. Interaction between the system and the patient requires a
(M.S. Rahman).
1 Anirban Basu currently works for Hitachi R&D. The views, opinions and/or secured channel. Different authentication protocol [1–3] have been
findings contained in this article are those of the author(s) and should not be proposed to preserve the privacy and security. Lack of security may
interpreted as an official Hitachi position, policy or decision, unless so designated result in devastating consequences like data loss and data theft. A
by other documentation. lot of intruders are searching for an insecured channel and trying to

https://doi.org/10.1016/j.future.2018.12.044
0167-739X/© 2018 Published by Elsevier B.V.
512 A.A. Omar, M.Z.A. Bhuiyan, A. Basu et al. / Future Generation Computer Systems 95 (2019) 511–521

Fig. 2. An application of MediBchain.

personal data, attackers will require the keys. There is no identifier

for these datasets, only encryption keys will be used to identify
such encrypted and pseudonymous3 data.

1.1. Our contribution

Our platform ensures that the private healthcare data in cloud

is controlled by only patient herself. The main idea of this work
Fig. 1. Entities of EHR system and its Data flow.
is to keep the sensitive healthcare data on the blockchain to attain
accountability, integrity and security. Patients will have the overall
control over the blocks in which their data will be stored. Present
access valuable healthcare data in the cloud network. In most of the healthcare systems lack in pseudonymity as those only store the
cases, data loss in healthcare causes detrimental consequences to data in cloud, but our platform ensures the pseudonymity of pa-
the patients and healthcare organizations. Due to recent attacks on tients. We achieve pseudonymity by using cryptographic func-
healthcare data in cloud systems, different countries like USA [4] tions. MediBchain will regain the interest of patients on EHR sys-
and UK [5] have experienced critical data loss. Personal data of tems and will retain accountability, integrity, pseudonymity, secu-
patients’ were kept without encryption in the cloud which allowed rity and privacy which are being lost with the increasing computa-
the attackers to steal the sensitive private data. Let us assume a tional power of emerging technologies in EHR systems.4 Analysis
scenario where patients keep their data in any Electronic Health of these attributes is discussed in Section 3. Our contributions are
Record (EHR) system [6–11] for preservation and also for further as follows:
access. Fig. 1 depicts a generalized formation of EHR systems. In
the figure patients and healthcare organizations take part in the 1. Security and privacy guarantee: The proposed platform
process as both data sender and data receiver. EHR system is the guarantees accountability, pseudonymity, authenticity and
manager of the whole process that maintains the data flow of the integrity along with data privacy.
system. Top most entity is the cloud where data is kept. Patients 2. Analysis: Rigorous analysis on security, privacy, account-
share their personal data with the doctors and healthcare organiza- ability, pseudonymity and integrity shows how our platform
tions with the help of these EHR systems. Suppose, a patient keeps achieves the above mentioned properties.
her data in the cloud system [7] which uses blockchain as a data 3. Evaluation: We have implemented smart contract and
storage platform. System will store the data on blockchain when shown different analogies of costs (e.g., transaction cost,
the patient shares her data with the system. Accountability of data execution cost). Then we have evaluated a Java implementa-
is system centric in case of the instance [7], whereby the system tion of input and output generation algorithm using Elliptic
will provide data storage service even when data is shared with Curve Cryptography (ECC) for our system. Experimental
the doctors or healthcare organizations. Consequently, the system results will help to compare several aspects of EHR system
is responsible for data loss. and will help to decide whether accept our platform or not.
Fig. 22 depicts the design of our platform in which aforemen-
tioned problems have been addressed by storing the encrypted Organization of the paper: The remainder of the paper is
healthcare data in the cloud system. As a result, if our system organized as follows: Section 2 describes the related work. In
somehow loses the control over blockchain, patients will be ac- Section 3 we discuss the preliminaries. In Section 4, we describe
countable for their data as they will control the encryption keys our platform. In Section 5, we evaluate the platform and analyze it
solely. Data sharing in our system is also being controlled by the formally. We give some concluding remarks in Section 6.
patients. Vulnerabilities related to data preservation have been
addressed in our system by using cryptographic functions along 2. Related work
with blockchain technology. However, our system will store the
encrypted personal data ensuring overall privacy of the data such Some national level frameworks based on cloud for electronic
that even if system gets attacked by the attacker the stolen data medical system have been proposed in [8,9,12]. Patra et al. [12]
will make no sense to them. To get the plaintext of those encrypted proposed a model which is cloud-based and deals with patients’

2 Private Accessible Unit (PAU) is the intermediary unit between blockchain and 3 Pseudonymity refers to the fact of using disguised identity.
data sender or receiver. 4 Analysis of security terminologies are given in Section 5.
 A.A. Omar, M.Z.A. Bhuiyan, A. Basu et al. / Future Generation Computer Systems 95 (2019) 511–521 513

private data. This model ensures cost effectiveness, and this system 2.1. Blockchain
was designed for rural areas where cost plays an immense role.
Medical professionals and policy makers could serve the patients Fig. 3 exhibits the structure of blocks in the blockchain network.
remotely through a cloud-based model which stores all the im- In the figure each block is connected to its previous block by the
perative data in a single cloud. Patients were encouraged to share hash of previous block. Blocks store the time-stamp of being mined
their data in the cloud so that they could get the medical service in the network. Mining takes place in the network by solving
from the professionals remotely. Disease diagnosis and control mathematically complex problems. Miners compete each other to
mine the block so that they could earn some cryptocurrency. In our
could be made by this remote treatment. Data collection and data
platform miners will get Ether from Ethereum Network for mining,
delivery are the key points in symptom analysis. Rolim et al. [13]
and our platform’s Ethereum account will be charged against it.
proposed a framework where the system processes data in the
Simple Ether transfer functionality will be used to transfer the
steps of data collection and data delivery. In this model sensors
Ether from our account. Each block contains corresponding block
play the role of collector which collects the data and sends directly number and data that has been given to store in the blockchain
to the system to store and work with this data further. These which has been denoted as δn .
data would be accessed by the medical professionals and sensors Blockchain-secured transaction-based technology [21] gives
were proposed to be attached with the medical equipment in the users a better security. Bitcoin as well as blockchain has not
this system. Yin et al. [14] introduced cloud based patient centric been failed since these were introduced [22]. The network is shared
system. This model includes three layers: data collection layer, and information is stored throughout the whole network, thus
data management layer and data service layer. [15] described a increasing the reliability of this technology. All the information
blockchain based access control manager for heath data to enhance is treated in a redundant way in blockchain [23]. Blockchain is
the interoperability of this system. Off blockchain mechanism with distributed but it remains all the same for its nodes ensuring the
the involvement of public blockchain was proposed as an access integrity [24,25]. Centralized database can be corrupted and needs
control manager of healthcare data. a third party to maintain it. To change the history of the blockchain
Controllability and Traceability are two key topics of privacy any individual has to control at least 51% of the chain and it will
cost a lot to challenge the immutability of blockchain. This im-
preserving systems. Xiao et al. [6] proposed a model which is
mutable architecture [26–28] is a blessing in archival science too.
based on blockchain to help patients to own, control and share
Identities in the blockchain are covered by pseudonyms by which
their personal data easily and securely with privacy preserva-
privacy for the participants is ensured with a very high degree [29].
tion. This application based model also deals with Secure Multi-
Cryptographic authentication of the time blocks with time-stamp
party Computing (MPC) and Indicator-Centric Schema (ICS). Simic allows the entire network to hold the logs for any interaction in
et al. [16] showed a case study where the study concludes with the blockchain. Blockchain ensures the verifiability of the users.
the illustration of significant benefits of IoT and blockchain in a Other than above discussed characteristics some author explicitly
combined manner. In their work IoT devices were proposed to be mention the key points like trust enabling notion [21,30–32] ,
used as collectors of private health data of the patients’, and real Consensus, Transparency, Smart contract etc.
time data of patient could be saved in blockchain. Scalability of the Blockchain gives a distribution oriented service to be used as a
blockchain in case of Big data has also been tested in their study. storage. All the records that may be stored in the blockchain have to
Ekblaw et al. [7] proposed a prototype named ‘MedRec’ which uses use smart contracts [33,34]. Smart contracts determine the record
blockchain as a backbone and tried to find the security solutions for of data and conditions in the blockchain. These contracts, as a form
EHR systems. They tried to give their prototype — integrity, authen- of code, give a huge power to the programmers to read and write
ticity, auditability and data sharing through blockchain. Elements over the blockchain [34]. As storage, blockchain provides accuracy
of their system are: Registrar Contract (RC), Patient–Provider Rela- and reliability to its users and protects the data from fraud and
being tampered or corrupted [35]. Blockchain as storage maintains
tionship Contract (PPR), Summary Contract (SC), where RC maps
proper decentralization and true redundancy, total privacy and
the identification strings of the participants to their Ethereum
cost reduction [36]. Decentralized web will be the future of this
addresses, PRP issues contracts between two nodes in the system
era [37].
when one node stores and manages medical records for the other,
SC locates the participants medical record history. Jun et al. [17] 3. Preliminaries
proposed a web-based architecture where they showed a secured
accessing multiple patient repository system. They concentrated In this Section, we explain each properties (e.g., security, pri-
mainly on lifetime repository of health data, which consists of vacy and management) that our protocol achieves. Finally, we
client application (CA), central access-control (CAC), local access- introduce the building blocks of our protocol.
control (LAC) and Hospital information system. Linn et al. [15]
described a blockchain based access control manager for health 3.1. Properties
data to enhance the interoperability of this system.
The backbone of our work is blockchain. Blockchain technology 3.1.1. Security and privacy
is popular for its application in Bitcoin cryptocurrency [18], which We briefly describe each of the security and privacy properties
is a public ledger to hold and maintain the transactional data and in the context of our system below.
integrity [19]. One of the reasons for using blockchain technol- 1. Pseudonymity: No entity will be able to identify any party of
ogy in cryptocurrency is its decentralized digital ledger property, our system because users are being identified by a dynamic
which was presented by Nakamoto [20] in his Bitcoin cryptocur- key. As a result users are keeping their selves pseudony-
rency framework. Blockchain’s data structure has been modeled mous.5 Data will not be identified by just seeing it.
by blocks which is linearly sequenced. Each block contains the
cryptographic hashes corresponding to the previous and current 5 Pseudonymity and anonymity are two different things. Anonymity refers to
block to ensure continuity and immutability of the chain. Chaining the fact of being unknown; in our system users are identified with dynamic keys,
mechanism ensures integrity of this secured data structure. hence users are pseudonymous.
514 A.A. Omar, M.Z.A. Bhuiyan, A. Basu et al. / Future Generation Computer Systems 95 (2019) 511–521

Fig. 3. Structure of Blocks in blockchain.

2. Privacy: Only registered parties will be able to interact with Table 1

Terminology table.
the system. Even a registered party will not be able to access
Notation Description
the private raw data of other parties.
3. Integrity: Authenticated parties will be able to store private ID ID of the User
PWD Password of the user
data. UD Encrypted user data
4. Accountability: Each block will be identified by correspond- Uid Block id, where user data will be saved
ing block-id. Only authenticated parties will get them and IDX ID of the User X
will interact with them. PWDX Password of the user X
UDX User X’s Encrypted data
5. Security: Parties will keep their encrypted data in the system UidX Block number, where user X’s data is saved
which ensures secured environment for them. Secured channel Obtained by the authentications process of our system
T (δn ) Transaction of δn through smart contract
HM Set of all identical hashes
3.1.2. Management Γ Address of the issuer
• Users need to register once and by providing the ID and PWD6 ν Address of the message sender
they can easily get into the platform. δn Number of categories in the smart contract
{S , R}authenticated authenticated sender, S and receiver, R
• PAU will act as a Trusted Third Party (TTP) of our system, as {S , R} Unauthenticated Partied, S and R
it will be the medium between user and blockchain. Bi , ξi & Hi Property of different blocks
• In the case of Block id sharing, users need to be very careful
because untrusted access will make the platform vulnerable
for that particular user’s data.

Decryption Scheme:
3.2. Cryptographic tools
Plaintext point, PM ←− (PM + KnB G) ←− PM + KPB
Here, we describe Elliptic Curve Cryptography (ECC) [38] which
only receiver knowing private key nB will retrieve this point, PM
has been used as the cryptographic tool to provide proper crypto-
by removing nB KG.
graphic functionality to the users. Formal definition of ECC will be
given here.
4. MediBchain protocol
Definition 1 (Elliptic Curve Cryptography). Elliptic Curve Crypto-
graphic scheme use the trapdoor function which means if we com- In this section we present the architectural as well as the design
pute B from A through trapdoor function then it is mathematically view of our platform. Table 1. describes the notations that are used
infeasible to regenerate A from B. in the next sections.

trapdoor
A −−−−−→ B 4.1. Overview of our protocol
A↚B
Fig. 4. shows the high level view of our platform. The following
All the functional properties of ECC are described: entities and their roles are described briefly here.
Encryption Scheme: Data sender is the patient, who will send her personal healthcare
Choose, Elliptic group Ep (a, b) and generator point, G ∈ Ep (a, b) data to the system. Data sender plays the vital role in case of data
such that the smallest value of n for that nG = 0 is a very large preservation. Data that will be sent to the system must be accurate
prime number. otherwise wrong data will be detrimental for patient because the
Message, M is encoded in to point Pm ∈ Ep (a, b) whole treatment depends on this sensitive data. However, our
Both sender and receiver selects a private key, nA < n system will take the encrypted data from the users. Encryption of
compute public key PA , such that PA = nA G data will be done in the very beginning of MediBchain’s process
execution.

Ciphertext point, PC = [(KG), (PM + KPB )] Data receiver will request for the data after authenticating itself to
the system.
(K is the random integer and PB is the public key of receiver
here). Registration Unit will act as an authenticator. When any party
(Sender or Receiver) will come for the first time to take the service
of the system; it will store their ID and PWD to be used further.
6 ID and PWD are described in Table 1. Each party will have to register for once and need to preserve the
 A.A. Omar, M.Z.A. Bhuiyan, A. Basu et al. / Future Generation Computer Systems 95 (2019) 511–521 515

ID and PWD. Further they just have to log in and access through
secured channel for transaction of their private data in the cloud.
Private Accessible Unit (PAU) Both the parties of the system will
be able to interact with PAU after authentication. It needs a secured
channel to interact with PAU because through this unit they will
send their private data to the System. It is the intermediary unit
for both the levels of our system, through which the element of
one level will interact with the other.
blockchain will hold the data of the users. Each transaction in
the blockchain will return an identifier. Transaction identifiers will
help the users to access the data further.
For better understanding our system is divided into two levels.
Level-1 is Graphical User Interface (GUI). User will interact with
our system through this level. Elements of level-1 are: Registration
Unit and PAU. PAU is the element of both Levels so it will work
between level 1 and 2. Level-2 is the backend of our system,
which interacts with low level elements of this system through
PAU. Element of level-2 is: blockchain. blockchain is being used
as a repository of healthcare data in our system. Our platform
uses permissioned blockchain which will require authentication to
access.
Steps in the system : Steps of our system could be defined from
Fig. 4.
Step-1: Data sender will request with the ID and PWD to have Fig. 4. High level view of this system.
access in the system.
Step-2: Upon accessing the system in step-2, Data sender will send
data to PAU for storing.
Step-3 & 4: Step 3 & 4 will take place in level-2 of our system, where
PAU will send UID to blockchain and it will return UID for future
access to the blockchain and also for finding the exact Block where
the data were saved.
Step-5: In this step PAU will return the UID to Data sender which
was given by blockchain.
Step-6: From this step rest of the steps are related to Data receiver.
As step-1, this step also requires sign in process and after sign in
Data receiver can request for the data.
Step-7: In this step Data receiver will request for the data to Private
Accessible Unit along with the UID . PAU will receive the UID for
further use.
Step-8 & 9: Step 8 & 9 are same as step 3 & 4 but the data are not
same for this steps. In step-8 PAU will request the blockchain along
with the UID and in Step-9 blockchain will return it.
Fig. 5. Low level view of sending protocol.
Step-10: This is the final step where PAU send the private data to
the Data receiver.

4.2. Formal description of protocol By providing key and the health data to this function data sender
will get UD and will send it to the system. Public key encryption
In this section we will define how Data sender, Data receiver, technique (e.g., Elliptic Curve Cryptography (ECC)) will be applied
and our system will work altogether in case of sending and receiv- to encrypt the private data.
ing the data. In case of data transmission in our system parties need Suppose X is a Data sender of our system. At first X will request
to go through a step called registration. After confirmation of the for getting into the system by providing the IDX and PWDX . Our
Registration Unit that party can access the PAU. system will send confirmation to X if she provides the right ID
and PWD. If X could sign in to the system properly and gets the
4.2.1. Protocol between data sender and system confirmation then she will send her UDX to PAU through a secured
Fig. 5. Shows the low level view of sending protocol. A patient channel. Secured channel will provide the security to the transmis-
will play the role of a data sender in this protocol. Encrypted data sion of data . In this stage PAU will interact with blockchain and this
will be sent to the system. Generation of ciphertexts solely depend interaction with the blockchain will be done by the smart contracts
upon a function known as encryption function. Generalized form of our system.
of this function is Enc(x,y). Below we will see how this function In our system smart contracts have been designed in a way such
that blockchain will return the number of that block which has
works,
been denoted as Uid . Each block has a unique id which will work as
Enc(key, Data) = UD (1) an id of a specific patient. PAU will get the Uid on each transaction
516 A.A. Omar, M.Z.A. Bhuiyan, A. Basu et al. / Future Generation Computer Systems 95 (2019) 511–521

X will get her UDX which has to be decrypted to get the actual
raw data to decrypt the data user need to use Dec(x,y) function.
Dec(key, UD ) = plaintext (2)
X will use Eq. (2) with key and UDX to retrieve the raw data.

4.2.3. Storage of our system

Our system will store the ID and PWD for authentication and
response purpose. Our system solely will manage these private
data in the cloud without depending on any other trusted third
party (TTP) apart from the PAU. Each time when user will store the
data she will get a new block to write so the block-id will change
by time. ID and PWD is dependent on party but Uid is dynamic with
each data storing process.

4.3. Programmatic view of MediBchain

Smart contract of our system has been presented in this paper

through some algorithms. These algorithms have been designed
Fig. 6. Low level view of receiving protocol. to be converted in any blockchain based language (e.g., Solidity,
Golang). Contracts of our system are written in Solidity language
and all the results of this paper are also based on Solidity based
environment. Algorithms 1–3 will be appropriate for any environ-
of data in the system for X it will be UidX . PAU will send the UDX to
ment designed for blockchain environment.
the blockchain then smart contract will return the special id UidX ,
Algorithm-1 describes how our system will check the issuers
for X. After that PAU will send the UidX to X and end the protocol. verifiability. All the hash of our system is denoted by HM and
X has to store this UidX otherwise next time X will not be able to all the valid Hi must be a part of HM . Here, i refers to particular
access her personal private data. number of Hi .
Getting the UidX is the confirmation for X that means the data
has been kept to the system and then X could log out and end the HM ←− {H1 , H2 , H3 , . . . , Hi }
secured channel transmission with the system. HM is the set of all identical hashes of our system that will be
provided in the time of account creation in the blockchain network.
4.2.2. Protocol between data receiver and system Γ &ν are part of HM and play significant role in transaction. Two
Receiving in our system will take two layers of authorization. different notations have been used to reduce the complexity of
Because after registering or signing into our system parties will Algorithm-1, issuer of contract has been denoted with Γ and data
have to provide the Uid to get their data back through the secured uploader/downloader has been denoted with ν . Here, issuer is
the address who runs the contract and message sender is the
channel. In this phase if they fail to submit the Uid then they will
address who sends the message. If both of them are not same then
not be able to access their data. Uid is the key to receive the actual
Algorithm-1 will return false.
data. Fig. 6. shows a low level view of receiving protocol.
Suppose user X wants to retrieve her data which she sent to
the system in sending phase. As like sending phase this phase is Algorithm 1: Checking of Issuer and Sender
also controlled with the authentication or Registration unit where Result: Verified Issuer
X has to sign in first then will be able to access our system. This 1 Γ , ν;
sign in requires the ID and PWD of the user which was given in the 2 ▷ address of the issuer and message sender respectively
registration phase. If X provides appropriate ID and PWD only then 3 while Γ && ν ∈ HM do
the system will send confirmation. After getting the confirmation X 4 if Γ ̸ = ν then
will be able to interact with the system through a secured channel. 5 return;
In this interaction with the system, X has to provide her UidX . 6 else
After getting the UidX system will interact with blockchain. This 7 _;
interaction will take place in level-2 of our system. Only PAU can 8 ▷ It will proceed the code to next algorithm
interact with blockchain, here the smart contracts of our system 9 end
will be the medium. 10 end
Smart contract will send the UidX to blockchain for retrieving
This algorithm is important for security and accountability of
the data of X from it. 256 bit hash of the corresponding block
data transaction. It will work in between the time of smart con-
number will be checked in the smart contract, when the hash will
tract execution and the data transaction (e.g., upload, download)
be matched with any block then it will continue the process to
between MediBchain and blockchain. Eavesdroppers could take a
retrieve the data. Otherwise this exception will be handled through chance of data manipulation in the meantime. All the accounts
the smart contracts. of this system will be the part of HM and also the initiator of
Suppose the hash of any block is, contract and data uploader/downloader will be same. Execution
0xe3b1c14298fc1c149afbf4c8196fb92427ae41e4649b9 of rest of the contract will be dependent on the similarity of
34ca495991b785 Γ &ν . Algorithm-2 will be initiated after Algorithm-1, in which δn
Only if the hash of UidX ’s corresponding block is same then X represents the number of categories to be held by the structure of
will be able to get her data. In our system blockchain will return data in our contracts.
the UDX to PAU and it will be redirected to X later. After this data Algorithm-2 will be executed after fulfilling the conditions be-
retrieval session will have its end. low.
 A.A. Omar, M.Z.A. Bhuiyan, A. Basu et al. / Future Generation Computer Systems 95 (2019) 511–521 517

Algorithm 2: Transaction of Data Algorithm 3: Block-id Generation

Result: Data Upload
∑n Result: Block-id
1 struct Data ←− 1 δn 1 ξi , Hi ;
2 Data[] data; 2 ▷ Will hold the Hi ←− Hash of Block, ξi ←− block number
3 bool←−0; 3 while bool do
4 while n do 4 ▷ Returned value from Algorithm 2
5 ▷ getting input from message sender,ν 5 if bool ←− 1 then
6 if ν returns string
∑n then 6 ξi ←− block.Number();
7 data ←− 1 δn ;
7 Hi = block.blockhash(ξi );
8 bool ←− 1; 8 return Hi
9 return bool; 9 else
10 else 10 return Null;
11 return bool; 11 end
12 end 12 end
13 end

the corresponding block number ξi and block.blockhash() will

Iff, return Hi .

Γ && ν ∈ HM and, Bi ∋ ξi , Hi
Γ (issuer) = ν (message sender) ξi and Hi are the properties of each block, Bi by which our system
will work
Here, Γ is the address who runs the contract and ν is the address
who sends the message. If both of them are not same then this Hi ←− block.blockHash(i )
algorithm will return false. Users’ (patients’) data will be having Programmatically each Hi will be generated from its corresponding
different categories to be inputted. Different categories mean that ξi . As instance, if block.blockhash() gets ξ1 as a parameter it
the healthcare data come in different types, suppose user wants to will return H1 or if it gets ξ20 the function will return H20 . So the
save Blood sugar’s data and also Blood pressure’s data these two relation can be written as,
are different. By category we refer to this scenario that the user
{H1 , H2 , H3 , H4 , . . . , Hi } ≡ {ξ1 , ξ2 , ξ3 , ξ4 , . . . , ξi }
can store different diagnostic results in a block. Hence, we have
designed two different contracts. In Algorithm-2 each structure 5. Protocol analysis & evaluation
will hold maximum four different types of healthcare data to be
stored in the block if we change data part as follows, 5.1. Security analysis
4
∑ ◦ Pseudonymity: Data Sender, S and Receiver, R will not be
data ←− δn
identified by any party during transaction.
n=1

We have another smart contract which takes maximum eight • Pseudonymity of S : After authentication S will upload
different types of health data to be stored in the block. For that we the encrypted private data, UD . Any other party will not
be able to identify S by looking her UD because of its
need to change data part again. So above data part will be changed
identificationless attribute.
as follows-
• Pseudonymity of R: Hi will be used to trace particular
8 Bi of the blockchain which holds the private data of S .
∑
data ←− δn During transaction T party will hold the Hi to have her
n=1 UD back from the system, these Hi s are as sensitive as
the private data for receiver. Hi will be held by only our
We have shown some computational analysis in Section 5.3 using
party which ensures the pseudonymity of Data Receiver
the variation of data storing capabilities of different smart con-
because no one will be able to detect S during T or even
tracts.
after T because of encrypted property of UD .
Line-1 is showing that the structure of smart contract can take Suppose, α {ID,PWD} is the function for authentication,
n number of individual data from a particular patient at a time.
In the loop data will be assigned to its corresponding structure in α{ID,PWD} −→ {S , R}authenticated
line- 7 and then the data will be written in the block in the same ◦ Privacy: Registration Unit and UD ensures the privacy of the
contract. A particular structure will be written in a particular block. {S , R}authenticated and data respectively.
As mentioned earlier each block of blockchain holds different
id which is not same as HM . HM represents the account id of • Privacy from system: Parties, {S , R}authenticated of our
blockchain network whereas hash ids has been denoted with Hi . system have privacy as pseudonymity of users is main-
A bool variable has been returned from Algorithm-2 as a flag for tained. α {ID,PWD} will ensure the access in the sys-
Algorithm-3. In Algorithm-3, ξi represents the block number and tem. This controlled access of {S , R}authenticated pro-
vide privacy to the users of our system. Therefore, UD
Hi represents the hash of particular block.
of {S , R}authenticated cannot be compromised any way.
Algorithm-3 will return hash id Hi if all the requirements will be • Privacy from other parties: S will have her dedicated Bi
fulfilled by the contract. It will take a variable named bool by which in the blockchain to store UD . So, if any {S ,
this algorithm will define whether to return block-id, Hi or not. R}authenticated of our system tries to access any other
Functions block.Number() and block.blockhash() are the party’s data it will not be able to access the particular
syntax of Solidity language, where block.Number() will return block as each party will have their dedicated Hi .
518 A.A. Omar, M.Z.A. Bhuiyan, A. Basu et al. / Future Generation Computer Systems 95 (2019) 511–521

Clearly, the former analysis guarantees a very strong privacy

of parties because only {S , R}authenticated will be able to
access as well as retrieve data from that particular Bi .
◦ Integrity:
• Access request data integrity: Each time S or R tries
to access the system, she needs to authenticate herself
primarily. This access request needs to be done by both
the dynamic entities- S and R of system. These access
requests will require correct ID and PWD, which will
be generated by party itself and will be holding by
the database of system. So without S or R and system
these authentication data will not be known by anyone.
By which system guarantees the access request data
Fig. 7. Computation time in generating input.
integrity.
• User data Integrity: Use of Enc(x,y) function ensures the
data integrity as the data in the blockchain will make no
sense to any other person except the data owner. After
retrieving the data from the system {S , R}authenticated
need to decrypt the UD with Dec(x,y) function. In order
to break this integrity level attacker needs to break the
security of underlying encryption scheme, ECC.

All the data that are related to our healthcare data manage-
ment system guarantees integrity.
◦ Accountability:
• Transactional Bi : When any party will come to save
its data to the system a unique number or nonce, Hi
will be returned which leverages the accountability of
our system. Only party itself will be holding this nonce Fig. 8. Computation cost of transaction and execution of smart contract.
which makes the party accountable for its UD because
without valid information about Bi ∋ ξi , Hi party will
not be able to access her private data from blockchain.
• PAU as bridge: Interaction of {S , R}authenticated with
the system is controlled. This controlled path refers
to the secured channel which will be created by the
party itself through α {ID,PWD}. Through this channel
{S , R}authenticated will interact with PAU which is a
bridge between the system and blockchain. Secured
channel makes the bridge accountable for secured T
with blockchain.

◦ Security: Each Bi will be dedicated to {S , R}authenticated and

their Hi is secured as integrity is guaranteed in our platform.
As a result, these Bi will not be accessed by any {S , R}. If
Fig. 9. Computation cost of transaction and execution of smart contract.
attacker somehow manages to intrude into the blockchain
network patients’ sensitive data will make no sense because
of encrypted attribute of data. Accessing the raw data of
5.2. Computation & evaluation
patient will need the keys and Dec(x,y) will return the raw
data to parties. So, the data security is guaranteed in our
We set up an environment to evaluate our protocol by writing
platform.
programs using Solidity 0.4.11 and JAVA 1.8 with a computer
The equation for Transaction, Intel(R) Core(TM) i5, CPU-3.30 GHz, 8 GB of RAM, Win 8, 64-bit OS.
We deployed Elliptic Curve Cryptography (ECC) for generating and
{{ } retrieving the input and output respectively.

T (δn ) ←− ∀HM : Γ ∈ HM , ν ∈ HM , Γ = ν and

5.3. Data sharing
{ }}
We test the computation time to generate the cipher texts. Each
∀α{S ,R}authenticated ID, PWD
{ }
encryption is an isolated process. Fig. 7. presents the data encryp-
tion time versus string size of healthcare data. We take several
After analyzing each of the properties we can conclude with saying inputs to see how the rate of growth of time for encryption changes
that no platform secures blockchain based pseudonymous health- with variable input size. We take 5 to 30 kb of data to analyze the
care data other than our platform- ‘MediBchain’, in the best of our encryption time of different data size. From the resultant graph
knowledge. we can observe the rate of growth of curve is nearly linear which
 A.A. Omar, M.Z.A. Bhuiyan, A. Basu et al. / Future Generation Computer Systems 95 (2019) 511–521 519

means the encryption time increases with increase of data size.

Data sharing phase of our system is variable and independent
process, variable means that input size could vary for different
users and independent means the encryption of different users’
data are not dependent on each other.

5.3.1. Data manipulation with smart contract

The issues that have been mentioned in the manuscript could be
solved with other technologies, but through blockchain environ-
ment we get the proper distributive attribute which lacks in others.
Blockchain gives us the option to use it as distributed ledger which
makes the technology a viable option. Ethereum environment has
been used to analyze the effectiveness of this new idea of EHR
Fig. 10. Transaction cost of smart contract with variable input.
system over windows operating system. Ethereum is the most
effective platform to run Dapps (Distributed Apps) using solidity
language that is the reason why Ethereum platform has been used
to access blockchain.
Before getting access of a block in the blockchain network data
will be accessed by our smart contract. Use of smart contract will
cost some gas which is known as the cryptofuel of Ethereum Virtual
Machine (EVM). To run any Dapp (distributed application) on the
Ethereum environment the executed application will need to have
some transactions in the network; in return of transaction the
environment costs the executor some gas. Initiator or executor
of transaction will get the gas in exchange of Ether in Ethereum
environment. We evaluate two smart contracts, one with 4 inputs
category other with 8 inputs category. In context of programming
language which is number of variables to take input from party.
Fig. 11. Execution cost of smart contract with variable input. Sections 5.3.2 and 5.3.3 will depict the analogy of different terms
of smart contract with 4 inputs category and 5.3.4 and 5.3.5 will
depict the analogy between two different smart contracts with
variable inputs, where . We tried to show some analogy based on
the transaction and execution cost of our smart contract.

5.3.2. Transaction cost vs. execution cost

Fig. 8. depicts the analogy between transaction and execution
cost of smart contract. To have an accurate analyzing result we
run the smart contract with different input sizes that varies from
5 to 100 characters of string. Curves in Fig. 8. shows the cost is
increasing with the input size. But the rate of growth of these two
curves is same between the intervals and linear too.

5.3.3. Block-id generation costs

One of the key terms to be ensured while writing smart con-
Fig. 12. Computation time in generating actual output. tracts was block-id generation. Block-id generation will cost for
execution and transaction. We analyze the block-id generation cost
with different string length, but interestingly it costs same for all
the inputs. Fig. 9. shows the curves of execution and transaction
cost of block-id generation. It is clear that each parameter is almost
constant with the increase of the size of string. Transaction and
execution cost is same for growing input size.

5.3.4. Transaction cost of variable inputs

Parties of our system may have to upload a vast amount of data
in different categories. Smart contract may have to be redesigned
so that we analyze the cost to see how our platform reacts with
an increasing amount of category to store it in blockchain. Before
this subsection we were talking only about smart contract having
4 categories to take as input, but for having an effective analogy
we will give 8 categories as input to see how the behavior changes
Fig. 13. Input generation vs. Output retrieval time of system.
of our platform. Fig. 10. shows us the analogy between two smart
contracts in which one will take 4 inputs and other will take 8
inputs. In Fig. 10. we can see that smart contract having 8 categories
of input will cost higher, but the rate of growth of curves are similar
and the cost will increase with string size.
520 A.A. Omar, M.Z.A. Bhuiyan, A. Basu et al. / Future Generation Computer Systems 95 (2019) 511–521

5.3.5. Execution cost of variable inputs [7] Ariel Ekblaw, Asaph Azaria, John D Halamka, Andrew Lippman, A case study
Fig. 11. presents the execution cost of smart contract with for blockchain in healthcare:medrec prototype for electronic health records
and medical research data, in: Proceedings of IEEE Open & Big Data Confer-
variable input. As explained above smart contracts may vary in
ence, volume 13, 2016, p. 13.
different scenario, so that we present the execution costs’ analogy [8] E. Hendrick, B. Schooley, C. Gao, CloudHealth: developing a reliable cloud plat-
in Fig. 11. The rate of growth of curves is similar but smart contract form for healthcare applications, in: IEEE 10th Consumer Communications
with 8 inputs will cost more gas while execution with increasing and Networking Conference (CCNC), 2013.
string lengths. [9] Omniyah Gul, Mahmoud Al-Qutayri, Chan Yeob Yeun, Quang Hieu Vu, Frame-
work of a national level electronic health record system, in: Cloud Computing
Technologies, Applications and Management (ICCCTAM), 2012 International
5.4. Output generation Conference on, IEEE, 2012, pp. 60–65.
[10] Peng Zhanga, Jules Whitea, Douglas C Schmidta, Gunther Lenzb, S Trent
To get the plaintext or actual private healthcare data of patient Rosenbloomc, Fhirchain: Applying blockchain to securely and scalably share
clinical data, J. Netw. Comput. Appl. (2018).
the data from blockchain need to be decrypted. As like encryption, [11] Gaby G Dagher, Jordan Mohler, Matea Milojkovic, Praneeth Babu Marella,
decryption or output generation process is also isolated. All the Ancile: Privacy-preserving framework for access control and interoperability
output generation for the parties is independent from each other. of electronic health records using blockchain technology, Sustainable Cities
To analyze the output retrieval time we take different sets of string Soc. 39 (2018) 283–297.
[12] Manas Ranjan Patra, Rama Krushna Das, Rabi Prasad Padhy, Crhis: cloud based
5 to 30 kilobytes of data at a single input to get an actual idea of
rural healthcare information system, in: Proceedings of the 6th International
output retrieval time for the patients. In Fig. 12. curve shows that Conference on Theory and Practice of Electronic Governance, ACM, 2012, pp.
the rate of growth of time is related with the input size as the time 402–405.
is increasing for decryption with input size. The curve is nearly [13] Carlos Oberdan Rolim, Fernando Luiz Koch, Carlos Becker Westphall, Jorge
linear. Time is in millisecond in the graph that is computed with Werner, Armando Fracalossi, Giovanni Schmitt Salvador, A cloud computing
solution for patient’s data collection in health care institutions, in: eHealth,
Java during decryption. Elliptic Curve Cryptography (ECC) is used Telemedicine, and Social Medicine, 2010. ETELEMED’10. Second International
to generate the plaintext. Conference on, IEEE, 2010, pp. 95–99.
[14] Yin Zhang, Meikang Qiu, Chun-Wei Tsai, Mohammad Mehedi Hassan, Atif
5.4.1. Input generation vs. Output retrieval Alamri, Health-cps: Healthcare cyber-physical system assisted by cloud and
big data, IEEE Syst. J. 11 (1) (2017) 88–95.
Generation of input and output is independent from each other.
[15] Laure A Linn, Martha B Koo, Blockchain for health data and its potential use in
Encryption will take place in the time of giving input and decryp- health it and health care related research, in: ONC/NIST Use of Blockchain for
tion will take place in the time of output. Fig. 13. depicts that two Healthcare and Research Workshop. Gaithersburg, Maryland, United States:
processes take very different amount of time while processing. ONC/NIST, 2016.
[16] Miloš Simić, Goran Sladić, Branko Milosavljević, A case study iot and
With the string length both the time increase but encryption needs
blockchain powered healthcare.
more time than decryption. For encryption it takes 80 to 90 ms [17] Jun Choe, Sun K Yoo, Web-based secure access from multiple patient reposi-
where decryption needs less than 10 ms. tories, Int. J. Med. Inf. 77 (4) (2008) 242–248.
[18] Siraj Raval, Decentralized Applications: Harnessing Bitcoin’s Blockchain Tech-
6. Conclusion nology, O’Reilly Media, Inc, 2016.
[19] Melanie Swan, Blockchain: Blueprint for a New Economy, O’Reilly Media, Inc.,
2015.
The paper presented privacy preserving platform for healthcare [20] Satoshi. Nakamoto, Bitcoin: A peer-to-peer electronic cash system. 2008.
data in cloud. We have defined a set of security and privacy require- [21] Roman Beck, Jacob Stenum Czepluch, Nikolaj Lollike, Simon Malone,
ments for healthcare data management systems and argued why Blockchain-the gateway to trust-free cryptographic transactions, in: ECIS,
page ResearchPaper153, 2016.
such attributes are necessary for a healthcare data management
[22] Rocky Dariua, 4 Features of Blockchain Technology, 2016.
system in cloud. Our analysis shows that our platform satisfies all [23] Mike Sharples, John Domingue, The blockchain and kudos: A distributed sys-
such requirements. Experimental performance evaluation shows tem for educational record, reputation and reward, in: European Conference
that this platform runs well in blockchain environment. In the on Technology Enhanced Learning, Springer, 2016, pp. 490–496.
future we will try to explore the interoperability between differ- [24] Jordi Cucurull, Puiggalí Jordi, Distributed immutabilization of secure logs, in:
International Workshop on Security and Trust Management, Springer, 2016,
ent entities (e.g., diagnostic center, hospital, doctors, patients) of pp. 122–137.
healthcare process, and another direction would be to address the [25] JJ. Xu, Are blockchains immune to all malicious attacks? Financ. Innovat.
issue of handling key-theft/loss mechanisms or key distribution (2016).
techniques. [26] R. Böhme, N. Christin, B. Edelman, Bitcoin: Economics, technology, and gov-
ernance, Econ. Perspect. (2015).
[27] J. Sun, J. Yan, KZK. Zhang, Blockchain-based sharing services: What blockchain
References technology can contribute to smart cities, Financ. Innovat. (2016).
[28] Ingo Weber, Xiwei Xu, Régis Riveret, Guido Governatori, Alexander Pono-
[1] Xiong Li, Jianwei Niu, Md Zakirul Alam Bhuiyan, Fan Wu, Marimuthu Karup- marev, Jan Mendling, Untrusted business process monitoring and execution
piah, Saru Kumari, A robust ecc based provable secure authentication protocol using blockchain, in: International Conference on Business Process Manage-
with privacy protection for industrial internet of things, IEEE Trans. Ind. Inf. ment, Springer, 2016, pp. 329–347.
(2017). [29] Richard Hull, Vishal S Batra, Yi-Min Chen, Alin Deutsch, Fenno F Terry
[2] Xiong Li, Maged Hamada Ibrahim, Saru Kumari, Arun Kumar Sangaiah, Heath III, Victor Vianu, Towards a shared ledger business collaboration
Vidushi Gupta, Kim-Kwang Raymond Choo, Anonymous mutual authentica- language based on data-aware processes, in: International Conference on
tion and key agreement scheme for wearable sensors in wireless body area Service-Oriented Computing, Springer, 2016, pp. 18–36.
networks, Comput. Netw. 129 (2017) 429–443. [30] Svein Ølnes, Beyond bitcoin enabling smart government using blockchain
[3] Abdullah Al Omar, Mohammad Shahriar Rahman, Anirban Basu, Shinsaku technology, in: International Conference on Electronic Government and the
Kiyomoto, MediBchain: A blockchain based privacy preserving platform for Information Systems Perspective, Springer, 2016, pp. 253–264.
healthcare data, in: Security, Privacy, and Anonymity in Computation, Com- [31] David S Gerstl, Leveraging bitcoin blockchain technology to modernize secu-
munication, and Storage, Springer International Publishing, 2017, pp. 534– rity perfection under the uniform commercial code, in: International Confer-
543. ence of Software Business, Springer, 2016, pp. 109–123.
[4] FoxNewsHealth, ’Ransomware’ Cyberattack Cripples Hospitals Across Eng- [32] Duane Wilson, Giuseppe Ateniese, From pretty good to great: Enhancing pgp
land, Associated Press, 2017, p. 5. using bitcoin and the blockchain, in: International Conference on Network
[5] April Glaser, U.S. hospitals have been hit by the global ransomware attack - and System Security, Springer, 2015, pp. 368–375.
Recode, 2017. [33] Mike. Jacobs, A Proposed Blockchain Reference Architecture, 2016.
[6] Xiao Yue, Huiju Wang, Dawei Jin, Mingqiang Li, Wei Jiang, Healthcare data [34] Rachel Frank, ISO/TC 307 - Blockchain and distributed ledger technologies.
gateways: found healthcare intelligence on blockchain with novel privacy risk [35] Victoria Louise Lemieux, Trusting records: is blockchain technology the an-
control, J. Med. Syst. 40 (10) (2016) 218. swer? Records Manag. J. 26 (2) (2016) 110–139.
 A.A. Omar, M.Z.A. Bhuiyan, A. Basu et al. / Future Generation Computer Systems 95 (2019) 511–521 521

[36] Joaquin Garcia-Alfaro, Data Privacy Management, Autonomous Spontaneous Dr. Anirban Basu is a Researcher at Hitachi R&D in Japan,
Security, and Security Assurance, Springer, 2014. and a Visiting Research Fellow at the University of Sus-
[37] Zach Herbert, Why blockchains are the future of cloud storage. – Sia Blog, sex. He holds a Ph.D. in Computer Science (2010) and
2017. a Bachelor of Engineering (Hons.) in Computer Systems
[38] Neal Koblitz, Elliptic curve cryptosystems, Math. Comput. 48 (177) (1987) Engineering (2004) from the University of Sussex. His
203–209. research focuses on a user-centric view of privacy; and
computational trust as an information security paradigm
in an increasingly knowledge-based connected world. His
work has generated over 70 refereed publications and
Abdullah Al Omar received his B.Sc. degree from Depart- about 20 co-authored Japanese patent applications. He is
ment of Computer Science and Engineering, University of particularly active within the IFIPTM computational trust
Asia Pacific in 2016. Currently he is working as a Lecturer management community.
at the Department of Computer Science and Engineering,
University of Asia Pacific. His research interests include
Applied Cryptography, Protocol Construction, Privacy- Shinsaku Kiyomoto received his B.E. in engineering sci-
preserving and secured platform design and blockchain. ences and his M.E. in Materials Science from Tsukuba Uni-
versity, Japan, in 1998 and 2000, respectively. He joined
KDD (now KDDI) and has been engaged in research on
stream ciphers, cryptographic protocols, and mobile se-
curity. He is currently a senior researcher at the Informa-
tion Security Laboratory of KDDI R&D Laboratories (now
KDDI Research, Inc). He was a visiting researcher of the
Md Zakirul Alam Bhuiyan received the Ph.D. degree and Information Security Group, Royal Holloway University of
the M.Eng. degree from Central South University, China, London from 2008 to 2009. He received his doctorate in
in 2013 and 2009 respectively, and the BSc degree from engineering from Kyushu University in 2006. He received
International Islamic University Chittagong, Bangladesh, the IEICE Young Engineer Award and IEICE Achievement Award in 2004 and 2016
in 2005, all in Computer Science and Technology. He respectively. He is a member of JPS and IEICE.
is currently an assistant professor of the Department
of Computer and Information Sciences at the Fordham
University. Earlier, he worked as an assistant professor at Mohammad Shahriar Rahman is currently an associate
the Temple University and a post-doctoral fellow at the professor at the University of Liberal Arts Bangladesh.
Central South University, China, a research assistant at Earlier, he worked as a research engineer at the Infor-
the Hong Kong PolyU, and a software engineer in indus- mation Security group of KDDI Research, Japan. He re-
tries. His research focuses on dependable cyber physical systems, WSN applications, ceived his Ph.D. and M.S. degrees in information science
big data, cloud computing, and cyber security. He served as a lead guest editor of from Japan Advanced Institute of Science and Technology
IEEE TBD, ACM TCPS, Information Sciences, and so on. He also served as general (JAIST), in 2012 and 2009 respectively, and B.Sc. in com-
chair, program chair, workshop chair, publicity chair, TPC member, and reviewer of puter science and engineering from University of Dhaka,
international journals/conferences. He is a member of IEEE and a member of ACM. Bangladesh, in 2006. His research interests include secure
protocol construction, privacy-preserving computation
and security modeling. He is a member of International
Association for Cryptologic Research (IACR). Dr. Rahman has co-authored 40+
research papers and submitted 8 co-authored Japanese patent applications.