Abstract
Currently, blockchain technology, which is decentralized and may provide tamperresistance to recorded data, is experiencing exponential growth in industry and research. In this paper, we propose the MIStore, a blockchainbased medical insurance storage system. Due to blockchain’s the property of tamperresistance, MIStore may provide a highcredibility to users. In a basic instance of the system, there are a hospital, patient, insurance company and n servers. Specifically, the hospital performs a (t, n)threshold MIStore protocol among the n servers. For the protocol, any node of the blockchain may join the protocol to be a server if the node and the hospital wish. Patient’s spending data is stored by the hospital in the blockchain and is protected by the n servers. Any t servers may help the insurance company to obtain a sum of a part of the patient’s spending data, which servers can perform homomorphic computations on. However, the n servers cannot learn anything from the patient’s spending data, which recorded in the blockchain, forever as long as more than n − t servers are honest. Besides, because most of verifications are performed by recordnodes and all related data is stored at the blockchain, thus the insurance company, servers and the hospital only need small memory and CPU. Finally, we deploy the MIStore on the Ethererum blockchain and give the corresponding performance evaluation.
Introduction
Bitcoin, proposed in 2009 by Satoshi Nakamoto [1], is the first decentralized cryptocurrency which maintains a public transaction ledger, called blockchain, in a distributed manner without the central authority. The core technological innovation of Bitcoin is Nakamoto consensus which provides a highprobability guarantee that an adversary cannot alter a transaction once this transaction is sufficiently deep in the blockchain, assuming honest nodes control the majority of computational resources in the system. The Nakamoto blockchain works in a permissionless model, where any node can freely join and leave the protocol, and there is no apriori knowledge of the set of consensus nodes. Alternative cryptocurrencies called altercoins (e.g., Litecoin [2], Ripple [3] and Ethereum [4]) have achieved enormous success. Several consensuses to manage blockchainbased ledgers have been proposed: proofofwork [5], proofofstake [6, 7], proofofspace [8], proofofactivity [9], proof ofhumanwork [10], practical Byzatine faulttolerance [11], or some combinations [12,13,14]. Especially, most existing cryptocurrencies, including Bitcoin, adopt proofofwork.
Blockchain is a tamperresistant timestamp ledger of blocks that is utilized to share and store data in a distributed manner. The stored data may be payment records (e.g., Bitcoin, Litecoin), contract (e.g., Ethererum) or personal data. Currently, blockchain has attracted enormous attention from academics and practitioners (e.g., computer science, finance and law) due to its signal properties containing distributed structre, security, privacy and immutability [17]. In blockchain, users can generate a arbitrary number of public keys that effectively prevents them from being tracked, and this ensure users’ privacy. Recently, blockchain has been widely utilized in nonmonetary applications including but not limited to: securing robotic swarms [19] and verifying proof of location [20]. Moreover, blockchain can use cryptography technologies [31,32,33] to improve it security, privacy and functionality.
Recently, blockchainbased medical system is a hot topic. Yue et al. [18] proposed a APP of sharing healthcare data, where patients control, send and own their data easily. Moreover, Qi et al. [30] proposed the MeDShare, a system that can address the problem of medical data sharing among medical big data servers in a trustless environment. Besides, Ekblaw et al. [29] presented the MedRec, decentralized record management system to resolve electronic health records by using blockchain. In the researches, they did not provide the function of homomorphic computing for data recorded at the blockchain, and they just utilized the blockchain as a storage tool. Therefore, in the systems, a node cannot help others to process encrypted data.
In an ideal and basic medical insurance business, there are a hospital, a patient and an insurance company. The insurance company can to know a sum of the patient’s specified spending records, however the company cannot learn the details of the spending records. Furthermore, servers can help the insurance company to process a patient’s spending records without learning anything about the spending records. Otherwise, it will result in a risk of information leakage. Moreover, once the insurance company attempt to know the patient’s sum of spending records, the insurance company can get his desired result without any help of hospital and patient. Finally, the most important point is that all data must be verifiable and tamperresistant. Otherwise, the system could not be credible.
To address the problems, in the present paper, we propose the MIStore, a blockchainbased medical insurance storage system. Features of MIStore can be summarized as follows:

Decentralization. There is no the third party authorities to provide any authentication. Moreover, any node may become some hospital’s server if the node and the hospital wish. Besides, data is stored at the blockchain, rather than cloud servers.

Secure data storage. On the one hand, every transaction’s publicly verifiable data must be verified by all recordnodes before the transaction is included in the blockchain. On the other hand, we suggest that MIStore adopts the Practical Byzantine Faulttolerance (PBFT) to be the consensus scheme of the blockchain, and all related data is stored at the blockchain. Due to PBFT’s property of tamperresistance, data, which has been included by recordnodes in the blockchain, cannot be modified or deleted by anyone. Due to the above two points, it provides high credibility to all users. Therefore, once a transaction has been included in the blockchain, all its publicly verifiable data is credible.

Threshold. For instance, a hospital performs a (t, n)threshold MIStore protocol among a patient, an insurance company and n servers. Firstly, the hospital store confidential data in the blockchain. Secondly, the servers cannot learn anything from the data if more than n − t servers are honest. Thirdly, after the insurance company sends a query to the blockchain, if he can collect t correct responses to the query, then he can obtain his desired result. Finally, anyone (including the insurance company) cannot learn anything with less than t responses.

Verifiable. Key data stored at the blockchain is verifiable. Specifically,

Anyone can verify whether the verification key is valid.

Any server can verify whether his coreshare is correctly computed by the corresponding hospital.

The insurance company can verify whether responses are correctly computed by corresponding servers, respectively.

Patient may verify whether his spending data is correctly processed by corresponding hospital.


Efficient verification. Key data is recorded in the transaction’s payload, and most of key data is publicly verifiable. Therefore, recordnodes can help other nodes to verify payloads’ data before the transactions are recorded in the blockchain. Consequently, once a transaction has been recorded in the blockchain, the transaction’s publicly verifiable data is credible. After that, the transaction’s receiver needs not to perform the verifications performed by recordnodes. Moreover, the receiver just needs to perform very little verification that can be performed only by him. In this way, it significantly reduces users’ verifying computations, and receivers just perform some simple and few computations, rather than complex and massive computations.

