Abstract
Health data sharing, as a booming demand, enables the patients with similar symptoms to connect with each other and doctors to obtain the medical history of patients. Health data are usually collected from edge-based Internet of medical things (IoMT) with devices such as smart wearable devices, smart watches, and smartphones. Since health data are highly private and have great financial value, adversaries ceaselessly launch diverse attacks to obtain private information. All these issues pose great challenges to health data sharing in edge-based IoMT scenarios. Existing research either lacks comprehensive consideration of privacy and security protection or fails to provide a proper incentive mechanism, which expels users from sharing data. In this study, we propose a novel blockchain-assisted data sharing scheme, which allows secure and privacy-preserving profile matching. A bloom filter with hash functions is designed to verify the authenticity of keyword ciphertext. Key-policy attribute-based encryption (KP-ABE) algorithm and smart contracts are employed to achieve secure profile matching. To incentivize users actively participating in profile matching, we devise an incentive mechanism and construct a two-phase Stackelberg game to address pricing problems for data owners and accessing problems of data requesters. The optimal pricing mechanism is specially designed for encouraging more users to participate in health data sharing and maximizing users’ profit. Moreover, security analysis illustrates that the proposed protocol is capable of satisfying various security goals, while performance evaluation shows high scalability and feasibility of the proposed scheme in edge-based IoMT scenarios.
1. Introduction
Internet of medical things (IoMT) can improve healthcare service quality by sharing health data among users and realize remote health care. Generally, profile matching is the prerequisite of health data sharing. For example, patients with similar symptoms may want to connect with others, exchange their experiences, and broaden the understanding of the symptoms helping them to get early diagnosis or better treatments in time [1, 2].
Since IoMT devices are usually resource constraint, edge computing is introduced into the system to improve the efficiency [3, 4]. Due to privacy-sensitive nature of health data, data security and privacy preservation are crucial in edge-based IoMT system. Although the existing schemes use cryptographic algorithms to achieve security, there are still some threats because the edge is a semi-trusted center and also faces a single point of failure. In addition, these works failed to take incentive problem into consideration for users. Even though incentive mechanism is considered in [5, 6], the security issues in profile matching have hardly been solved.
Fortunately, emerging blockchain technology is tamper-proof, decentralized, transparent, anonymous, and autonomous, which is a promising solution for the aforementioned problems [7]. Although blockchain is conducive to profile matching and health data sharing, there are still three following challenges: (1) how to realize privacy preservation through profile matching in blockchain environment? (2) How to ensure that the authenticity of the keyword is selected from a valid keyword set while not revealing users’ private information? (3) How to design an incentive mechanism for motivating users to take an active part in the system?
To solve the above challenges, we put forward a secure and privacy-preserving profile matching scheme by employing key-policy attribute-based (KP-ABE) keyword search and bloom filter in edge-based IoMT. Blockchain is adopted to store the keyword ciphertext. It ensures that requesters access the desired data and protect data privacy. Moreover, the bloom filter verifies the authenticity of keyword ciphertext using various hash functions without disclosing any sensitive information. We design an optimal pricing mechanism to incentivize data owners and data requesters to participate in this system.
The major contributions of the proposed scheme are summarized as follows. We construct a new blockchain-based profile matching framework in edge-based IoMT with security and privacy preservation. We design a bloom filter based on many hash functions to verify whether the keyword is selected from a valid keyword set before storing the keyword ciphertext in blockchain. In this way, the computational cost is significantly reduced. We present a key-policy attribute-based keyword search and bloom filter profile matching protocol in a blockchain-enabled edge-based IoMT. Only when data users’ attribute set satisfies the access structure set, users are able to access the desired data. Data owners’ original data are stored in local server, while the corresponding keyword ciphertext is kept in blockchain verified by a bloom filter. It greatly improves search efficiency. We devise an optimal pricing mechanism to motivate users to actively participate in the system. The data owners take part in pricing and setting payment for matching data according to pricing list based on an optimal pricing mechanism. In particular, it provides an economic approach to analyze the incentive mechanism. By utilizing game-based optimal pricing mechanism, data owners and data requesters can obtain their maximum benefits. Furthermore, we implement smart contracts on the Ethereum platform and conduct extensive evaluations to demonstrate the superiority of the proposed scheme.
The structure of the study is organized as follows. Related works about health data sharing with edge computing blockchain-based profile matching are elaborated in Section 2. Section 3 introduces preliminaries of the work. Section 4 presents system architecture, workflow, security threats, and design goals. Section 5 designs the detailed profile matching protocol for the proposed blockchain, proposes an optimal pricing mechanism to incentive data owner and data requester actively participating in data sharing, and presents the smart contracts. Then, Section 6 analyzes how our scheme achieves the security goals. Section 7 carries out the proposed scheme on Ethereum platform to estimate the performance of protocol and smart contracts. Finally, Section 8 concludes this work.
2. Related Work
In this section, we introduce existing relevant researches on health data sharing with edge computing, profile matching, and incentive mechanisms.
2.1. Health Data Sharing with Edge Computing
Privacy issues emerge with the fast development of edge computing and IoMT [8, 9]. The edge node was the closest to the restricted resource devices and had strong computing power. Therefore, some edge-based healthcare systems were proposed [10]. Pustokhina et al. [11] presented an effective scheme in edge computing-enabled IoMT system. The IoMT devices sensed patient’s data and transferred the captured data to edge computing. Aiming at guaranteeing data security and flexible right control simultaneously, an efficient attribute-based encryption (ABE) scheme was proposed to outsource part of encryption and decryption to edge nodes [12]. It supported attribute updates and reduced the computing cost of resource-constrained devices for edge-enabled smart health care. To rely on a trusted center, Akkaoui et al. [13] proposed a blockchain-based secure health data sharing framework in edge computing, named “EdgeMediChain.” The work promoted the necessary requirements for scalability, security, and privacy of medical ecosystem. Similarly, Nguyen et al. [14] proposed a new decentralized health architecture that integrates mobile edge computing and blockchain for data offloading and data sharing in distributed hospital networks. They utilized a decentralized authentication mechanism associated with a distributed IPFS storage to improve service quality. The ongoing study [15] proposed a ubiquitous healthcare framework that leveraged edge computing, big data, deep learning, high-performance computing, and the IoMT to solve the above challenges. The framework made use of four layers. Three main components improved network service quality. However, these works did not provide profile matching and incentive mechanisms for these health data.
2.2. Profile Matching
Some cloud-assisted solutions have been proposed to address the problems of data security and privacy preservation for profile matching [16–18]. Li et al. [17] put forward a privacy-preserving and scalable matching protocol without disclosing the users’ personal data to the cloud. To achieve secure communication between users, He et al. [18] designed an efficient Cross-Domain HandShake (CDHS) scheme with symptom matching in hierarchical identity-based cryptosystem. Compared with the existing profile matching schemes, their schemes used cloud computing to conduct most of the computation, which effectively reduced user’s computation complexity. However, the cloud is a semi-trusted center, which may collude with other malicious users to obtain the sensitive data.
Blockchain has drawn considerable interests in research and industrial communities [19–22] due to its advantages. Yang et al. [23] designed a distributed matching mechanism based on blockchain. Furthermore, their scheme transformed the social welfare maximization problem into a matching game of bilateral matching and unilateral preference. Meng et al. [24] proposed a blockchain-enabled signature matching while achieving data security and privacy preservation. In [25], a matching scheme based on hierarchical blockchain was proposed to protect users’ privacy. The scheme combined ciphertext-policy attribute-based (CP-ABE) encryption and bloom filter to meet users’ requirements to search friends.
The aforementioned works proposed heuristic blockchain-based profile matching schemes with data security and privacy preservation. In fact, some researches presented a structure or concept for profile matching based on blockchain without technically proposing a solution in detail for a specific application scenario. In this work, we present a novel blockchain-based profile matching framework by employing (key-policy attribute-based encryption) KP-ABE and bloom filter to achieve data security and privacy preservation. In addition, we design a detailed profile matching protocol and implement the devised smart contracts on Ethereum test platform.
2.3. Incentive Mechanisms
To encourage more users to join the system, some incentive mechanisms have been designed. Jiao et al. [26] proposed a profit maximization mechanism to maximize the profit under different users’ valuation distributions. The pricing mechanism effectively solved the profit maximization problem and provided useful strategies for users. Game-theoretic methods had been extensively used in pricing mechanism [27, 28]. The uncertainty of future prices with a single-leader, multiple-follower Stackelberg game was proposed to maximize profits by setting optimal pricing strategy [27]. It provided a simple distributed algorithm for finding the unique Stackelberg equilibrium point. Chen et al. [28] proposed a pricing approach for incentive mechanisms and considered a two-stage game in a three-layer architecture. They formulated a Markov decision process (MDP)-based social welfare maximization model and studied a convex optimization pricing problem.
Some works adopted blockchain technology to design incentive mechanisms. Liu et al. [29] designed an optimal pricing mechanism and adopted a two-phase Stackelberg game to address pricing and buying problem of the users. Furthermore, they used backward induction to investigate the quantity of purchased data and pricing strategies. Li et al. [30] put forward an incentive mechanism to encourage users to participate in sharing data through price-aware top-k matching queries. Xiong et al. [31] proposed multi-leader multi-follower game-based alternating direction method of multipliers algorithm for pricing to accomplish optimum results in a distributed manner. Zhang et al. [32] designed a dynamic, hierarchical pricing mechanism based on economic modeling methods and heterogeneous agent theory. Nie et al. [33] proposed an optimal incentive mechanism of users using backward induction and applied a Stackelberg game to analyze users’ participation level.
The existing work failed to apply the incentive mechanism to encourage data owners and data requesters to share health data. In this scheme, we combine blockchain technology and smart contract to design an optimal pricing mechanism with the guarantee of data security and privacy preservation for motivating users to actively join the system and maximizing their profits.
3. Preliminaries
In this section, we provide preliminaries required in this work.
3.1. Cryptographic Assumptions
Definition 1. Decisional Bilinear Diffie–Hellman Problem (DBDH). We denote an elliptic curve as and consider a cycle group of prime order . Let be a generator in and . The DBDH problem is defined as follows: given an input tuple , is computed. Assume that an attacker can successfully distinguish between and with the advantage . If the DBDH assumption holds, the advantage must be ignored.
3.2. Linear Secret-Sharing Schemes (LSSS)
An LSSS access structure is denoted as , where is an matrix and is an injective function from . to attributes. Let be an authorized set, defined as . Let be the set of distinct attributes in . Here, . There exist constants such that , where is row of . It randomly generates a vector , where is the secret to be shared and is randomly chosen. For , it will compute , where is row of . Given an attribute set and , is found and is formulated.
3.3. Bloom Filter
A bloom filter [34] is a data structure for validating whether an element comes from a set. An -bit bloom filter can be represented by a set of hash functions , . All the positions in the array are all initially 0. To query an input into the bloom filter, its corresponding position is set as 1; i.e., is set. The bloom filter checks whether an element is selected from a set . is hashed by the hash functions to obtain hashed array positions. If any of the bits in these positions are set to 0, it represents that the element does not belong to the set. Otherwise, all the bits in the positions are set to 1, which means the element is in the set. There exists a possibility that , and all bits in the corresponding positions are all 1, termed as the false-positive error. Its probability is . Here, . Hash functions are able to minimize false-positive probability . There are two algorithms, shown as follows: , and algorithm puts all into BF. . If , it returns 0. Otherwise, it returns 1.
3.4. Blockchain and Smart Contract
Blockchain is a distributed ledger, which records numerous transactions [35]. All nodes in the network have the same copy of the ledger. Blockchain has the features of decentralization, privacy preservation, immutability, fault tolerance, and the ability to implement smart contracts. In blockchain, consensus algorithm is used to address the consistency issue of untrusted systems [36]. Current proposed consensus mechanisms include proof of work (PoW), proof of stake (PoS), and delegated proof of stake (DPoS) [37–39]. In our system, we design a proof of existence consensus mechanism for the proposed system.
Smart contract is a computer program that can be self-executed, self-verified, and tamper-resistant without trusted parties. The credibility of smart contract drives from its unforgeability. It cannot be modified or altered once it is deployed on blockchain. Ethereum is a decentralized application platform of smart contract, which supports application of Turing complete. It allows users to create, deploy, and run smart contract on blockchain. In our scheme, we design and deploy the smart contracts on Ethereum to test its availability and evaluate its performance.
4. System Model
In this section, we first propose the system architecture built upon edge-based IoMT. Then, we analyze the security threats and set the security goals.
4.1. System Architecture
The proposed model is made up of different entities: attribute authority (AA), IoMT devices, data owners (DOs), data requesters (DRs), and edge nodes, as shown in Figure 1. The major symbols used in the system architecture are listed in Table 1.
4.1.1. Attribute Authority
AA takes charge of system initialization and registration for DO and DR. It is a trustworthy center in this system. Furthermore, AA generates attribute keys for authorized entities.
4.1.2. IoMT Devices
IoMT devices contain smart devices, such as smartphone, smart watch, and other wearable devices. They are used to collect the data, especially health data in this context. Furthermore, the collected data are uploaded to DOs who can share their data with others within the edge-based IoMT infrastructure.
4.1.3. Data Owners
Data owners refer to patients who construct a community to share their medical experiences and symptoms with others for broadening healthcare information. These DOs can form a social Internet. Additionally, they can earn fees by sharing their symptoms and experiences. They must register at the AA for obtaining attribute keys and joining the system. Moreover, DOs encrypt the keywords of their symptoms using attribute keys. They participate in pricing smart contract to derive an optimal price according to their own pricing strategies.
4.1.4. Data Requesters
Data requesters refer to patients who want to seek similar patients. Similar patients can share medical experiences, so that data requesters can better understand their health states. The DR should firstly register at the AA for attribute keys to take part in the system. The DR can generate search tokens using attribute keys and search relevant symptoms on blockchain. Once DRs receive the matching result from pricing and payment smart contract, they will select the intending data according to the matching results and pay fees to the corresponding DO by pricing and payment smart contract. Furthermore, they earn the fee by providing feedback to feedback smart contract.
4.1.5. Edge Nodes
Edge nodes are used to maintain the blockchain. Edge nodes are also responsible for packaging transactions into blocks in the blockchain.
There are three smart contracts deployed in our proposed blockchain: verification smart contract (VSC), pricing and payment smart contract (PPC), and feedback smart contract (FSC). Firstly, verification smart contract is used to verify whether the profile keywords are valid. Secondly, pricing and payment smart contract is used to set price based on the optimal pricing mechanism and transfer fee to corresponding user’s account. Finally, feedback smart contract is used to reward data requester.
4.2. Workflow
Firstly, data requesters and data owners register at the AA for gaining attribute keys to join the system. Patients (data owners) construct a community to share their medical experiences and symptoms with others. They encrypt and upload their profile keywords. KP-ABE and verification smart contract verify whether the keywords belong to a keywords set. If the keywords are valid, they will be uploaded to blockchain for users to search. A data requester, who wants to seek similar patients without real identities, uses the master public key, keywords, and his/her private key to generate a token for searching. After that, if there are matching keywords, they will be sent to pricing and payment smart contract. The results of pricing will be sent to the DR. Furthermore, the DR is able to access DOs’ data by paying fees to them. DRs send feedback information to feedback smart contract. Moreover, a small fee is rewarded to the DR by feedback smart contract.
4.3. Security Threats and Design Goals
In our scheme, the AA is completely trusted for performing registration and generating attribute keys, but unauthorized entities may access the encrypted profile keywords and tokens to gain DOs’ private information such as identity and address during its transmission in the system. Furthermore, there may be some dishonest requesters who access DOs’ data without paying fees. Some DOs may provide false/fake information to requesters. Thus, we aim to achieve the following security goals.
4.3.1. Privacy Preservation
DOs’ identities contain some significant privacy information, which cannot be leaked or learned by unauthorized opponents. Besides, feedback information from requesters cannot reveal the DOs’ identity information.
4.3.2. Secure Match
In our scheme, the eavesdroppers attempt to guess attribute keys or search tokens for accessing data. Therefore, it is of great significance to protect keys and tokens from revealing during matching process.
4.3.3. Fairness and Incentive
DRs must pay a reasonable fee to a DO for accessing the DOs’ data. On the other hand, DOs should provide true information for DRs. Smart contract could realize payment with fairness and verify the authenticity of the matched profile keywords. To incentivize more DRs and DOs to participate in sharing health data, we design an optimal pricing mechanism to maximize their profits. When DRs and DOs accomplish data sharing, they will obtain corresponding rewards.
4.3.4. Access Control
DOs have the ability to control data access and establish access policy. Access control ensures that requesters satisfying access policy can access the DOs’ information. Malicious attackers cannot eavesdrop or modify patients’ profile keywords, which are transmitted in the public channel of edge-based IoMT. The attribute-based encryption algorithm is adopted to achieve data confidentiality and integrity in this system.
5. The Proposed Protocol
In this section, we firstly describe the proposed protocol based on blockchain. Then, we demonstrate the optimal pricing mechanism.
5.1. Protocol Description
The proposed protocol contains three phases: system setup, index generation, and profile matching. The process of the proposed protocol is shown in Figure 2.
5.1.1. Phase1: System Setup
Given a security parameter , the AA selects a bilinear map [40] , where and are two additive cyclic groups of the same prime order . is a multiplicative cyclic group of prime order . is the generator of , and is the generator of . AA chooses a hash function , where . In addition, the AA randomly chooses , , and , . In the system, it defines the attribute space as . Let be the number of bits in a bloom filter (BF) and be the amount of hash functions in a BF. The AA selects random group elements . It generates hash functions , which are used to add an element into corresponding positions in a BF. The master public key , and the master secret key .
The AA generates a secret key when a requester registers at the AA. There is an LSSS access structure for the requester, where is an matrix and is a set of diverse attributes in . It means , and . The function makes a row of matrix map to attributes. It chooses a random vector . This vector’s values will be used to share . For , it computes , where is row of . Furthermore, it chooses and computes , , , and . Let the private key be .
5.1.2. Phase 2: Index Generation
Firstly, consensus users from edge nodes participating in profile matching are selected to participate in the network consensus, shown in Figure 3. Assume that the number of all consensus users is in the blockchain network. The system generates a random number as the index of the consensus users to be the selected as the miner.
Secondly, an edge node selects a random value . He/she computes the keyword ciphertext , where , , , and . Then, the miner sends to blockchain and generates transaction data stored in the transaction pool, packs them into a block, and sends the block to all the consensus users who can verify that the keyword of secure index in the new generating block is selected from according to Algorithm 1. If , it returns 1, otherwise it returns 0. The bloom filter is used to verify the authenticity of keywords, shown in Algorithm 2.
| ||||||||||||||||||||||
| ||||||||||||||||||
5.1.3. Phase 3: Profile Matching
Keyword search. The DR searches desired data using the DR’s private key to generate a keyword trapdoor in blockchain. The trapdoor is generated as follows. Choose a random vector , where random number . This vector’s values will be used to share . For , it computes . It chooses and computes , , , and , where is a set of distinct attributes in for . Then, DR sends to blockchain.
Test. Assume that attributes associated with satisfy . There exists such that , where is row of . Given an original ciphertext , a keyword , and a search token , the following equation is verified:
If (2) holds, the matching keyword is sent to pricing and payment smart contract. The DO sets payment according to the optimal pricing mechanism. The incentive mechanism is expected to encourage more data owners and data requesters to participate in the process of profile matching. Otherwise, it aborts.
Correctness: when the encrypted keyword is the same as the keyword in the trapdoor, the correctness of the test algorithm is verified as follows:
Based on PBFT, if not less than consensus users verify the new block, following the basic setting of , etc. [41], the new block will be added into the blockchain as a new valid block. In this round, the generation of a valid block marks the completion of consensus. The miner will generate a random number to determine the next miner in the next round. Then, the DO participates in pricing and sets the fees. When the DR wants to access the desired data, he/she needs to pay the fee to the corresponding DO by PPC. The specific pricing process can be seen in the following optimal pricing mechanism.
5.2. Optimal Pricing Mechanism
When a data requester matches the profile keyword in blockchain, he/she accesses the corresponding data by paying fees to the data owner. In this section, we design an optimal pricing mechanism based on a Stackelberg game. Optimal price maximizes the profits of the data owners and the data requesters. The data owners determine their own prices of data based on profit functions as the leaders. The data requesters determine the access quantity of data as followers. The Stackelberg game is between data owners and data requesters, shown in Figure 4.
5.2.1. Stackelberg Game Problem Formulation
The number of data owners is . A set of data owners can be expressed by . Data owners provide the desired data for the data requester. In our optimal pricing mechanism, there is a DR determining access strategy, such as access amount of data. Meanwhile, each data owner determines the optimal price for corresponding data. The access amount of the data requester from data owner is . The unit price of data owner for the data requester is . We denote the access amount set and the optimal access amount set of the data requester from different data owners as and , respectively. The unit price set and the optimal price set of the data requester from different data owners are denoted as and , respectively. The main symbols used in an optimal pricing mechanism are shown in Table 2.
To evaluate the access quality of data, an access quality factor is denoted by . Data owner provides data’s quality, formulated as follows:
The data requester’s utility is expressed as follows:
The data requester gives a feedback evaluation to the data of the data owner and obtains small fees as rewards, denoted as . is the accessing willingness of the data requester. The data requester maximizes its utility based on the access quantity , forming its subgame, which is given as follows. Problem 1 (data requester’s subgame for data owner j): is the minimum amount of accessed data, and is the largest amount of accessed data. Data owner’s utility can be expressed as follows: Here, represents the unit cost set by data owner . The data owner’s reputation score is expressed as , which changes dynamically according to the data requester feedback on the data owner’s data and amount of files downloaded by the data requester. . The terms and are lower and upper bound reputation scores, respectively. . is the bad reputation score threshold. is the initial reputation score threshold. is the good reputation score threshold. The data owner maximizes its utility based on the price , forming its subgame, which is given as follows. Problem 2 (data owner’s subgame for the data requester):
The data requester can accept the maximum price, denoted as . Problem 1 and problem 2 constitute the Stackelberg game, which aims for finding the equilibrium points. In other words, the profit of data owner comes up to maximization when the data requester obtains its largest profit.
Definition 2. The points are an equilibrium if it satisfies both the following two conditions:To analyze the Stackelberg game, we use backward induction [28].
5.2.2. Data Requesters’ Accessing Strategy in Stage II
Data owner provides data’s unit price for the data requester (i.e., , for all ). The data requester from data owner decides its optimal access strategy (i.e., , for all ).
First, we take the derivative on the data requester’s utility in (5) according to , which is expressed as follows:
is a strictly concave function shown by the above derivatives. To obtain the optimal response function, we set , which is given as follows:
Then,
According to (14), is data requester’s optimal quantity of accessed data.
5.2.3. Data Owners’ Pricing Strategies in Stage I
Data owner can obtain his/her largest profit based on the data requester’s optimal access strategy. According to formulation (7)–(14), the optimal utility of data owner for the DR can be rewritten as follows:
First, we take the derivative on data owner’s utility in (15) according to , which is expressed as follows:
is a strictly concave function shown by the above derivatives. To obtain the optimal response function, we set , which is given as follows:
Then,
According to (19), when , , , and are the active impact, it will get data owner’s optimal price.
According to (7), we gain the data requester’s optimal utility from data owner, given as follows:
According to (5)–(19), we are able to get the optimal utility of the data requester from data owner , given as follows:
By finding the equilibrium point of the game, both the data requester and the data owners can obtain their own optimal utility. A Nash equilibrium reaches between them. Meanwhile, the incentive mechanism promotes the data owners to take an active part in sharing their experiences. There will be some contradictions and conflicts of benefits if there is no balance between data requesters and data owners.
5.3. Smart Contract Design
To satisfy the system’s requirements, we design smart contracts with various functions. The interactions among contracts (programmed in Solidity\footnotehttps: // remix ethereum org/) for Ethereum include the following steps. The function is given in Algorithm 3. KeywordCiphertext (CW): This function is called to store keyword ciphertext in blockchain. Before storing the data in blockchain, the DO sends the keyword with hash functions to invoke VSC for verifying that the keyword is selected from a valid keyword set. If the keyword is correct, the keyword ciphertext will be packed in a block. Pricing (Pricinglist, pricing): This function is used to formulate pricing list for blockchain. Before generating the pricing list based on an optimal pricing mechanism provided by the DO, PPC will invoke VSC for verifying the validity of the keyword. If it is valid, the DO will take part in pricing built on an optimal pricing mechanism. Then, the pricing list will be stored in blockchain. setFee (Paymentstruct, payment): The function is called to set charges for desired data and feedback data. The fee is divided into two parts: the DO’s data fee and the DR’s reward fee. Payment (account, fee): The DR calls this function to transfer the fee to the intended DO’s account. Then, he/she can access the desired data. If deposit of the DR’s account is enough, it will be executed. Furthermore, PPC sends the payment result to FSC.
|
6. Security Proof
In this section, we analyze how the proposed scheme is able to effectively realize the goals defined in the section of system model.
6.1. Privacy Preservation
Users send data to blockchain through their blockchain account during data transmissions in edge-based IoMT. Due to the immunity characteristics of blockchain, data in the blockchain are tamper-proof. Therefore, users’ sensitive information can be protected. Furthermore, the encrypted keywords are stored in blockchain. They will not divulge any information of users. Our scheme utilizes a bloom filter in smart contract to verify the validity of keywords, which reduces the unnecessary consumption. The optimal pricing mechanism is used to incentivize the DO and the DR to share their data. Malicious behaviors are prevented from getting illegal fees via the anonymous blockchain account.
6.2. Secure Match
Definition 3. Secure match. An adversary cannot distinguish the keyword from keyword ciphertext or search trapdoor.
Theorem 1. The proposed protocol can achieve secure match in the random oracle model on the DBDH assumption.
To avoid reinvent the wheel, we refer to [43] for the keyword secrecy game. Security proof is as follows.
Proof. The random oracles of algorithms Private key, Trapdoor, and Test are , , and , respectively. Assume that is an attacker who has advantage to attack the proposed chosen keyword attack game. We build a challenger . He/she plays game with to derive the solution to the DBDH problem as follows: List : record .
6.2.1. Setup
Given a security parameter and an input tuple , challenger generates the system master public key and the master secret key .(a): if the query exists on in a tuple , is returned; else, is chosen, is added to , and is returned(b): if the query exists on in a tuple , is returned; else, is chosen, is added to , and is returned
6.2.2. Phase 1
(a): Since challenger has knowledge of and , it can construct private key corresponding to any , and next, the tuple is added to . When satisfies , is output.(b): If matches , challenger outputs . Else, can set as in . chooses a random vector with the first element and next sets . It chooses and constructs the trapdoor as in the real scheme.(c): If the attribute set associated with is , outputs . Else, can always compute a trapdoor as in . Then, it proceeds to the test easily. If the test holds, outputs 1 and 0 otherwise.6.2.3. Challenge
outputs and . Challenger sets the original challenge ciphertext as follows:(a), , and are set.(b)A random coin is flipped, and an query on is issued to achieve .(c)An query on is issued to achieve .(d)The challenge original ciphertext is output as .(e)If , then generated a valid ciphertext in which and . After that, sends to .
6.2.4. Phase 2
The phase is the same as the Phase 1.
6.2.5. Guess
outputs a guess bit , if , and outputs 1; else, it outputs 0.
In the guess phase, if , then we have the following:
In addition,
Consequently,
Thus, the probability of wining the keyword secrecy game is at least.
6.3. Fairness and Incentive
The DO’s attribute key is used to encrypt the profile keywords. The bloom filter and smart contract can verify the authenticity of keywords. By this way, only valid keywords can be uploaded to blockchain. To search the desired keyword, DR must generate a search trapdoor according to his/her selected access structure. Thus, other entities cannot obtain any information about keywords and matching results during the process of keyword searching. Attackers cannot learn any information from encrypted keywords and trapdoors. Therefore, our scheme can achieve secure match.
6.4. Access Control
Our scheme utilizes key-policy attribute-based encryption (KP-ABE) in the proposed protocol. The keyword is encrypted by the DO’s attribute set . The DR uses his/her key to generate a search trapdoor , which is related to the access structure. It is used for searching the matching keyword. Only when the attribute of keyword ciphertext satisfies the access structure of search trapdoor , the DR can access the desired data after calling pricing and payment smart contract (PPC) to transfer fees to a specific DO’s account. If the DR fails to pay fees to the DO’s account, he/she cannot query the intended data. Thus, DO is able to control the access of his/her data.
7. Implementation and Performance Evaluation
In this section, we implement the proposed algorithms in a simulated edge-based IoMT environment with Java programming and JPBC library. We deploy the designed smart contracts on Ethereum test platform. Firstly, we introduce the parameter settings. We compare the security properties of our solution with other relevant solutions. Then, the computational overhead and communication overhead are analyzed for the proposed protocol. We design the smart contracts and evaluate the performance of the designed smart contracts on Ethereum test platform. Finally, we evaluate the performance of the proposed optimal pricing mechanism.
7.1. Parameter Settings and Platform
The system security parameter . For some prime , we utilize type A pairing on the elliptic curve over the field . The cryptographic primitives are implemented using JPBC library and Java on a laptop computer with Intel (R) Core (TM) i5-7400 CPU @3.00 GHz, 8 GB RAM, and Microsoft Windows 10 operating system.
In addition, we employ Ganache (client version) to build a local test chain on Linux system. We use solidity language to write data into smart contracts and then upload it to blockchain. Smart contract framework and solidity compiler are truffle @0.5.0 and solc @0.5.0, respectively. To gain time consumption of publishing smart contracts, we utilize Web3js library of Nodejs to interact with smart contracts on the blockchain and test the time cost of marking transactions. Due to the limited space, the specific deployment process is skipped.
7.2. Comparisons of Security Properties
We compare the security properties of our scheme with other matching schemes in Table 3. The comparison results indicate that the proposed scheme is capable of providing a promising solution to improve profile matching service in edge-based IoMT scenarios [25, 42, 43]. Their scheme does not achieve security properties of blockchain-based and fairness and incentive. However, our scheme can provide all of the security properties.
7.3. Communication Overhead and Computational Cost
In edge-based IoMT scenarios, the communication and computation resources are constrained. In this subsection, we show the improved performances of the proposed scheme. We denote , , , and as the size of elements in , , , and . The communication overhead is caused by index generation phase and keyword search phase, shown in Table 4. In index generation phase, DO sends to blockchain for searching data, and the total length is bytes. The DR sends search trapdoor using the secret key to blockchain for searching the desired data, and the total length is bytes during the process of keyword search. We compare the communication overhead with [42, 43], shown in Table 4. As can be seen from Table 4, the index generation overhead of the proposed scheme is lower. In addition, the overhead of keyword search phase in [42, 43] is higher than our proposed scheme.
We compare the computational overhead in Table 5. The algorithm SystemInit simulates system setup phase. The generated keyword ciphertext is simulated by the algorithm Encrypt. Furthermore, the algorithm Trapdoor generates secret key and search trapdoor for the DR. The algorithm Test is used to test whether the keyword ciphertext and trapdoor match. From Table 5, we observe that our computational overhead is higher than that in [43] during the process of the algorithm Test. Nonetheless, our scheme’s computational overhead is lower than other two schemes.
7.4. Time Consumption of Smart Contracts and Resource Consumption of Nodes
Because the length of data affects the time consumption of transmitting a transaction to blockchain, we firstly discuss its length. According to Section 7.3, the length of index generation and keyword search is and . As can be seen from Table 6, we see that the average time consumption of sending a transaction KeywordCipheretext to blockchain is 98.8 ms, a transaction Pricing is 354.84 ms, and a transaction Feedback is 79.49 ms. The gas consumption of transaction KeywordCipheretext is 0.0146637 ether, transaction Pricing is 0.03544138 ether, and transaction Feedback is 0.01035046 ether.
7.5. Performance Analysis of Pricing Mechanism
We evaluate the performance for data owners and data requesters under the proposed optimal pricing mechanism, as shown in Figure 5. We set some parameter values, denoted as follows: , , , , and . The parameter represents the data requester’s willingness to access the data. When values are different, we simulate the utility of data owners and data requesters, where is equal to in [44]. In Figures 5(a) and 5(b), we compare optimal pricing mechanism with independent pricing scheme in [44]. We find that the amount of accessed data increases and data requester’s utility increases. It shows that in our scheme, the data requester can have more utility than Liu’s scheme in [44]. Figure 5(c) and 5(d) shows that the data owners can get more utility with the increase in unit price. Moreover, the results show that the data owners get more profits in our scheme than Liu’s scheme in [44] when the accessing willingness of requester increases.
(a)
(b)
(c)
(d)
8. Conclusion and Future Work
In this work, we introduce a new blockchain-based profile matching scheme by utilizing KP-ABE algorithm and bloom filter, which guarantees privacy preservation and security of health data in edge-based IoMT. Firstly, we present a system framework based on blockchain for profile matching among different users. Secondly, we design a consensus mechanism for proposed blockchain to achieve the consensus of the system. Thirdly, smart contract with an optimal pricing mechanism is designed to formulate pricing list and encourage more users to participate in the system. We evaluate the performance of communication overhead. We employ JPBC library to evaluate computational cost of the proposed protocol, compared with other schemes. Finally, we deploy the smart contracts on Ethereum platform and test the time consumption of smart contracts.
In our future work, we plan to deploy smart contracts on Hyperledger Fabric and store original data using encryption algorithm in IPFS for profile matching, which has a potential to improve the performances in edge-based IoMT scenarios.
Data Availability
No data were used to support this study.
Conflicts of Interest
The authors declare that they have no conflicts of interest.
Acknowledgments
This work was supported in part by the National Natural Science Foundation of China under Grant 62072005 and the Natural Science Foundation of Anhui Province under Grant 2108085Y22.