Efficient homomorphic computation. According to insurance company’s query, servers can perform homomorphic multiplications and additions on their shares, and then generate responses. Moreover, the homomorphic computations calculated by servers are efficient additions and multiplications of finite field.
Organization
In “Background”, background is introduced. In “System setting and model”, we show the system setting and model. In “An overview of MIStore”, an overview of MIStore is given. We introduce construction of the MIStore system in “MIStore”. In “Performance evaluation”, a performance evaluation is given. Finally, a short conclusion is given in “Conclusion”.
Background
Bitcoin [1] is a decentralized payment scheme in which every participant maintains its own local copy of the whole transaction history, “chain” of “blocks” called blockchain. Blockchain is maintained by anonymous recordnodes, called miners, via executing a consensus scheme that extends the blockchain. The recordnodes are connected by a reliable peertopeer network. Bitcoin consistency relies on the idea of computational puzzles—a.k.a. moderately proofofwork put forth by Dwork and Naor [16]. In Bitcoin, payers broadcast transactions and miners collect transactions into their local blocks. A block contains two parts: blockbody and blockheader. Specifically, the blockbody contains the transactions. The blockheader contains the hash value of previous block, the current Unix time, target value, a nonce and a merkle root of transactions. In Bitcoin consensus, a block to be valid if the cryptographic hash of its header must be smaller than a target value. Moreover, if some miner finds a solution of the cryptographic puzzle, then he immediately broadcasted his block including the solution to others. After that, upon verifying the block, others will receive and add this block as a new one in its local blockchain and then continue the mining process on its updated blockchain. The creator of the block is rewarded with bitcoins (coins in Bitcoin system) via the coinbase transaction which is the first transaction in the blockbody. Consequently, bitcoins are created and distributed among miners. Moreover, this creator is also rewarded by transactions fees for all transactions included in the block. Besides, Bitcoin assumes that a majority of computational power is controlled by honest players.
Smart contract is proposed by Ethereum [15] that is similar as Bitcoin. Smart contracts represent the implementation of a contractual agreement, whose legal provisions have been formalized into source code. Contracting parties can structure their relationships efficiently, in a selfexecuting method and without the ambiguity of words. Reliance on source code enables willing parties to simulate the agreement’s performance before execution and model contractual performance. Moreover, smart contracts introduce new relationships that are both automatically enforced and defined by code, but that are not linked to any underlying contractual rights or obligations. In the present paper, before hospital and servers work, they should mortgage coins in smart contracts, respectively. Besides, if someone does not work honestly, then anyone can input the corresponding evidences to obtain a part of the “wrongdoer”’s guarantee deposit.
In the paper, the security of Shamir’s (t, n)secret sharing (SSS) [21] is the security base of our system. We extend SSS to obtain a threshold secure multiparties computing protocol that will be described in the A. Besides, we use elliptic curve [22, 23] point multiplication to generate commitments of core data. Then we utilize bilinear map (pairing computations) [25] to verify the correctness of the committed core data.
Figures presented in the paper are created by using Visio.
System setting and model
Blockchain network and cryptographic keys
MIStore is comprised of recordnodes and lightnodes. Specifically, all recordnodes are connected by a reliable peertopeer network, and each lightnode connects with a certain number of recordnodes. Recordnodes are responsible to maintain the blockchain via Practical Byzantine Faulttolerance (PBFT) consensus and store the entire blockchain list. Specifically, time is divided in to epoches. In an epoch, recordnodes collect and verify transactions sent to the blockchain network, and they record valid transactions in their local blocks. By performing PBFT, some recordnode’s block become the valid block of the epoch. After that, all recordnodes join in the next epoch to build the next block. While, lightnodes do not store the entire blockchain, and they store all blockheaders.
Moreover, in the system, there is no trusted public key infrastructure. It means that any node can generate a arbitrary number of keypairs by itself. In a blockchain system, all users communicate with each other via transactions of blockchain, and they only trust messages presented at blockchain. Additionally, each recordnode can poll a random oracle [24] as a random bit source. Besides, by mortgaging a certain amount of coins with an address, a lightnode can become a hospital or insurance company with the address.
A node is honest if it follows all protocol instructions and is perfectly capable of sending and receiving information. Furthermore, a node is malicious if it can deviate arbitrarily from protocol instructions. Finally, in a blockchain system, all users communicate with each other via transactions of blockchain, and they only trust messages presented at blockchain.
In the implementation of MIStore, we utilize ECDSA [27] to be the signature schceme Sig(⋅), ECIES [28] to be the encryption scheme Enc(⋅) and SHA256 [1] to be the hash function H(⋅).
Assumptions
According to Practical Byzantine Faulttolerance [11] consensus scheme, we assume that \(\frac {2}{3}\) of recordnodes are honest in the system. Therefore, the blockchain of the system does not fork. In other words, once a transaction has appeared in the blockchain, then the transaction cannot be modified or deleted by anyone. Moreover, we assume that digital signature Sig(⋅), encryption scheme Enc(⋅) and hash function H(⋅) used in MIStore are ideal such that no one can violate Sig(⋅), Enc(⋅) and H(⋅). Finally, we assume that hospital and servers are partially trusted. Therefore, data sent by them should be verified.
The basic instance
In the paper, we mainly introduce the basic instance that contains a patient, a hospital and insurance company. For the patient, a more complex instance can be combined by the basic instance. Moreover, we assume that medical payments recorded in the blockchain belong to the range of the corresponding medical insurance.
An overview of MIStore
In this paper, we propose a blockchainbased medical insurance storage system, called MIStore. The system may help an insurance company to obtain the sum of patient’s medical medical spending records. Moreover, the medical spending data recorded at the blockchain are always confidential to servers as long as a certain number of servers are honest. In this system, there are four parties that are patients, hospitals, servers and insurance companies. All related data is recorded at the blockchain. Due to the property of tamperresistance of blockchain, all users may trust data recorded at the blockchain.
To introduce MIStore’s working process, we take the basic instance as a example, which contains a hospital H, a patient P, an insurance company I and n servers Sr_{1}, Sr_{2}, ⋯ Sr_{n}. Specifically, H performs a (t, n)threshold MIStore protocol among the n servers by sending an initializetransaction to the blockchain network. After that, H may send P’s confidential medical spending data to the blockchain network by sending recordtransactions. At some later time, if I wants to know the sum of some P’s spending records, then I may send a querytransaction to the blockchain network. After that, active servers will generate and send responses to the blockchain network by sending respondtransactions. Finally, if I collects at least t correct responses, then he can recover the real result. However, it must be pointed that anyone (including I) cannot learn anything about the correct result with less than t responses. The protocol is secure as long as more than n − t servers are honest. An overview of MIStore is shown in Fig. 1.
In the MIStore, most data is verifiable. For instance, anyone can verify the validation of the initializetransaction sent by the hospital, a server may verify the correctness of his core share sent by the hospital, an insurance company can verify whether responses are correctly computed by corresponding servers, and a patient can verify whether his spending data is correctly processed by the corresponding hospital. Moreover, because MIStore is decentralized, so there is no centralized node to punish the “bumblers”. To punish the bumblers’ mistake, we adopt the smart contract. Specifically, before hospitals and servers perform a MIStore protocol, they should a certain amount of mortgage coins in smart contracts, respectively. If someone of them publishes some invalid data in the blockchain, then anyone can input the evidences in the corresponding smart contract to obtain a part of the bumbler’s guarantee deposit.
MIStore
In this section, we introduce how MIStore works. We will describe transaction and block used in the system at first.
Transaction and block
In MIServer, a transaction contains two parts that are transaction header and payload. Transaction header and payload are shown in Table 1.
Moreover, the payload might contain secret or public data that may be used in verifications or computations. In the system, according to payload, transactions can be divided into four types. They are initializetransaction, recordtransaction, querytransaction and respondtransaction, and they can be described by T_{initialize}, T_{record}, T_{query} and T_{respond} as follows:
In MIStore, time is also divided into epoches. In each epoch, recordnodes will generate a block belong to the epoch via selected consensus scheme, and a block can be described as follow (Table 2):
Besides, recordnodes are responsible to verify all publicly verifiable data of transactions before the transactions are included in the blockchain. If any publicly verifiable data is invalid, then honest recordnodes will reject corresponding transactions. The transaction then will not be included in the blockchain. Moreover, due to adopting the Practical Byzantine Faulttolerance consensus scheme, if a transaction has presented at the blockchain, then all nodes can consider that the transaction’s publicly verifiable data is credible. Therefore, other nodes can trust the transaction’s publicly verifiable data without any other verifications.
Futhermore, in the MIStore system, recordnodes may perform two kinds of verifications on transactions. The first one is the basic verification, which should be performed on all transactions. They are:

The transaction’s inputs have not been used previously.

The transaction’s signature is valid.

The sum of input coins is equal to the sum of output coins.
The second one is the payload verification, which can be performed on initializetransactions and respondtransactions. It means that, in the payloads of initializetransaction and respondtransaction, there is publicly verifiable data that may be verified by recordnodes. If a transaction has presented at the blockchain, then it means that most of recordnodes have accepted the transaction’s publicly verifiable data. Therefore, the transaction’s receiver can consider that the transaction’s publicly verifiable data is credible. Thus the receiver just needs to perform some other verifications that can be performed only by him. In this way, the most of verification computations are performed by recordnodes and it helps to decreases servers’ and insurance company’s verification computations significantly. Figure 2 describes verifications of initializetransaction, recordtransaction, querytransaction and respondtransaction.
Construction of MIStore
To clearly introduce the MIStore system, in this subsection, we describe the basic instance that contains a hospital, a patient, an insurance company and n servers. Specifically, Sr_{1}, Sr_{2}, ⋯ , Sr_{n} denote n servers’ IDs, ID_{H} is the hospital’s ID, ID_{P} is the patient’s ID and ID_{I} describes the insurance company’s ID. Essentially, more complex instance can be constructed with the basic instance. The symbols used in the paper are shown in Table 3.
At first, the hospital and n servers should have published smart contracts to mortgage a certain amount of guarantee coins at the blockchain, respectively. If someone publishes some incorrect data that is verifiable, then the discoverer can send the corresponding evidences to the bumbler’s smart contract to prove that the bumbler sent an incorrect data. Then, the discoverer can automatically obtain a amount of reward from the bumbler’s smart contract.
After mortgaging guarantee coins, the MIStore system can be performed as follows:

Step 1: Initialization. Hospital randomly samples two polynomials F_{1}(x) and F_{2}(x) of degree t − 1 over \(\mathbb {F}_{p}\) as the following polynomials:
$$F_{1}(x)=a_{t1}x^{t1}+a_{t2}x^{t2}+{\cdots} +a_{1}x+s_{core,1}, $$$$F_{2}(x)=d_{t1}x^{t1}+d_{t2}x^{t2}+{\cdots} +d_{1}x+s_{core,2}, $$where \(s_{core,1},s_{core,2},a_{1},\cdots ,a_{t1},d_{1},\cdots ,d_{t1}\in \mathbb {F}_{p}\), a_{t− 1}≠ 0 and d_{t− 1}≠ 0. Let
$$f_{1}(x)=a_{t1}x^{t1}+a_{t2}x^{t2}+\cdots+a_{1}x, $$$$f_{2}(x)=d_{t1}x^{t1}+d_{t2}x^{t2}+\cdots+d_{1}x. $$Then, we have F_{1}(x) = f_{1}(x) + s_{core,1} and F_{2}(x) = f_{2}(x) + s_{core,2}. Hospital computes
$$f_{1}(x)f_{2}(x)=q_{2t2}x^{2t2}+q_{2t3}x^{2t3}+\cdots+q_{2}x^{2}. $$After that, hospital randomly samples l(x) of degree t − 1 from \(\mathbb {F}_{p}[x]\) as follow:
$$l(x)=c_{t1}x^{t1}+c_{t2}x^{t2}+{\cdots} +c_{1}x. $$Let
$$h(x)=f_{1}(x)f_{2}(x)l(x)=b_{2t2}x^{2t2}+b_{2t3}x^{2t3}+\cdots+b_{1}x. $$Then hospital generates a verification key VK as follow:
$$\begin{array}{@{}rcl@{}} \mathit{VK} &=& \{g,g^{a_{t1}},\cdots,g^{a_{1}},g^{s_{core,1}},g^{d_{t1}},\cdots,g^{d_{1}},g^{s_{core,2}},\\ && g^{b_{2t2}}, \cdots,g^{b_{1}},g^{c_{t1}},\cdots,g^{c_{1}}\}, \end{array} $$where g is a base point of 256bit BarretoNaehrig curve (BNcurve) [25]. For i from 1 to n, hospital does as follows:

Compute CF_{i,1} = F_{1}(Sr_{i}), CF_{i,2} = F_{2}(Sr_{i}) and Ch_{i} = h(Sr_{i}). {CF_{i,1}, CF_{i,2}, Ch_{i}} is Server_{i}’s coreshare.

Encrypts CF_{i,1}, CF_{i,2}, Ch_{i} with Server_{i}’s public key pk_{i} into \(C_{CF_{i,1}}=Enc_{pk_{i}}(CF_{i,1})\), \(C_{CF_{i,2}}=Enc_{pk_{i}}(CF_{i,2})\) and \(C_{Ch_{i}}=Enc_{pk_{i}}(Ch_{i})\) via ECIES. Only Server_{i} can decrypt them since only Server_{i} has the corresponding secret key sk_{i}.

Compute commitments \(CM_{CF_{i,1}}=g^{CF_{i,1}}\), \(CM_{CF_{i,2}}=g^{CF_{i,2}}\) and \(CM_{Ch_{i}}=g^{Ch_{i}}\). The commitments will be used in later verifications without obtaining CF_{i,1}, CF_{i,2} and Ch_{i}.
Then, the hospital generates a initializetransaction T_{initialize} as follows:
After that, the hospital sends the T_{initialize} to blockchain network.


Step 2: Recordnodes verify T_{initialize}. Honest recordnodes will verify all new initializetransactions before appending them at the blockchain. For instance, when an honest recordnode receives the T_{initialize}, he will verify its verification key (VK) at first, and then verify other data with the VK. If T_{initialize} passes the verifications, then the recordnode accepts the T_{initialize} and writes it in his local block, otherwise, he will reject the T_{initialize}. The verifications are described as follows:

First, verify the verification key VK. The recordnode verifies whether polynomials f_{1}(x), f_{2}(x), h(x) and l(x), committed in verification key, are wellformed. Specifically, the recordnode does as follows:

Randomly sample a number \(x_{0}\in \mathbb {F}_{p}\).

Compute
$$\begin{array}{@{}rcl@{}} g_{1}&=&(g^{a_{t1}})^{x_{0}^{t1}}(g^{a_{t2}})^{x_{0}^{t2}}{\cdots} (g^{a_{1}})^{x_{0}}\\ &=& g^{a_{t1}x_{0}^{t1}+a_{t2}x_{0}^{t2}+{\cdots} +a_{1}{x_{0}}}\\ g_{2}&=&(g^{d_{t1}})^{x_{0}^{t1}}(g^{d_{t2}})^{x_{0}^{t2}}{\cdots} (g^{d_{1}})^{x_{0}}\\ &=& g^{d_{t1}x_{0}^{t1}+d_{t2}x_{0}^{t2}+{\cdots} +d_{1}{x_{0}}}\\ g_{3}&=&(g^{b_{2t2}})^{x_{0}^{2t2}}(g^{b_{2t3}})^{x_{0}^{2t3}}{\cdots} (g^{b_{1}})^{x_{0}}\\ &=& g^{b_{2t2}x_{0}^{2t2}+b_{2t3}x_{0}^{2t3}+{\cdots} +b_{1}x_{0}}\\ g_{4}&=&(g^{c_{t1}})^{x_{0}^{t1}}(g^{c_{t2}})^{x_{0}^{t2}}{\cdots} (g^{c_{1}})^{x_{0}}\\ &=& g^{c_{t1}x_{0}^{t1}+c_{t2}x_{0}^{t2}+{\cdots} +c_{1}x_{0}} \end{array} $$ 
If
$$e(g_{1},g_{2})=e(g_{3}g_{4},g), $$then the recordnode accepts that f_{1}(x), f_{2}(x), h(x) and l(x) satisfy relationships and forms mentioned at Step 1. Otherwise he rejects the T_{initialize} and stops his verifications.


Second, verify commitments \(CM_{CF_{i,1}}\), \(CM_{CF_{i,2}}\), \(CM_{Ch_{i}}\), i from 1 to n. Specifically, the recordnode computes as follows:

Compute
$$\begin{array}{@{}rcl@{}} {CF}_{i,1}^{*} &=& (g^{a_{t1}})^{Sr_{i}^{t1}}{\cdots} (g^{a_{1}})^{Sr_{i}}(g^{s_{core,1}})\\ {CF}_{i,2}^{*} &=& (g^{d_{t1}})^{Sr_{i}^{t1}}{\cdots} (g^{d_{1}})^{Sr_{i}}(g^{s_{core,2}})\\ {Ch}_{i}^{*} &=& (g^{b_{2t2}})^{Sr_{i}^{2t2}}{\cdots} (g^{b_{1}})^{Sr_{i}} \end{array} $$ 
If
$$ {CF}_{i,1}^{*} = CM_{CF_{i,1}}, {CF}_{i,2}^{*} = CM_{CF_{i,2}} \text{ and } {Ch}_{i}^{*} = CM_{Ch_{i}}, $$(1)then the recordnode accepts that \(CM_{CF_{i,1}}\), \(CM_{CF_{i,2}}\) and \(CM_{Ch_{i}}\) are correctly computed by the hospital, otherwise he rejects the T_{initialize} and stop his verifications.

If any data cannot pass corresponding verification, then the recordnode rejects the T_{initialize}.

Remark 1
Because the recordnode randomly samples the number x_{0}, so the Eq. 1 is enough to prove the validation of the verification key.

Step 3: Servers verify coreshares. i from 1 to n, when the Server_{i} sees the T_{initialize} at the blockchain, the server may perform the following computations:

Decrypt \(C_{CF_{i,1}}\), \(C_{CF_{i,2}}\) and \(C_{Ch_{i}}\). Then he obtains CF_{i,1}, CF_{i,2} and Ch_{i}.

If
$$CM_{CF_{i,1}}=g^{CF_{i,1}},CM_{CF_{i,2}}=g^{CF_{i,2}}\textrm{ and }CM_{Ch_{i}}=g^{Ch_{i}}, $$then the server accepts that the T_{initialize} is valid, otherwise he can send his evidences \(\text {ID}_{T_{initialize}}\), CF_{i} and Ch_{i} to the hospital’s smart contract. After that, the server can obtain a amount of reward.


Step 4: Record. After seeing the T_{initialize} at the blockchain, the hospital may generate recordtransactions. Moreover, let da_{1}, da_{2}, ⋯, da_{m} denote the patient’s spending records. The each spending record has a unique invoice number, \({\text {ID}}_{invoice}^{i}\). However, they belong to the same initializetransaction T_{initialize}. Without loss of generality, we assume that the hospital generates two recordtransactions (T_{1} and T_{2}), and the patient’s spending records are da_{1}, da_{2}, da_{3}, da_{4}. Then, i from 1 to 4, hospital randomly divides da_{i} into da_{i} = dd_{i,1}dd_{i,2}. Then, the hospital computes
$$\mathsf{s}_{i,1} = \mathsf{dd}_{i,1}  \mathsf{s}_{core,1}, \mathsf{s}_{i,2}=\mathsf{dd}_{i,2}\mathsf{s}_{core,2}. $$Then, it generates transactions T_{1}, T_{2} as follows:
After that, the hospital sends T_{1}, T_{2} to blockchain network.

Step 4.5: Patient verifies spending records. The patient knows the true spending records da_{1}, da_{2}, da_{3}, da_{4}. After seeing the transactions T_{1} and T_{2} at the blockchain, he can verify the correctness of his spending data of T_{1} and T_{2}. Specifically, he verify whether the following equations are correct, i from 1 to 4.
$$e(g^{\mathsf{da}_{i}},g)=e(g^{s_{core,1}}g^{\mathsf{s}_{i,1}},g^{s_{core,2}}g^{\mathsf{s}_{i,2}}) $$If the above equation holds for each i from 1 to 4, then the patient considers that his spending data is correctly processed by the hospital. Otherwise, he will consider that the hospital is dishonest and send the evidences to the hospital’s smart contract to get a certain number of reward.

Step 5: Query. When the insurance company wants to get a sum of spending records related to the initializetransaction T_{initialize}, he may send a querytransaction T_{query} containing ID\(_{T_{\mathit {initialize}}}\) to the blockchain network. The T_{query} is described as follows:
When the querytransaction is appended at the blockchain, it means that insurance company wants to know the sum of all spending records of the patient corresponding to ID\(_{T_{initialize}}\) until now.
Remark 2
After the T_{query} is correctly responded by at least t servers, when the patient performs new payments with the hospital, the hospital should generates another new initializetransaction, including a new verification key, for the patient.

Step 6: Respond. After the T_{query} has presented at blockchain. If a server wishes to respond the query, then he will generate a response according to the T_{query}. After that, the server will secretly send his response to the insurance company via a respondtransaction T_{respond}. If insurance company collets at least t responses correctly computed by corresponding servers, then insurance company can recover the correct sum of spending records related to the ID_{initialize}. To introduce the process, without loss of generality, we assume that the t servers are Server_{1}, Server_{2}, ⋯ , Server_{t} and they wish to respond the T_{query}. According to T_{query}, the servers can obtain s_{1,1}, s_{1,2}, s_{2,1}, s_{2,2}, s_{3,1}, s_{3,2}, s_{4,1}, s_{4,2} which are recorded in T_{1} and T_{2}. First, i from 1 to t, the Server_{i} computes as follows:
$$\mathit{Resp}_{i} = \sum\limits_{j = 1}^{4} (CF_{i,1} + s_{j,1})(CF_{i,2}+s_{j,2})4\cdot Ch_{i}. $$Then Server_{i} encrypts Resp_{i} into
$$C_{\mathit{Resp}_{i}} = Enc_{pk_{I}}(\mathit{Resp}_{i}) $$with insurance company’s public key pk_{I}. Then Server_{i} computes a commitment of Resp_{i} as follow:
$$CM_{\mathit{Resp}_{i}} = g^{\mathit{Resp}_{i}}. $$After that, Server_{i} generates a respondtransaction \({T}_{\mathit {respond}}^{i}\), containing \(\text {ID}_{T_{initialize}}\), \(CM_{\mathit {Resp}_{i}}\) and \(C_{\mathit {Resp}_{i}}\). The T_{respond} can be described as follow:
Overall, servers Server_{1}, Server_{2}, ⋯, Server_{t} will generate \(C_{\mathit {Resp}_{1}}\), \(C_{\mathit {Resp}_{2}}\), ⋯, \(C_{\mathit {Resp}_{t}}\) and \(CM_{\mathit {Resp}_{1}}\), \(CM_{\mathit {Resp}_{2}}\), ⋯, \(CM_{\mathit {Resp}_{t}}\). Then, Server_{1}, Server_{2}, ⋯, Server_{t} generate transactions \({T}_{\mathit {respond}}^{1}\), \({T}_{\mathit {respond}}^{2}\), ⋯, \({T}_{\mathit {respond}}^{t}\), respectively. Because only the insurance company has the corresponding secret key sk_{I}, so only the insurance company can decrypt \(C_{\mathit {Resp}_{1}}\), \(C_{\mathit {Resp}_{2}}\), ⋯, \(C_{\mathit {Resp}_{t}}\). After that, the servers send \({T}_{\mathit {respond}}^{1}\), \({T}_{\mathit {respond}}^{2}\), ⋯, \({T}_{\mathit {respond}}^{t}\) to the blockchain network.

Step 7: Recordnodes verify \({T}_{\mathit {respond}}^{1}\), \({T}_{\mathit {respond}}^{2}\), ⋯, \({T}_{\mathit {respond}}^{t}\). After receiving the respondtransactions \({T}_{\mathit {respond}}^{1}\), \({T}_{\mathit {respond}}^{2}\), ⋯, \({T}_{\mathit {respond}}^{t}\), a recordnode may verify validations of their \(CM_{\mathit {Resp}_{1}}\), \(CM_{\mathit {Resp}_{2}}\) and \(CM_{\mathit {Resp}_{t}}\). Specifically, i from 1 to t, the recordnode performs as follows:

Compute
$$g^{CF_{i}} = (g^{a_{t1}})^{Sr_{i}^{t1}} {\cdots} (g^{a_{1}})^{Sr_{i}} (g^{a_{0}}) = g^{a_{t1}Sr_{i}^{t1}+\cdots+a_{1}Sr_{i}+s_{core}} $$$$g^{Ch_{i}}=(g^{b_{2t2}})^{Sr_{i}^{2t2}}{\cdots} (g^{b_{1}})^{Sr_{i}}=g^{b_{2t2}Sr_{i}^{2t2}+\cdots+b_{1}Sr_{i}} $$ 
With s_{1,1}, s_{1,2}, s_{2,1}, s_{2,2}, s_{3,1}, s_{3,2}, s_{4,1}, s_{4,2} and the bilinear map e, the recordnode further computes
$$\begin{array}{@{}rcl@{}} E_{i} &=& e(g^{CF_{i,1}}g^{\mathsf{s}_{1,1}},g^{CF_{i,2}}g^{\mathsf{s}_{1,2}})\\ && \times e(g^{CF_{i,1}}g^{\mathsf{s}_{2,1}},g^{CF_{i,2}}g^{\mathsf{s}_{2,2}})\\ && e(g^{CF_{i,1}}g^{\mathsf{s}_{3,1}},g^{CF_{i,2}}g^{\mathsf{s}_{3,2}})\\ && \times e(g^{CF_{i,1}}g^{\mathsf{s}_{4,1}},g^{CF_{i,2}}g^{\mathsf{s}_{4,2}}) \end{array} $$ 
If
$$E_{i}/e(g^{Ch_{i}},g^{4})=e(CM_{\mathit{Resp}_{i}},g), $$then the recordnode considers that \(CM_{\mathit {Resp}_{i}}\) is valid.


Step 8: Recover. Because the \({T}_{\mathit {respond}}^{1}\), \({T}_{\mathit {respond}}^{2}\), ⋯, \({T}_{\mathit {respond}}^{t}\) present at the blockchain, it means that the transactions pass all previous all verifications. Therefore, the insurance company just needs to perform the final verification that can by performed only by him. That is, i from 1 to t, the insurance company decrypts \(C_{\mathit {Resp}_{i}}\) and then obtain Resp_{i}. If
$$CM_{\mathit{Resp}_{i}}=g^{\mathit{Resp}_{i}}, $$then insurance company accepts that the Resp_{i} is correctly computed by Server_{i}. Otherwise he rejects the response and can send his evidences ID\(_{T_{\mathit {respond}}}\) and Resp_{i} to the Server_{i}’s smart contract, and then insurance company can obtain a amount of reward. If all the t responses pass the verifications, then the insurance company uses lagrange interpolation to reconstruct a polynomial as follow:
$$\tilde{F}(x) = \sum\limits_{i = 1}^{t} \mathit{Resp}_{i} \prod\limits_{j = 1,j\neq i}^{t} \frac{xSr_{j}}{Sr_{i}Sr_{j}}. $$Finally, the insurance company calculates \(\tilde {F}(0)\) that is the desired result.
Performance evaluation
In this section, we evaluate a performance of the MIStore system. The performance evaluation can be broken into three parts. The first part studies the processing time of cryptographic and mathematic computations in this system. The time of processing transactions is researched in the second part. The last part further demonstrates the processing time of blocks when different transactions are sent to the blockchain network. The section starts with the prototype system setting.
Prototype system setting
MIStore’s efficiency mainly depends on the blockchain platform and performance of cryptographic schemes. For instance, in the paper, we use the Ethererum blockchain as the blockchain platform. Specifically, Ethereum’s block can contains transactions of at most 62,360 bytes, its average block interval is about 15 s and its transaction’s payload contains at most 1014byte data, so the MIStore’s efficiency is significantly limited by the Ethererum blockchain. Therefore, if we use some other more suitable blockchain, then we might get a better throughput. Besides, we use our BNcurve code to perform the pairing and point multiplication. Therefore, time cost of pairing and point multiplication may be longer than the previous optimal works. For instance, in Pinocchio [34], due to their excellent code, a pairing computation just takes 0.9 ms, while ours takes about 84.651 ms. Therefore, if we use their computer platform and code, maybe the performance of the prototype system could be improved.
We implement a prototype system that is a (2,3)threshold MIStore protocol among three servers. Specifically, it contains a hospital, a patient, an insurance company and three servers. We use laptops and virtual machines to perform the prototype system. Our laptop’s configuration is described as follows: the Intel i55300 CPU with 2.30GHz, 4GB memory, Windows 10 OS. In the local area network, we deploy a local blockchain via goethereum that is a Go implementation of the Ethereum protocol (https://github.com/ethereum/goethereum). In the blockchain network, we deploy four recordnodes (miners), and we use transaction simulator (https://github.com/ethereum/goethereum) to simulate the hospital, servers and insurance company to generate and send transactions. Moreover, we record MIStore system’s data in the transaction’s payload. In the Ethereum blockchain, a transaction’s payload can record data of at most 1014 bytes.
Additionally, Ethererum has a embedded signature scheme that is the ECDSA with the secp256k1 elliptic curve [26]. For convenience, we use the scheme to sign messages. Besides, to encrypt key data recorded in the payloads of initializetransaction and respondtransaction, we use the encryption scheme ECIES with the elliptic curve secp256k1 to encrypt the key data via receiver’s public key. It results in that each encrypted message has a length of 96 bytes. Moreover, the encrypted data can be decrypted only by the corresponding receivers since only he has the corresponding private key.
Furthermore, for committing data and verifying committed data, we utilize 256bit BarretoNaehrig curve (BNcurve) [25] to commit the data via the base point multiplication. For instance, let G be the base point of the BNcurve. Then, the secret s can be committed by sG. Therefore, a commitment has a length of 64 bytes since any point of the BNcurve has two coordinates and each of the coordinates is of 32 bytes. Moreover, we use the bilinear map e (pairing computation) constructed by the BNcurve to verify the correctness of the commitments. Specifically, e(g^{a}, g^{b}) = e(g^{ab}, g). For instance, if we want to verify ab = c and we do not want to reveal a, b and c, then we may use the following equation to verify ab = c.
Processing time of cryptographic schemes
Generally, the time cost of performing cryptographic schemes will have a certain degree of influence on the time of processing transactions, and then it may influence the efficiency of the system. Therefore, in the subsection, we discuss the processing time cost of cryptographic and mathematic components.
For each of encryption, decryption, point multiplication, point addition, signing, verifying signatures, pairing, field addition and field multiplication, we perform 1000 experiments to obtain their average time cost. Their average time cost is shown in Table 4.
Generating transactions
In MIStore system, different transactions may have different payloads. For instance, an initializetransaction includes a verification key, 9 commitments, 3 servers’ IDs and 9 encrypted messages, while a respondtransaction only contains a initializetransaction’s ID, an encrypted response and a commitment about the response. Moreover, the sizes of payloads of initializetransaction, querytransaction and respondtransaction are fixed, while the size of payload of recordtransaction is variable. Therefore, different transactions may have different generation time. In the subsection, we study generation time of transactions in the implementation. We discuss the initializetransaction at first.
In our prototype system, according to “??”, a T_{initialize}’s payload includes a verification key, three servers’ IDs, 9 encrypted messages and 9 commitments. Moreover, according to “??”, the data recorded in the T_{initialize}’s payload is of 1504 bytes. However, the payload of a transaction, in the Ethererum blockchain, can include at most 1014 bytes. In other words, one transaction cannot contain 1504 bytes. Therefore, in the prototype system, we divide the T_{initialize} into \({T}_{\mathit {initialize}}^{1}\), \({T}_{\mathit {initialize}}^{2}\) and \({T}_{\mathit {initialize}}^{3}\) in order to record all its data. Specifically, the both transactions can be described as follows:
Indeed, recordtransactions may have payloads with variable sizes. Moreover, a basic message recorded in a recordtransaction’s payload is a array of {ID_{initialize}, ID_{invoice}, s_{k,1}, s_{k,2}} which is of 128 bytes. Due to that the a payload can include at most 1014 bytes, a recordtransaction’s payload can contain at most 7 × 128 = 896 bytes. For convenience, in the prototype system, we only generate recordtransactions with the largest payload. Specifically, we only generate two kinds of recordtransactions which are described as follows:
A querytransaction, whose payload just includes a initializetransaction’s ID, can be shown as follows:
A respondtransaction’s payload contains the corresponding initializetransaction’s ID, an encrypted response and a commitment of the response. Specifically, Server_{i}’s respondtransaction can be described as follow:
In the prototype system, sizes of transactions’ payloads are shown in Table 5. For each of \({T}_{\mathit {initialize}}^{1}\), \({T}_{\mathit {initialize}}^{2}\), \({T}_{\mathit {initialize}}^{3}\), T_{record}, T_{query} and T_{respond}, we generate 1000 transactions in order to obtain their average generating time cost. Then their average time cost are shown in Table 6.
Verifying transactions
In the system, before a transaction is appended at the blockchain, most recordnodes must verify the transaction. Specifically, recordnodes verify all publicly verifiable data of the transaction. Moreover, if a transaction has appeared at the blockchain, then it means that it has been accepted by most recordnodes. Therefore, the transaction’s publicly verifiable data is credible. Consequently, others (e.g., hospital, patient, insurance company and servers ) do not have to verify the transaction’s publicly verifiable data. In this way, it significantly reduces verifying computations of users. In the subsection, we study transactions’ verification time cost. All publicly verifiable data of transactions are summarized as follows:

All transactions’ signatures are publicly verifiable data that can be verified by recordnodes. Therefore, if a transaction has appeared at the blockchain, then the transaction’s signature is credible, and others need not to verify the signature.

Except signatures, the payloads of initializetransaction and respondtransaction have public verifiable data that can be verified by recordnodes. Specifically, they are the initializetransaction’s verification key, commitments of coreshares and commitments of responses. Consequently, if an initializetransaction (or a querytransaction) has appeared at the blockchain, then its publicly verifiable data is credible. Therefore, the transaction’s receiver need not to verify the public verifiable data.
In this way, the transaction’s receiver just needs to verify some key data that can be verified by only him.
For each of \({T}_{\mathit {initialize}}^{1}\), \({T}_{\mathit {initialize}}^{2}\), \({T}_{\mathit {initialize}}^{3}\), T_{record}, T_{query} and T_{respond}, we verify 1000 transactions, and then obtain their average verifying time cost. Then their average verifying time cost are shown in Table 6. Specifically, in Table 6, S is a signing computation, V denotes a signature verification, PM describes a point multiplication on the ECC, PA is a point addition on the ECC, Pairing means a pairing computation, E is a encryption, D denotes a decryption, FM describes a field multiplication and FA is a field addition. For instance, “2PM + 3PA + 1V + 6Pairing” denotes that the corresponding computations contain 2 point multiplications, 3 point additions, 1 signature verification and 6 pairing computations.
It must be pointed that if the system does not use blockchain to record transactions and does not use recordnodes to help users to verify publicly verifiable data, then transaction receivers should perform more verifying computations than the blockchainbased system. Specifically, if that happens and we also use the above transactions and cryptographic schemes, then this will result in:

Because all transactions are stored by some centralized nodes, so storages might be modified or deleted by the centralized nodes.

All related users must independently verify all public verifiable data including the verification key and commitments.

Servers and insurance company might be heavier than the blockchainbased system. Therefore, some computations and operations cannot be processed efficiently, even cannot be performed.
For instance, we assume that a nonblockchainbased MIStore (pure system) is performed. If an insurance company receives a respondtransaction, then it must verify all verifiable data, otherwise it will not trust the transaction. Specifically, he will costs about 528.297 ms to verify it. However, if the system is based on a blockchain network, that is the key point of the paper, then the insurance company just needs to cost 33.936 ms to verify some key data since other data has been verified by recordnodes. Comparisons between the pure system and the blockchainbased system are shown in Table 7. According to the Table 7, if the system is not based on the blockchain, then the insurance company and servers all need a certain amount of verifying computations. However, if the system is based on the blockchain, then most computations can be done by recordnodes, then the insurance company and servers just need to perform very few verifying computations.
Blockchain performance evaluation
We run our MIStore on the Ethereum blockchain. After generating a certain number of blocks, the block interval tends to be stable. That is, generating 1000 blocks takes about 4.3 h. In other words, generating a block takes about 15.2 s on average. Furthermore, in the Ethereum blockchain, a block can record transactions of at most 62,360 bytes, a transaction with an empty payload is of 308 bytes and a transaction’s payload can record data of at most 1014 bytes. Therefore, a transaction’s size should be from 308 bytes to 308 + 1014 = 1322 bytes.
According to Table 5 and above contents, in our implementation, any transaction’s size can be calculated. Transactions’ sizes are shown in Table 8. A block can record transactions of at most 62360 bytes. Therefore, if a block only record identical transactions, then the number of recorded transactions has a limit.
In our experiments, because different transactions have different significance, so the more significant transaction should be processed earlier. In the Ethererum blockchain, recordnodes (miners) earlier process a transaction with more transaction fee. Therefore, we set different transactions with different transaction fees. When transactions are pending in a recordnode’s transaction pool, transactions with more fees will be recorded earlier. In the MIStore system, the initializetransaction is the base of later transactions. Therefore, it should has the first priority. For quickly responding insurance company’s query, we set that querytransaction has the second priority and respondtransaction has the third priority. Finally, recordtransaction has the lowest priority. In this way, the system’s responding rate will be obviously increased. In our experiments, their transaction fees are shown in Table 9.
In our experiments, after an initializetransaction has appeared at the blockchain, the hospital continually send recordtransactions to the blockchain network. The recordtransactions are same as mentioned at “??”. The data of recordtransactions’ payloads is called as “spendingdata”. Every block can contain at most 51 recordtransactions with the most arrays of spending data. Then, a block can store spendingdata of at most 45696 bytes. Because the blockchain generates a block per about 15 s on average, so the system can record spendingdata of at most 3046.4 bytes per second on average. At some later time, the insurance company sends a querytransaction to the blockchain network. Consequently, in the next block, the insurance company can get 3 responsetransactions. The respondtransactions are recorded by recordnodes earlier than recordtransactions since it has larger transaction fee. Finally, the insurance company can recover his desired data. The whole process only takes about 24 s.
MIStore’s efficiency mainly depends on the blockchain platform. For instance, in the paper, we use the Ethererum blockchain as the platform. Specifically, Ethereum’s block can contains transactions of at most 62,360 bytes, its average block interval is about 15 s and its transaction’s payload contains at most 1014byte data, so the MIStore’s efficiency is significantly limited by the blockchain platform. Therefore, if we use some other more suitable blockchain platform, then it might get a better throughput.
Conclusion
In this paper, we propose a blockchainbased threshold medical insurance storage system, called MIStore. Because of combining with blockchain, the system obtains some special advantages, e.g., decentralization, tamperresistance and recordnodes help users to verify publicly verifiable data. Firstly, the blockchain’s property of tamperresistance gives users highcredibility. Moreover, due to the decentralization, users can communicate with each other without the thirdparties. Secondly, the system supports the property of threshold. That is, patient’s data is confidentially controlled by servers specified by the hospital, and the stored data is always confidential for the servers as long as a certain number of the servers are honest. Furthermore, according to the insurance company’s query, the specified servers can perform homomorphic computations on the data and then get responses. If the insurance company can collect a threshold number of correct responses, then he can recover the correct patient’s spending data. Thirdly, all important data is verifiable. In particular, most of data is publicly verifiable. Therefore, recordnodes of blockchain can help users to perform the public verifications. Consequently, this significantly reduces users computations. Finally, a performance evaluation about the system is given.
References
Nakamoto, S.: Bitcoin: A peertopeer electronic cash system, Available: http://bitcoin.org/bitcoin.pdf, 2008
Litecoin. https://litecoin.org
Schwartz, D., Youngs, N., and Britto, A.: The Ripple Protocol Consensus Algorithm. Technical Report. https://ripple.com/files/ripple_consensus_whitepaper.pdf, 2014
Wood, G., Ethereum: A secure decentralised generalised transaction ledger[J]. Ethereum project yellow paper 151:1–32, 2014.
Dwork, C., and Naor, M.: Pricing via processing or combatting junk mail[C]. In: Annual International Cryptology Conference, pp. 139–147. Springer, Berlin, 1992.
King, S., and Nadal, S.: Ppcoin: Peertopeer cryptocurrency with proofofstake[J]. Selfpublished paper, August, 2012, 19
Kwon, J.: Tendermint: Consensus without mining. 2014[J]. https://tendermint.com/static/docs/tendermint.pdf, 2014
Dziembowski, S., Faust, S., Kolmogorov, V., et al.: Proofs of space[C]. In: Annual Cryptology Conference, pp. 585–605. Springer, Berlin, Heidelberg, 2015.
Bentov, I., Lee, C., Mizrahi, A., and Rosenfeld, M.: Proof of activity Extending bitcoin’s proof of work via proof of stake. In: Proceedings of the ACM SIGMETRICS 2014 Workshop on Economics of Networked Systems, NetEcon. 2, 2014.
Blocki, J., and Zhou, H. S.: Designing proof of humanwork puzzles for cryptocurrency and beyond[C]. In: Theory of Cryptography Conference, pp. 517–546. Springer, Berlin, 2016.
Castro, M., and Liskov, B., Practical Byzantine fault tolerance[C]. OSDI 99:173–186, 1999.
King, S., and Nadal, S.: Ppcoin: Peertopeer cryptocurrency with proofofstake. https://peercoin.net/assets/paper/peercoinpaper.pdf, 2012
CryptoManiac: Proof of stake. NovaCoin wiki. https://github.com/novacoinproject/novacoin/wiki/Proofofstake, 2014
Bentov, I., Lee, C., Mizrahi, A., and Rosenfeld, M., Proof of activity Extending bitcoin’s proof of work via proof of stake [extended abstract]. SIGMETRICS Perform. Eval. Rev. 42(3):34–37, 2014.
Buterin, V.: A nextgeneration smart contract and decentralized application platform, 2014[J] https://github.com/ethereum/wiki/wiki/WhitePaper (visited on 10/09/2016), 2014
Dwork, C., and Naor, M.: Pricing via processing or combatting junk mail. In: CRYPTO’92, pp. 139–147, 1992.
Abramaowicz, M., Cryptocurrencybased Law[J]. Ariz. L. Rev. 58:359, 2016.
Yue, X., Wang, H., Jin, D., Li, M., and Jiang, W., Healthcare data gateways: Found healthcare intelligence on blockchain with novel privacy risk control. J. Med. Syst. 40(10):218, 2016.
Ferrer, E. C.: The blockchain: A new framework for robotic swarm systems. arXiv:1608.00695, 2016
Brambilla, G., Amoretti, M., and Zanichelli, F.: Using block chain for peertopeer proofoflocation. arXiv:1607.00174, 2016
Shamir, A., How to share a secret. ACM 22:612,613, 1979.
Joux, A., A one round protocol for tripartite DieHellman. J. Cryptol. 17:263–276, 2004.
Joux, A., and Nguyen, K., Separating decision DieHellman from computational DieHellman in cryptographic groups. J. Cryptol. 16:239–247, 2003.
Bellare, M., and Rogaway, P.: Random oracles are practical: A paradigm for designing efficient protocols[C]. In: Proceedings of the 1st ACM Conference on Computer and Communications Security, pp. 62–73. ACM, 1993.
Barreto, P. S. L. M., and Naehrig, M.: Pairingfriendly elliptic curves of prime order. In: Selected Areas in Cryptography (SAC), 2006.
Bernstein, D. J., and Lange, T.: Safecurves: Choosing safe curves for ellipticcurve cryptography. http://safecurves.cr.yo.to, 2013
Johnson, D., Menezes, A., and Vanstone, S., The elliptic curve digital signature algorithm (ECDSA)[J]. Int. J. Inf. Secur. 1(1):36–63, 2001.
Smart, N. P.: The exact security of ECIES in the generic group model[C]. In: IMA International Conference on Cryptography and Coding, pp. 73–84. Springer, Berlin, 2001.
Ekblaw, A., Azaria, A., Halamka, J. D., et al.: A Case Study for Blockchain in Healthcare: “MedRec” prototype for electronic health records and medical research data[C]. In: Proceedings of IEEE Open and Big Data Conference, Vol. 13, p. 13, 2016.
Xia, Q., Sifah, E. B., Asamoah, K. O., et al., MeDShare: Trustless medical data sharing among cloud service providers via blockchain[J]. IEEE Access 5:14757–14767, 2017.
Liu, X., Dong, M., Ota, K., Hung, P., and Liu, A., Service pricing decision in cyberphysical systems: insights from game theory. IEEE Trans. Serv. Comput. 9(2):186–198, 2016.
Chang, S., Zhu, H., Dong, M., Ota, K., Liu, X., and Shen, X., Private and flexible urban message delivery. IEEE Trans. Veh. Technol. 65(7):4900–4910, 2016.
Yan, J., Wang, L., Dong, M., Yang, Y., and Yao, W., Identitybased signcryption from lattices. Security and Communication Networks 8(18):3751–3770, 2015.
Parno, B., Howell, J., Gentry, C., et al.: Pinocchio: Nearly practical verifiable computation[C]. In: 2013 IEEE Symposium on Security and Privacy (SP), pp. 238–252. IEEE, 2013.
Acknowledgments
This work was supported by the National Key R&D Program of China (Grant No. 2016YFB0800602), the National Natural Science Foundation of China (NSFC) (Grant No. 61502048), and Shandong provincial Key R&D Program of China (Grant No. 2018CXGC0701).
Author information
Authors and Affiliations
Corresponding author
Ethics declarations
This article does not contain any studies with human participants performed by any of the authors.
Conflict of interests
Lijing Zhou declares that he has no conflict of interest. Licheng Wang declares that he has no conflict of interest. Yiru Sun declares that she has no conflict of interest.
Additional information
This article is part of the Topical Collection on Blockchainbased Medical Data Management System: Security and Privacy Challenges and Opportunities
Appendix: (t, n)threshold verifiable homomorphic confidential storage scheme
Appendix: (t, n)threshold verifiable homomorphic confidential storage scheme
(t, n)threshold verifiable homomorphic confidential storage scheme (TVHCSS) contains three parties (a distributor, n servers and a querier). Specifically, in TVHCSS, the distributor’s messages are protected and controlled by the n servers, and in each server’s hands, messages are ciphertext. When a querier sends a query to the n servers, if at least t servers return correct answers to the querier, then the querier can obtain what he wants. While if less than t servers return answers to the querier, then the querier cannot obtain anything.
A.1 Construction of TVHCSS
Symbols, used in the scheme, are summarized at Table 10.

g is a generator of a cyclic group 𝔾.

e is a bilinear map, e: 𝔾 × 𝔾 → 𝔾. For instance, e(g^{a}, g^{b}) = e(g, g)^{ab}.

D is the distributor’s ID.

Sr_{1}, Sr_{2}, ⋯ , Sr_{n} denote n servers’ IDs.

Q describes the querier’s ID.

{pk_{i}, sk_{i}} denotes the ith server’s key pair, for i from 1 to n.

{pk_{Q}, sk_{Q}} is Q’s key pair.

d_{1},d_{2}, ⋯ ,d_{m} describe the plaintext messages that will be protected by n servers in ciphertext.

\(Sahre^{asr}_{i}\) is the ithe server’s answer.
The TVHCSS can be described as follows:

Initialize. Let \(\mathbb {F}_{p}\) be a finite field with character p. D randomly samples a polynomial F(x) of degree t − 1 over \(\mathbb {F}_{p}\) as the following polynomial.
$$F(x)=a_{t1}x^{t1}+a_{t2}x^{t2}+{\cdots} +a_{1}x+s_{core}, $$where \(s_{core},a_{1},\cdots ,a_{t1}\in \mathbb {F}_{p}\) and a_{t− 1} ≠ 0. We denote that s_{core} is the core secret in the system. Let
$$f(x)=a_{t1}x^{t1}+a_{t2}x^{t2}+\cdots+a_{1}x. $$Then we have F(x) = f(x) + a_{0}. D computes
$$f(x)^{2}=q_{2t2}x^{2t2}+q_{2t3}x^{2t3}+\cdots+q_{2}x^{2}. $$After that, D randomly samples l(x) of degree t − 1 from \(\mathbb {F}_{p}[x]\) as follow:
$$l(x)=c_{t1}x^{t1}+c_{t2}x^{t2}+{\cdots} +c_{1}x. $$Let
$$h(x)=f(x)^{2}l(x)=b_{2t2}x^{2t2}+b_{2t3}x^{2t3}+\cdots+b_{1}x. $$D samples a generator g that can generate a cyclic group \(\mathbb {G}\). Then D publishes a verification key VK as follow:
$$\begin{array}{@{}rcl@{}} VK &=& \{g,g^{a_{t1}},\cdots,g^{a_{1}},g^{s_{core}},g^{b_{2t2}},g^{b_{2t3}},\\ && \cdots,g^{b_{1}},g^{c_{t1}},g^{c_{t2}},\cdots,g^{c_{1}}\} \end{array} $$ 
Verify committed polynomials. Anyone can verify whether polynomials f(x), h(x), l(x), committed in verification key, are wellformed and sound. Specifically, he can do as follows:

Randomly sample t different numbers \(x_{0},x_{1},\cdots ,x_{t1}\in \mathbb {F}_{p}\).

j from 0 to t − 1, compute
$$\begin{array}{@{}rcl@{}} {g_{j}^{f}} &=& (g^{a_{t1}})^{x_{j}^{t1}}(g^{a_{t2}})^{x_{j}^{t2}}{\cdots} (g^{a_{1}})^{x_{j}}\\ &=& g^{a_{t1}x_{j}^{t1}+a_{t2}x_{j}^{t2}+{\cdots} +a_{t1}{x_{j}}} \end{array} $$$$\begin{array}{@{}rcl@{}} {g_{j}^{h}} &=& (g^{b_{2t2}})^{x_{j}^{2t2}}(g^{b_{2t3}})^{x_{j}^{2t3}}{\cdots} (g^{b_{1}})^{x_{j}}\\ &=& g^{b_{2t2}x_{j}^{2t2}+b_{2t3}x_{j}^{2t3}+{\cdots} +b_{1}x_{j}} \end{array} $$$$\begin{array}{@{}rcl@{}} {g_{j}^{l}} &=& (g^{c_{t1}})^{x_{j}^{t1}}(g^{c_{t2}})^{x_{j}^{t2}}{\cdots} (g^{c_{1}})^{x_{j}}\\ &=& g^{c_{t1}x_{j}^{t1}+c_{t2}x_{j}^{t2}+{\cdots} +c_{1}x_{j}} \end{array} $$ 
If \(e({g_{j}^{f}},{g_{j}^{f}})=e({g_{j}^{h}}{g_{j}^{l}},g)\), for all j from 0 to t − 1, then the verifier accepts that the polynomials, committed by verification key, are wellformed and sound. Otherwise, he rejects and return to step Inilialize.


Distribute. D computes
$$F_{i}=F(Sr_{i})\ and\ h_{i}=h(Sr_{i}). $$D encrypts {F_{i}, h_{i}} with Sr_{i}’s public key as \(C_{i}=Enc_{pk_{i}}(CF_{i},Ch_{i})\). D sends C_{i} to Sr_{i}, respectively. For C_{i}, only Sr_{i} can decrypt it since only S_{i} has the corresponding secret key. After obtaining F_{i} and h_{i}, Sr_{i} can verify the soundness of {F_{i}, h_{i}} with verification key
$$\begin{array}{@{}rcl@{}} &&\{g,g^{a_{t1}},\cdots,g^{a_{1}},g^{s_{core}},g^{b_{2t2}},g^{b_{2t3}},\cdots,\\&&g^{b_{1}},g^{c_{t1}},g^{c_{t2}},\cdots,g^{c_{1}}\}. \end{array} $$Specifically, he computes
$${F}_{i}^{*}=(g^{a_{t1}})^{Sr_{i}^{t1}}{\cdots} (g^{a_{1}})^{Sr_{i}}(g^{s_{core}}) $$$${h}_{i}^{*}=(g^{b_{2t2}})^{Sr_{i}^{2t2}}{\cdots} (g^{b_{1}})^{Sr_{i}} $$If \({F}_{i}^{*}=g^{F_{i}}\) and \({h}_{i}^{*}=g^{h_{i}}\), then Sr_{i} accepts F_{i} and h_{i}, otherwise he rejects.

Publish. D computes
$$s_{i}=d_{i}s_{core} $$for 1 ≤ i ≤ m. Then D publishes s_{1}, s_{2}, ⋯ , s_{m} that can be seen by anyone including the servers. However, only the servers can use s_{1}, s_{2}, ⋯ , s_{m} to generate answer shares that can be used by the querier to recover the corresponding needed result.

Query. The Querier Q sends servers a query that he wants to know a data that can be described as the following equation:
$$ \mathit{data}{\kern.5pt}={\kern.5pt}d_{i_{1}}d_{i_{2}}{\kern.5pt}+d_{i_{3}}d_{i_{4}}{\kern.5pt}+\cdots+d_{i_{k_{1}1}}d_{i_{k_{1}}}{\kern.5pt}+d_{i_{k_{1}+ 1}}{\kern.5pt}+\cdots++d_{i_{k_{1}+k_{2}}}{\kern.5pt}, $$(2)where \(1\leq i_{1},i_{2},\cdots ,i_{k_{1}+k_{2}}\leq m\).

Answer. If the ith server Sr_{i} wishes to answer Q, then he will generate a Share_{i} by calculating with s_{1}, s_{2}, ⋯ , s_{m}, F_{i} and h_{i} as follows:
$$\begin{array}{@{}rcl@{}} \mathit{Share}_{i} \!&=&\! (F_{i}+s_{i_{1}})(F_{i}+s_{i_{2}})+\cdots+(F_{i}+s_{i_{k_{1}1}})(F_{i}+s_{i_{k_{1}}})\\ &&+\, (F_{i}+s_{i_{k_{1}+ 1}})+\cdots+(F_{i}+s_{i_{k_{1}+k_{2}}})\frac{k}{2}h_{i} \end{array} $$After that, Sr_{i} encrypts Share_{i} as \(C_{i}^{share}=Enc_{pk_{Q}}(Share_{i})\) with Q’s public key. Then, Sr_{i} sends \(C_{i}^{share}\) to Q.

Recover. If Q collects at least t correct and different shares, he can recover the data as described in Eq. 2. Without loss of generality, we assume the t shares come from Sr_{1}, Sr_{2}, ⋯ , Sr_{t}. First, Q should verify the validations of Share_{1}, Share_{2} and Share_{t}. Specifically, i from 1 to t, Q computes
$$g^{F_{i}}=(g^{a_{t1}})^{Sr_{i}^{t1}}{\cdots} (g^{a_{1}})^{Sr_{i}}(g^{a_{0}})=g^{a_{t1}Sr_{i}^{t1}+\cdots+a_{1}Sr_{i}+s_{core}} $$$$g^{h_{i}}=(g^{b_{2t2}})^{Sr_{i}^{2t2}}{\cdots} (g^{b_{1}})^{Sr_{i}}=g^{b_{2t2}Sr_{i}^{2t2}+\cdots+b_{1}Sr_{i}} $$After that, with \(s_{i_{1}},s_{i_{2}},\cdots ,s_{i_{m}}\) and bilinear map e, Q further computes
$$\begin{array}{@{}rcl@{}} {E_{i}^{1}}&=&e(g^{F_{i}}g^{s_{i_{1}}},g^{F_{i}}g^{s_{i_{2}}})e(g^{F_{i}}g^{s_{i_{3}}},g^{F_{i}}g^{s_{i_{4}}})\\ && {\cdots} e(g^{F_{i}}g^{s_{i_{k_{1}1}}},g^{F_{i}}g^{s_{i_{k_{1}}}})\\ {E_{i}^{2}}&=&e(g_{i}^{F_{i}}g^{s_{i_{k_{1}+ 1}}}g_{i}^{F_{i}}g^{s_{i_{k_{1}+ 2}}}{\cdots} g_{i}^{F_{i}}g^{s_{i_{k_{1}+k_{2}}}},g)\\ \end{array} $$If
$${E_{i}^{1}}{E_{i}^{2}}/e(g^{h_{i}},g^{\frac{k}{2}})=e(g^{\mathit{Share}_{i}},g), $$then Q considers that Share_{i} is correctly computed by Sr_{i}. If all Share_{1}, Share_{2} and Share_{t} are correctly computed by senders, then Q can recover the data with Share_{1}, Share_{2} and Share_{t}. Specifically, Q can reconstruct a polynomial of degree t − 1 by Lagrange interpolating as follow:
$$\widetilde{F}(x) = \sum\limits_{i = 1}^{t} \mathit{Share}_{i} \prod\limits_{j = 1,j\neq i}^{t}\frac{Sr_{j}x}{Sr_{j}Sr_{i}} $$Finally, \(\widetilde {F}(0)\) equals to data.
Rights and permissions
Open Access This article is distributed under the terms of the Creative Commons Attribution 4.0 International License (http://creativecommons.org/licenses/by/4.0/), which permits unrestricted use, distribution, and reproduction in any medium, provided you give appropriate credit to the original author(s) and the source, provide a link to the Creative Commons license, and indicate if changes were made.
About this article
Cite this article
Zhou, L., Wang, L. & Sun, Y. MIStore: a BlockchainBased Medical Insurance Storage System. J Med Syst 42, 149 (2018). https://doi.org/10.1007/s1091601809964
Received:
Accepted:
Published:
DOI: https://doi.org/10.1007/s1091601809964