# Blockchain-Empowered Secure and Privacy-Preserving Health Data Sharing in Edge-Based IoMT

Authors: Xueli Nie; Aiqing Zhang; Jindou Chen; Youyang Qu; Shui Yu
Journal: Security and Communication Networks
 (2022)

---

## 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.


---

## Body

## 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 Section2. 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.


## 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 asE and consider a cycle group G of prime order q. Let P be a generator in G1 and a,b,c,z∈Zq∗. The DBDH problem is defined as follows: given an input tuple P∈G1,aP∈G2,bP∈G2,cP∈G2, eP,Pabc is computed. Assume that an attacker A can successfully distinguish between eP,Pabc and eP,Pz with the advantage AdvADBDHλ. If the DBDH assumption holds, the advantage AdvADBDHλ⩽ε must be ignored.


### 3.2. Linear Secret-Sharing Schemes (LSSS)

(1)AdvADBDHλ=PrAe,P,P,P,P,eP,Pabc=1−PrAe,P,P,P,P,eP,Pz=1⩽ε.An LSSS access structure is denoted asN,ρ, where N is an l×n matrix and ρ is an injective function from 1,2,…,l. to attributes. Let S∈N be an authorized set, defined as I=i|ρi∈S. Let Tr be the set of distinct attributes in N. Here, Tr=b:∃i∈1,l,ρi=b. There exist constants πi∈ZP,i∈I such that ∑i∈IπiNi=1,0,…0, where Ni is ith row of N. It randomly generates a vector v⟶=μ1,r2,…,rn, where μ1∈Zq∗ is the secret to be shared and r2,…,rn∈Zq∗ is randomly chosen. For 1≤i≤l, it will compute λi=v⟶Ni, where Ni is ith row of N. Given an attribute set S and Ni, πi∈Zq,i∈I is found and ∑i∈IπiNi=1,0,…0 is formulated.


### 3.3. Bloom Filter

A bloom filter [34] is a data structure for validating whether an element comes from a set. An m-bit bloom filter can be represented by a set of hash functions H=H1′,H2′,…Hk′, i∈1,k. All the positions in the array are all initially 0. To query an input w∈W=w1,…wn into the bloom filter, its corresponding position is set as 1; i.e., BFHi′w=1,i∈1,k is set. The bloom filter checks whether an element w is selected from a set W. w is hashed by the k hash functions H=H1′,H2′,…Hk′ to obtain k hashed array positions. If any of the bits in these positions are set to 0, it represents that the element w 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 w∉W, and all bits in the corresponding positions are all 1, termed as the false-positive error. Its probability is 1−1−1/mknk. Here, k=m/nln2. Hash functions are able to minimize false-positive probability 0.6185m/n. There are two algorithms, shown as follows:BF⟵BFBuildH1′,H2′,…,Hk′w1,w2,…,wn⋅BFBuild, and algorithm puts all w into BF.cw←VerifyBFH1′,H2′,…,Hk′,BF,w. If w∉W, 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.


## 3.1. Cryptographic Assumptions

Definition 1.
Decisional Bilinear Diffie–Hellman Problem (DBDH). We denote an elliptic curve asE and consider a cycle group G of prime order q. Let P be a generator in G1 and a,b,c,z∈Zq∗. The DBDH problem is defined as follows: given an input tuple P∈G1,aP∈G2,bP∈G2,cP∈G2, eP,Pabc is computed. Assume that an attacker A can successfully distinguish between eP,Pabc and eP,Pz with the advantage AdvADBDHλ. If the DBDH assumption holds, the advantage AdvADBDHλ⩽ε must be ignored.


## 3.2. Linear Secret-Sharing Schemes (LSSS)

(1)AdvADBDHλ=PrAe,P,P,P,P,eP,Pabc=1−PrAe,P,P,P,P,eP,Pz=1⩽ε.An LSSS access structure is denoted asN,ρ, where N is an l×n matrix and ρ is an injective function from 1,2,…,l. to attributes. Let S∈N be an authorized set, defined as I=i|ρi∈S. Let Tr be the set of distinct attributes in N. Here, Tr=b:∃i∈1,l,ρi=b. There exist constants πi∈ZP,i∈I such that ∑i∈IπiNi=1,0,…0, where Ni is ith row of N. It randomly generates a vector v⟶=μ1,r2,…,rn, where μ1∈Zq∗ is the secret to be shared and r2,…,rn∈Zq∗ is randomly chosen. For 1≤i≤l, it will compute λi=v⟶Ni, where Ni is ith row of N. Given an attribute set S and Ni, πi∈Zq,i∈I is found and ∑i∈IπiNi=1,0,…0 is formulated.


## 3.3. Bloom Filter

A bloom filter [34] is a data structure for validating whether an element comes from a set. An m-bit bloom filter can be represented by a set of hash functions H=H1′,H2′,…Hk′, i∈1,k. All the positions in the array are all initially 0. To query an input w∈W=w1,…wn into the bloom filter, its corresponding position is set as 1; i.e., BFHi′w=1,i∈1,k is set. The bloom filter checks whether an element w is selected from a set W. w is hashed by the k hash functions H=H1′,H2′,…Hk′ to obtain k hashed array positions. If any of the bits in these positions are set to 0, it represents that the element w 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 w∉W, and all bits in the corresponding positions are all 1, termed as the false-positive error. Its probability is 1−1−1/mknk. Here, k=m/nln2. Hash functions are able to minimize false-positive probability 0.6185m/n. There are two algorithms, shown as follows:BF⟵BFBuildH1′,H2′,…,Hk′w1,w2,…,wn⋅BFBuild, and algorithm puts all w into BF.cw←VerifyBFH1′,H2′,…,Hk′,BF,w. If w∉W, 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 Figure1. The major symbols used in the system architecture are listed in Table 1.Figure 1
System architecture.Table 1
Notation table of the architecture.
NotationDescriptionKP-ABEKey-policy attribute-based encryptionAAAttribute authorityDOsData ownersDRsData requestersVSCVerification smart contractPPCPricing and payment smart contractFSCFeedback smart contract


#### 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.


## 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 Figure1. The major symbols used in the system architecture are listed in Table 1.Figure 1
System architecture.Table 1
Notation table of the architecture.
NotationDescriptionKP-ABEKey-policy attribute-based encryptionAAAttribute authorityDOsData ownersDRsData requestersVSCVerification smart contractPPCPricing and payment smart contractFSCFeedback smart contract


### 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.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.


## 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 Figure2.Figure 2
Proposed protocol.


#### 5.1.1. Phase1: System Setup

Given a security parameterλ, the AA selects a bilinear map [40] e:G1×G2⟶GT, where G1 and G2 are two additive cyclic groups of the same prime order q. GT is a multiplicative cyclic group of prime order q. P1 is the generator of G1, and P2 is the generator of G2. AA chooses a hash function H1, where H1:0,1⟶Zq∗. In addition, the AA randomly chooses μ1, μ2, and θi∈Zq∗, g=e^P1,P2μ2. In the system, it defines the attribute space as U∧. Let m be the number of bits in a bloom filter (BF) and k be the amount of hash functions in a BF. The AA selects U=U^ random group elements h1,h2,…,hU∈G1. It generates k hash functions H1′,H2′,…,Hk′, which are used to add an element into corresponding positions in a BF. The master public key MPK=H1,e^,g,P1,P2,μ1P1,μ2P2,θiP1,θiP2,h1,h2,…,hU,H1′,H2′,…,Hk′, and the master secret key MSK=μ1,μ2,θi.The AA generates a secret key when a requester registers at the AA. There is an LSSS access structureN,ρ for the requester, where N is an l×n matrix and Tr is a set of diverse attributes in N. It means Tr=b:∃i∈1,l,ρi=b, and ∀b∈Tr/ρi. The function ρ makes a row of matrix N map to attributes. It chooses a random vector v⟶∈Zq∗. This vector’s values will be used to share μ1. For 1≤i≤l, it computes λi=v⟶Ni, where Ni is ith row of N. Furthermore, it chooses σ1,…,σl∈Zq∗ and computes Ai=λP2+θρiσiP2, Bi=σiP2, ∀b∈Tr/ρi, and Ei,b=θbσiP2. Let the private key be ak=Ai,Bi,Ei,b.


#### 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 Figure3. Assume that the number of all consensus users is Nc in the blockchain network. The system generates a random number as the index of the consensus users to be the selected as the miner.Figure 3
Consensus process.Secondly, an edge node selects a random valueχ∈Zq∗. He/she computes the keyword ciphertext cw=I1,Iz,I2, where I1=χP1, Iz=θzχP1, z∈Att, and I2=gH1wχ. Then, the miner sends cw 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 W according to Algorithm 1. If w∈W, it returns 1, otherwise it returns 0. The bloom filter is used to verify the authenticity of keywords, shown in Algorithm 2.Algorithm 1:BuildBF (W,m,n,k,h).
Input: A keywords set W, an array of length m, n keywords, k hash functions H=H1′,H2′,…,Hk′.Output: Bloom Filter BF.(1)BF= a new m- bits array of n elements(2)fori=1 to m do(3)BFi= NULL(4)for each element w∈W do(5)fori=1 to k do(6)j=Hi′w.(7)ifBFj== NULL(8)BFj=1.(9)returnBF.Algorithm 2: VerifyBF (ADO, Hcw).
Input: A keyword w, symmetric key sk, k hash functions, EncskH=EncskH1′w,H2′w,…,Hk′w.Output:ifw∈W, return 1, else return 0(1)for each element w.(2)fori=1 to k do(3)cj=EncskHj′w.(4)j=Decskcj.(5)if each BFj==1.(6)return 1(7)else return 0


#### 5.1.3. Phase 3: Profile Matching

Keyword search. The DR searches desired data using the DR’s private key ak to generate a keyword trapdoor Tw in blockchain. The trapdoor Tw=T1,i,T2,i,T3,i,b is generated as follows.Choose a random vectorV⟶=μ,γ1,…,γl, where random number γ1,…,γl∈Zq∗. This vector’s values will be used to share μ.For1≤i≤l, it computes ηi=V⟶⋅Ni. It chooses ε1,…,εl∈Zq∗ and computes T1,i=ηiH1WP2+θiσiεiP2, T2,i=εiBi, ∀b∈T/ρi, and T3,i,b=εiEi,b, where T is a set of distinct attributes in N for 1≤i≤l. Then, DR sends Tw=T1,i,T2,i,T3,i,b to blockchain.Test. Assume that attributes Att associated with cw satisfy N,ρ. There exists i∈I,πi∈Zq∗ such that ∑i∈IπiNi=1,0,…0, where Ni is ith row of N. Given an original ciphertext cw, a keyword w, and a search token Tw, the following equation is verified:(2)eI1,∑i∈IπiT1,i+∑z∈Δ/ρiT3,i,z=?e∑z∈ΔIz,∑i∈IπiT2,i⋅I2.If (2) holds, the matching keyword w′ 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:(3)eI1,∑i∈IT1,i∑z∈Δ/ρiT3,i,zπi=eχP1,∑i∈IπiηiH1wP2+θiσεP2+∑z∈Δ/ρiεiEi,z=eχP1,∑i∈IπiV⟶⋅MiH1wP2eχP1,∑i∈IπiθiσiεiP2+∑z∈Δ/ρiεiθzσiP2=eχP1,μ1H1wP2eχP1,∑i∈Iπi∑z∈ΔεiθzσiP2e∑z∈ΔIz,∑i∈IπiT2,i⋅I2=e∑z∈ΔθzχP1,∑i∈IπiσiεiP2⋅eP1,P2μ2χH1w=e∑z∈ΔIz,∑i∈IπiT2,i⋅I2.Based on PBFT, if not less than2/3 consensus users verify the new block, following the basic setting of 2/3, 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 R′∈0,Nc−1 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 Figure4.Figure 4
Stackelberg game-based optimal pricing mechanism.


#### 5.2.1. Stackelberg Game Problem Formulation

The number of data owners isM. A set of data owners can be expressed by M˜=1,…,M. 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 j∈M determines the optimal price for corresponding data. The access amount of the data requester from data owner j is xj. The unit price of data owner j for the data requester is pj. We denote the access amount set and the optimal access amount set of the data requester from different data owners as Xj=x1,…,xM and Xj∗=x1∗,…,xM∗, respectively. The unit price set and the optimal price set of the data requester from different data owners are denoted as Pj=p1,…,pM and Pj∗p1∗,…,pM∗, respectively. The main symbols used in an optimal pricing mechanism are shown in Table 2.Table 2
Notation table of the pricing mechanism.
NotationDescriptionM^The set of data ownersMThe amount of data ownersxjThe amount of accessed dataxmaxThe largest amount of accessed dataxminThe minimum amount of accessed dataxj∗The optimal amount of accessed dataXj∗The optimal amount set of accessed dataajThe accessing willingness of the data requestersjThe data owner’s reputation scorefjThe small fees as rewardscjThe cost of assessed data of data ownerj.pjThe unit price set by data ownerj.pmaxThe maximum accepted price set by the data requesterpj∗The optimal price set by data ownerj.Pj∗The set of optimal priceTo evaluate the access quality of data, an access quality factor is denoted byq. Data owner j provides data’s quality, formulated as follows:(4)Qxj=qln1+xj.The data requester’s utility is expressed as follows:(5)Urxj,pj=fjajQxj−xjpj=qfjajln1+xj−xjpj.The data requester gives a feedback evaluation to the data of the data ownerj and obtains small fees as rewards, denoted as fj. aj is the accessing willingness of the data requester. The data requester maximizes its utility based on the access quantity xj, forming its subgame, which is given as follows.Problem 1 (data requester’s subgame for data ownerj):(6)maxxjUrxj,pj,s.t.xj∈xmin,xmax,∀j∈M.xmin is the minimum amount of accessed data, and xmax is the largest amount of accessed data.Data owner’s utility can be expressed as follows:(7)Ujxj,pj=sjxjpj−xjcj.Here,cj represents the unit cost set by data owner j. The data owner’s reputation score is expressed as sj, which changes dynamically according to the data requester feedback on the data owner’s data and amount of files downloaded by the data requester. sj∈smin,smax. The terms smin and smax are lower and upper bound reputation scores, respectively. smin<sbad<sinit<sgood<smax. sbad is the bad reputation score threshold. sinit is the initial reputation score threshold. sgood is the good reputation score threshold. The data owner j maximizes its utility based on the price pj, forming its subgame, which is given as follows.Problem 2 (data owner’s subgame for the data requester):(8)maxpjUjxj,pj,s.t.pj∈cj,pmax,∀j∈M.The data requester can accept the maximum price, denoted aspmax. 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 pointsxj∗,pj∗ are an equilibrium if it satisfies both the following two conditions:(9)Urxj∗,pj∗>Urxj∗,pj,∀j∈M,(10)Ujxj∗,pj∗>Ujxj,pj∗,∀j∈M.
To analyze the Stackelberg game, we use backward induction [28].


#### 5.2.2. Data Requesters’ Accessing Strategy in Stage II

Data ownerj provides data’s unit price for the data requester (i.e., pj, for all j∈M). The data requester from data owner decides its optimal access strategy (i.e., xj, for all j∈M).First, we take the derivative on the data requester’s utility in (5) according to xj, which is expressed as follows:(11)∂Ur∂xjt=∂fjajqln1+xj−xjpj∂xj=fjajq1+xj−pj,(12)∂2Ur∂xj2=∂fjajq/1+xj−pj∂xj=−fjajq1+xj<0.Urxj,pj is a strictly concave function shown by the above derivatives. To obtain the optimal response function, we set ∂Ur/∂xj=0, which is given as follows:(13)∂Ur∂xj=fjajq1+xj−pj=0.Then,(14)xj∗=fjajqpj−1.According to (14), xj∗ 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:(15)Ujxj∗,pj=sjxjpj−xjcj=sjfjajq+sjcj−sjpj+sjfjajqcjpj.First, we take the derivative on data owner’s utility in (15) according to pj, which is expressed as follows:(16)∂Uj∂pj=∂sjfjajq+sjcj−sjpj+sjfjajqcj/pj∂pj=sjfjajqcjpj2−sj,(17)∂2Uj∂pj2=∂sjfjajqcj/pj2−sj∂pj=−2sjfjajqcjpj3<0.Ujxj∗,pj is a strictly concave function shown by the above derivatives. To obtain the optimal response function, we set ∂Uj/∂pj=0, which is given as follows:(18)∂Uj∂pj=sjfjajqcjpj2−sj=0.Then,(19)pj∗=fjajqcj.According to (19), when fj, aj, q, and cj 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:(20)Ujxj∗,pj∗=sjxj∗pj∗−sjxj∗cj=fjajq−cj2sj.According to (5)–(19), we are able to get the optimal utility of the data requester from data owner j, given as follows:(21)Urxj∗,pj∗=fjqajln1+xj∗−xj∗pj∗=fjqajlnfjajqcj−fjajq+fjajqcj.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 Algorithm3.KeywordCiphertext (CW): This function is called to store keyword ciphertext in blockchain. Before storing the data in blockchain, the DO sends the keyword with k 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.Algorithm 3: Smart Contract Algorithm.
Input: the keyword array Keyword, the pricing’s array pricing(1)
functionKeywordciphertext (CW) public returns()(2)
keyword.pushCW.(3)
returnresult(4)
end function(5)
functionPricing(Pricinglist,pricing) public(6)
query the correspondingcw.(7)
if the query is ok then(8)
Pricinglist.pushprice.(9)
else(10)
returnfalse(11)
end if(12)
returnresult.(13)
end function(14)
function SETFEE(Paymentstruct,payemnt) only DO public(15)
query the corresponding pricing result(16)
if the query is ok then(17)
paymentstruct.pushpayment(18)
else(19)
returnfalse.(20)
end if(21)
returnresult.(22)
end function(23)
function PAYMENT (DRandDRAccount,payment) returns()(24)
compute the DO feeDOFee and the DR fee DRFee(25)
query the balance of DR’s account(26)
ifDRBalance>DOFee+DRFeethen(27)
transfer fee to DO’s account and DR’s account(28)
returnresult.(29)
else(30)
returnfalse.(31)
end if(32)
end function


## 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 Figure2.Figure 2
Proposed protocol.


### 5.1.1. Phase1: System Setup

Given a security parameterλ, the AA selects a bilinear map [40] e:G1×G2⟶GT, where G1 and G2 are two additive cyclic groups of the same prime order q. GT is a multiplicative cyclic group of prime order q. P1 is the generator of G1, and P2 is the generator of G2. AA chooses a hash function H1, where H1:0,1⟶Zq∗. In addition, the AA randomly chooses μ1, μ2, and θi∈Zq∗, g=e^P1,P2μ2. In the system, it defines the attribute space as U∧. Let m be the number of bits in a bloom filter (BF) and k be the amount of hash functions in a BF. The AA selects U=U^ random group elements h1,h2,…,hU∈G1. It generates k hash functions H1′,H2′,…,Hk′, which are used to add an element into corresponding positions in a BF. The master public key MPK=H1,e^,g,P1,P2,μ1P1,μ2P2,θiP1,θiP2,h1,h2,…,hU,H1′,H2′,…,Hk′, and the master secret key MSK=μ1,μ2,θi.The AA generates a secret key when a requester registers at the AA. There is an LSSS access structureN,ρ for the requester, where N is an l×n matrix and Tr is a set of diverse attributes in N. It means Tr=b:∃i∈1,l,ρi=b, and ∀b∈Tr/ρi. The function ρ makes a row of matrix N map to attributes. It chooses a random vector v⟶∈Zq∗. This vector’s values will be used to share μ1. For 1≤i≤l, it computes λi=v⟶Ni, where Ni is ith row of N. Furthermore, it chooses σ1,…,σl∈Zq∗ and computes Ai=λP2+θρiσiP2, Bi=σiP2, ∀b∈Tr/ρi, and Ei,b=θbσiP2. Let the private key be ak=Ai,Bi,Ei,b.


### 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 Figure3. Assume that the number of all consensus users is Nc in the blockchain network. The system generates a random number as the index of the consensus users to be the selected as the miner.Figure 3
Consensus process.Secondly, an edge node selects a random valueχ∈Zq∗. He/she computes the keyword ciphertext cw=I1,Iz,I2, where I1=χP1, Iz=θzχP1, z∈Att, and I2=gH1wχ. Then, the miner sends cw 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 W according to Algorithm 1. If w∈W, it returns 1, otherwise it returns 0. The bloom filter is used to verify the authenticity of keywords, shown in Algorithm 2.Algorithm 1:BuildBF (W,m,n,k,h).
Input: A keywords set W, an array of length m, n keywords, k hash functions H=H1′,H2′,…,Hk′.Output: Bloom Filter BF.(1)BF= a new m- bits array of n elements(2)fori=1 to m do(3)BFi= NULL(4)for each element w∈W do(5)fori=1 to k do(6)j=Hi′w.(7)ifBFj== NULL(8)BFj=1.(9)returnBF.Algorithm 2: VerifyBF (ADO, Hcw).
Input: A keyword w, symmetric key sk, k hash functions, EncskH=EncskH1′w,H2′w,…,Hk′w.Output:ifw∈W, return 1, else return 0(1)for each element w.(2)fori=1 to k do(3)cj=EncskHj′w.(4)j=Decskcj.(5)if each BFj==1.(6)return 1(7)else return 0


### 5.1.3. Phase 3: Profile Matching

Keyword search. The DR searches desired data using the DR’s private key ak to generate a keyword trapdoor Tw in blockchain. The trapdoor Tw=T1,i,T2,i,T3,i,b is generated as follows.Choose a random vectorV⟶=μ,γ1,…,γl, where random number γ1,…,γl∈Zq∗. This vector’s values will be used to share μ.For1≤i≤l, it computes ηi=V⟶⋅Ni. It chooses ε1,…,εl∈Zq∗ and computes T1,i=ηiH1WP2+θiσiεiP2, T2,i=εiBi, ∀b∈T/ρi, and T3,i,b=εiEi,b, where T is a set of distinct attributes in N for 1≤i≤l. Then, DR sends Tw=T1,i,T2,i,T3,i,b to blockchain.Test. Assume that attributes Att associated with cw satisfy N,ρ. There exists i∈I,πi∈Zq∗ such that ∑i∈IπiNi=1,0,…0, where Ni is ith row of N. Given an original ciphertext cw, a keyword w, and a search token Tw, the following equation is verified:(2)eI1,∑i∈IπiT1,i+∑z∈Δ/ρiT3,i,z=?e∑z∈ΔIz,∑i∈IπiT2,i⋅I2.If (2) holds, the matching keyword w′ 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:(3)eI1,∑i∈IT1,i∑z∈Δ/ρiT3,i,zπi=eχP1,∑i∈IπiηiH1wP2+θiσεP2+∑z∈Δ/ρiεiEi,z=eχP1,∑i∈IπiV⟶⋅MiH1wP2eχP1,∑i∈IπiθiσiεiP2+∑z∈Δ/ρiεiθzσiP2=eχP1,μ1H1wP2eχP1,∑i∈Iπi∑z∈ΔεiθzσiP2e∑z∈ΔIz,∑i∈IπiT2,i⋅I2=e∑z∈ΔθzχP1,∑i∈IπiσiεiP2⋅eP1,P2μ2χH1w=e∑z∈ΔIz,∑i∈IπiT2,i⋅I2.Based on PBFT, if not less than2/3 consensus users verify the new block, following the basic setting of 2/3, 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 R′∈0,Nc−1 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.1.1. Phase1: System Setup

Given a security parameterλ, the AA selects a bilinear map [40] e:G1×G2⟶GT, where G1 and G2 are two additive cyclic groups of the same prime order q. GT is a multiplicative cyclic group of prime order q. P1 is the generator of G1, and P2 is the generator of G2. AA chooses a hash function H1, where H1:0,1⟶Zq∗. In addition, the AA randomly chooses μ1, μ2, and θi∈Zq∗, g=e^P1,P2μ2. In the system, it defines the attribute space as U∧. Let m be the number of bits in a bloom filter (BF) and k be the amount of hash functions in a BF. The AA selects U=U^ random group elements h1,h2,…,hU∈G1. It generates k hash functions H1′,H2′,…,Hk′, which are used to add an element into corresponding positions in a BF. The master public key MPK=H1,e^,g,P1,P2,μ1P1,μ2P2,θiP1,θiP2,h1,h2,…,hU,H1′,H2′,…,Hk′, and the master secret key MSK=μ1,μ2,θi.The AA generates a secret key when a requester registers at the AA. There is an LSSS access structureN,ρ for the requester, where N is an l×n matrix and Tr is a set of diverse attributes in N. It means Tr=b:∃i∈1,l,ρi=b, and ∀b∈Tr/ρi. The function ρ makes a row of matrix N map to attributes. It chooses a random vector v⟶∈Zq∗. This vector’s values will be used to share μ1. For 1≤i≤l, it computes λi=v⟶Ni, where Ni is ith row of N. Furthermore, it chooses σ1,…,σl∈Zq∗ and computes Ai=λP2+θρiσiP2, Bi=σiP2, ∀b∈Tr/ρi, and Ei,b=θbσiP2. Let the private key be ak=Ai,Bi,Ei,b.


## 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 Figure3. Assume that the number of all consensus users is Nc in the blockchain network. The system generates a random number as the index of the consensus users to be the selected as the miner.Figure 3
Consensus process.Secondly, an edge node selects a random valueχ∈Zq∗. He/she computes the keyword ciphertext cw=I1,Iz,I2, where I1=χP1, Iz=θzχP1, z∈Att, and I2=gH1wχ. Then, the miner sends cw 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 W according to Algorithm 1. If w∈W, it returns 1, otherwise it returns 0. The bloom filter is used to verify the authenticity of keywords, shown in Algorithm 2.Algorithm 1:BuildBF (W,m,n,k,h).
Input: A keywords set W, an array of length m, n keywords, k hash functions H=H1′,H2′,…,Hk′.Output: Bloom Filter BF.(1)BF= a new m- bits array of n elements(2)fori=1 to m do(3)BFi= NULL(4)for each element w∈W do(5)fori=1 to k do(6)j=Hi′w.(7)ifBFj== NULL(8)BFj=1.(9)returnBF.Algorithm 2: VerifyBF (ADO, Hcw).
Input: A keyword w, symmetric key sk, k hash functions, EncskH=EncskH1′w,H2′w,…,Hk′w.Output:ifw∈W, return 1, else return 0(1)for each element w.(2)fori=1 to k do(3)cj=EncskHj′w.(4)j=Decskcj.(5)if each BFj==1.(6)return 1(7)else return 0


## 5.1.3. Phase 3: Profile Matching

Keyword search. The DR searches desired data using the DR’s private key ak to generate a keyword trapdoor Tw in blockchain. The trapdoor Tw=T1,i,T2,i,T3,i,b is generated as follows.Choose a random vectorV⟶=μ,γ1,…,γl, where random number γ1,…,γl∈Zq∗. This vector’s values will be used to share μ.For1≤i≤l, it computes ηi=V⟶⋅Ni. It chooses ε1,…,εl∈Zq∗ and computes T1,i=ηiH1WP2+θiσiεiP2, T2,i=εiBi, ∀b∈T/ρi, and T3,i,b=εiEi,b, where T is a set of distinct attributes in N for 1≤i≤l. Then, DR sends Tw=T1,i,T2,i,T3,i,b to blockchain.Test. Assume that attributes Att associated with cw satisfy N,ρ. There exists i∈I,πi∈Zq∗ such that ∑i∈IπiNi=1,0,…0, where Ni is ith row of N. Given an original ciphertext cw, a keyword w, and a search token Tw, the following equation is verified:(2)eI1,∑i∈IπiT1,i+∑z∈Δ/ρiT3,i,z=?e∑z∈ΔIz,∑i∈IπiT2,i⋅I2.If (2) holds, the matching keyword w′ 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:(3)eI1,∑i∈IT1,i∑z∈Δ/ρiT3,i,zπi=eχP1,∑i∈IπiηiH1wP2+θiσεP2+∑z∈Δ/ρiεiEi,z=eχP1,∑i∈IπiV⟶⋅MiH1wP2eχP1,∑i∈IπiθiσiεiP2+∑z∈Δ/ρiεiθzσiP2=eχP1,μ1H1wP2eχP1,∑i∈Iπi∑z∈ΔεiθzσiP2e∑z∈ΔIz,∑i∈IπiT2,i⋅I2=e∑z∈ΔθzχP1,∑i∈IπiσiεiP2⋅eP1,P2μ2χH1w=e∑z∈ΔIz,∑i∈IπiT2,i⋅I2.Based on PBFT, if not less than2/3 consensus users verify the new block, following the basic setting of 2/3, 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 R′∈0,Nc−1 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 Figure4.Figure 4
Stackelberg game-based optimal pricing mechanism.


### 5.2.1. Stackelberg Game Problem Formulation

The number of data owners isM. A set of data owners can be expressed by M˜=1,…,M. 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 j∈M determines the optimal price for corresponding data. The access amount of the data requester from data owner j is xj. The unit price of data owner j for the data requester is pj. We denote the access amount set and the optimal access amount set of the data requester from different data owners as Xj=x1,…,xM and Xj∗=x1∗,…,xM∗, respectively. The unit price set and the optimal price set of the data requester from different data owners are denoted as Pj=p1,…,pM and Pj∗p1∗,…,pM∗, respectively. The main symbols used in an optimal pricing mechanism are shown in Table 2.Table 2
Notation table of the pricing mechanism.
NotationDescriptionM^The set of data ownersMThe amount of data ownersxjThe amount of accessed dataxmaxThe largest amount of accessed dataxminThe minimum amount of accessed dataxj∗The optimal amount of accessed dataXj∗The optimal amount set of accessed dataajThe accessing willingness of the data requestersjThe data owner’s reputation scorefjThe small fees as rewardscjThe cost of assessed data of data ownerj.pjThe unit price set by data ownerj.pmaxThe maximum accepted price set by the data requesterpj∗The optimal price set by data ownerj.Pj∗The set of optimal priceTo evaluate the access quality of data, an access quality factor is denoted byq. Data owner j provides data’s quality, formulated as follows:(4)Qxj=qln1+xj.The data requester’s utility is expressed as follows:(5)Urxj,pj=fjajQxj−xjpj=qfjajln1+xj−xjpj.The data requester gives a feedback evaluation to the data of the data ownerj and obtains small fees as rewards, denoted as fj. aj is the accessing willingness of the data requester. The data requester maximizes its utility based on the access quantity xj, forming its subgame, which is given as follows.Problem 1 (data requester’s subgame for data ownerj):(6)maxxjUrxj,pj,s.t.xj∈xmin,xmax,∀j∈M.xmin is the minimum amount of accessed data, and xmax is the largest amount of accessed data.Data owner’s utility can be expressed as follows:(7)Ujxj,pj=sjxjpj−xjcj.Here,cj represents the unit cost set by data owner j. The data owner’s reputation score is expressed as sj, which changes dynamically according to the data requester feedback on the data owner’s data and amount of files downloaded by the data requester. sj∈smin,smax. The terms smin and smax are lower and upper bound reputation scores, respectively. smin<sbad<sinit<sgood<smax. sbad is the bad reputation score threshold. sinit is the initial reputation score threshold. sgood is the good reputation score threshold. The data owner j maximizes its utility based on the price pj, forming its subgame, which is given as follows.Problem 2 (data owner’s subgame for the data requester):(8)maxpjUjxj,pj,s.t.pj∈cj,pmax,∀j∈M.The data requester can accept the maximum price, denoted aspmax. 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 pointsxj∗,pj∗ are an equilibrium if it satisfies both the following two conditions:(9)Urxj∗,pj∗>Urxj∗,pj,∀j∈M,(10)Ujxj∗,pj∗>Ujxj,pj∗,∀j∈M.
To analyze the Stackelberg game, we use backward induction [28].


### 5.2.2. Data Requesters’ Accessing Strategy in Stage II

Data ownerj provides data’s unit price for the data requester (i.e., pj, for all j∈M). The data requester from data owner decides its optimal access strategy (i.e., xj, for all j∈M).First, we take the derivative on the data requester’s utility in (5) according to xj, which is expressed as follows:(11)∂Ur∂xjt=∂fjajqln1+xj−xjpj∂xj=fjajq1+xj−pj,(12)∂2Ur∂xj2=∂fjajq/1+xj−pj∂xj=−fjajq1+xj<0.Urxj,pj is a strictly concave function shown by the above derivatives. To obtain the optimal response function, we set ∂Ur/∂xj=0, which is given as follows:(13)∂Ur∂xj=fjajq1+xj−pj=0.Then,(14)xj∗=fjajqpj−1.According to (14), xj∗ 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:(15)Ujxj∗,pj=sjxjpj−xjcj=sjfjajq+sjcj−sjpj+sjfjajqcjpj.First, we take the derivative on data owner’s utility in (15) according to pj, which is expressed as follows:(16)∂Uj∂pj=∂sjfjajq+sjcj−sjpj+sjfjajqcj/pj∂pj=sjfjajqcjpj2−sj,(17)∂2Uj∂pj2=∂sjfjajqcj/pj2−sj∂pj=−2sjfjajqcjpj3<0.Ujxj∗,pj is a strictly concave function shown by the above derivatives. To obtain the optimal response function, we set ∂Uj/∂pj=0, which is given as follows:(18)∂Uj∂pj=sjfjajqcjpj2−sj=0.Then,(19)pj∗=fjajqcj.According to (19), when fj, aj, q, and cj 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:(20)Ujxj∗,pj∗=sjxj∗pj∗−sjxj∗cj=fjajq−cj2sj.According to (5)–(19), we are able to get the optimal utility of the data requester from data owner j, given as follows:(21)Urxj∗,pj∗=fjqajln1+xj∗−xj∗pj∗=fjqajlnfjajqcj−fjajq+fjajqcj.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.2.1. Stackelberg Game Problem Formulation

The number of data owners isM. A set of data owners can be expressed by M˜=1,…,M. 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 j∈M determines the optimal price for corresponding data. The access amount of the data requester from data owner j is xj. The unit price of data owner j for the data requester is pj. We denote the access amount set and the optimal access amount set of the data requester from different data owners as Xj=x1,…,xM and Xj∗=x1∗,…,xM∗, respectively. The unit price set and the optimal price set of the data requester from different data owners are denoted as Pj=p1,…,pM and Pj∗p1∗,…,pM∗, respectively. The main symbols used in an optimal pricing mechanism are shown in Table 2.Table 2
Notation table of the pricing mechanism.
NotationDescriptionM^The set of data ownersMThe amount of data ownersxjThe amount of accessed dataxmaxThe largest amount of accessed dataxminThe minimum amount of accessed dataxj∗The optimal amount of accessed dataXj∗The optimal amount set of accessed dataajThe accessing willingness of the data requestersjThe data owner’s reputation scorefjThe small fees as rewardscjThe cost of assessed data of data ownerj.pjThe unit price set by data ownerj.pmaxThe maximum accepted price set by the data requesterpj∗The optimal price set by data ownerj.Pj∗The set of optimal priceTo evaluate the access quality of data, an access quality factor is denoted byq. Data owner j provides data’s quality, formulated as follows:(4)Qxj=qln1+xj.The data requester’s utility is expressed as follows:(5)Urxj,pj=fjajQxj−xjpj=qfjajln1+xj−xjpj.The data requester gives a feedback evaluation to the data of the data ownerj and obtains small fees as rewards, denoted as fj. aj is the accessing willingness of the data requester. The data requester maximizes its utility based on the access quantity xj, forming its subgame, which is given as follows.Problem 1 (data requester’s subgame for data ownerj):(6)maxxjUrxj,pj,s.t.xj∈xmin,xmax,∀j∈M.xmin is the minimum amount of accessed data, and xmax is the largest amount of accessed data.Data owner’s utility can be expressed as follows:(7)Ujxj,pj=sjxjpj−xjcj.Here,cj represents the unit cost set by data owner j. The data owner’s reputation score is expressed as sj, which changes dynamically according to the data requester feedback on the data owner’s data and amount of files downloaded by the data requester. sj∈smin,smax. The terms smin and smax are lower and upper bound reputation scores, respectively. smin<sbad<sinit<sgood<smax. sbad is the bad reputation score threshold. sinit is the initial reputation score threshold. sgood is the good reputation score threshold. The data owner j maximizes its utility based on the price pj, forming its subgame, which is given as follows.Problem 2 (data owner’s subgame for the data requester):(8)maxpjUjxj,pj,s.t.pj∈cj,pmax,∀j∈M.The data requester can accept the maximum price, denoted aspmax. 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 pointsxj∗,pj∗ are an equilibrium if it satisfies both the following two conditions:(9)Urxj∗,pj∗>Urxj∗,pj,∀j∈M,(10)Ujxj∗,pj∗>Ujxj,pj∗,∀j∈M.
To analyze the Stackelberg game, we use backward induction [28].


## 5.2.2. Data Requesters’ Accessing Strategy in Stage II

Data ownerj provides data’s unit price for the data requester (i.e., pj, for all j∈M). The data requester from data owner decides its optimal access strategy (i.e., xj, for all j∈M).First, we take the derivative on the data requester’s utility in (5) according to xj, which is expressed as follows:(11)∂Ur∂xjt=∂fjajqln1+xj−xjpj∂xj=fjajq1+xj−pj,(12)∂2Ur∂xj2=∂fjajq/1+xj−pj∂xj=−fjajq1+xj<0.Urxj,pj is a strictly concave function shown by the above derivatives. To obtain the optimal response function, we set ∂Ur/∂xj=0, which is given as follows:(13)∂Ur∂xj=fjajq1+xj−pj=0.Then,(14)xj∗=fjajqpj−1.According to (14), xj∗ 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:(15)Ujxj∗,pj=sjxjpj−xjcj=sjfjajq+sjcj−sjpj+sjfjajqcjpj.First, we take the derivative on data owner’s utility in (15) according to pj, which is expressed as follows:(16)∂Uj∂pj=∂sjfjajq+sjcj−sjpj+sjfjajqcj/pj∂pj=sjfjajqcjpj2−sj,(17)∂2Uj∂pj2=∂sjfjajqcj/pj2−sj∂pj=−2sjfjajqcjpj3<0.Ujxj∗,pj is a strictly concave function shown by the above derivatives. To obtain the optimal response function, we set ∂Uj/∂pj=0, which is given as follows:(18)∂Uj∂pj=sjfjajqcjpj2−sj=0.Then,(19)pj∗=fjajqcj.According to (19), when fj, aj, q, and cj 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:(20)Ujxj∗,pj∗=sjxj∗pj∗−sjxj∗cj=fjajq−cj2sj.According to (5)–(19), we are able to get the optimal utility of the data requester from data owner j, given as follows:(21)Urxj∗,pj∗=fjqajln1+xj∗−xj∗pj∗=fjqajlnfjajqcj−fjajq+fjajqcj.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 Algorithm3.KeywordCiphertext (CW): This function is called to store keyword ciphertext in blockchain. Before storing the data in blockchain, the DO sends the keyword with k 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.Algorithm 3: Smart Contract Algorithm.
Input: the keyword array Keyword, the pricing’s array pricing(1)
functionKeywordciphertext (CW) public returns()(2)
keyword.pushCW.(3)
returnresult(4)
end function(5)
functionPricing(Pricinglist,pricing) public(6)
query the correspondingcw.(7)
if the query is ok then(8)
Pricinglist.pushprice.(9)
else(10)
returnfalse(11)
end if(12)
returnresult.(13)
end function(14)
function SETFEE(Paymentstruct,payemnt) only DO public(15)
query the corresponding pricing result(16)
if the query is ok then(17)
paymentstruct.pushpayment(18)
else(19)
returnfalse.(20)
end if(21)
returnresult.(22)
end function(23)
function PAYMENT (DRandDRAccount,payment) returns()(24)
compute the DO feeDOFee and the DR fee DRFee(25)
query the balance of DR’s account(26)
ifDRBalance>DOFee+DRFeethen(27)
transfer fee to DO’s account and DR’s account(28)
returnresult.(29)
else(30)
returnfalse.(31)
end if(32)
end function


## 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 adversaryA 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 algorithmsPrivate key, Trapdoor, and Test are Oak, Otrapdoor, and Otest, respectively. Assume that A is an attacker who has advantage ε to attack the proposed chosen keyword attack game. We build a challenger C. He/she plays game with A to derive the solution to the DBDH problem as follows:Listaklist: record N,ρ,akN,ρ.


#### 6.2.1. Setup

Given a security parameterλ and an input tuple r1P1,r2P1,r3P1, challenger C generates the system master public key MPK=H1,e^,g,P1,P2,μ1P1,μ1P2,θiP1,θiP2,H1 and the master secret key MSK=μ1,μ2,θi.(a)
H1w: if the query exists on H1list1 in a tuple w,κ1, κ1 is returned; else, κ1∈RZq∗ is chosen, w,κ1 is added to H1list1, and H1w=κ1 is returned(b)
H1I1,I2,Izz∈Att: if the query exists on H1list2 in a tuple I1,I2,Izz∈Att,κ2, κ2 is returned; else, κ2∈RZq∗ is chosen, I1,I2,Izz∈Att,κ2 is added to H1list2, and H1I1,I2,Izz∈Att=κ2 is returned


#### 6.2.2. Phase 1

(a)
OakN,ρ: Since challenger C has knowledge of μ1 and θρi, it can construct private key corresponding to any N,ρ, and next, the tuple is added to aklist. When N,ρ satisfies Att∗, ⊥ is output.(b)
OtrapdoorN,ρ,w: If N,ρ matches Att∗, challenger C outputs ⊥. Else, C can set T2,i,T3,i,b as in Oak. C chooses a random vector V⟶ with the first element μ and next sets ηi=V⟶⋅Ni. It chooses ε1,…,εl∈Zq∗ and constructs the trapdoor Tw as in the real scheme.(c)
OtestN,ρ,w: If the attribute set Att associated with cw is Att∗, C outputs ⊥. Else, C can always compute a trapdoor Tw as in Otrapdoor. Then, it proceeds to the test easily. If the test holds, C outputs 1 and 0 otherwise.


#### 6.2.3. Challenge

A outputs w1∗ and w0∗. Challenger C sets the original challenge ciphertext as follows:(a)
I1∗=r1P1, Iz∗=r1r2P1, and I2∗=gH1wr3 are set.(b)
A random coinb∈0,1 is flipped, and an H1 query on wb∗ is issued to achieve κ1∗.(c)
AnH1 query on H1I1∗,I2∗,Iz∗z∈Att∗ is issued to achieve κ2∗.(d)
The challenge original ciphertext is output ascw∗=Att∗,I1∗,I2∗,\\Iz∗z∈Att∗.(e)
IfQ=r1r2r3P1∈G1, then cw∗ generated a valid ciphertext in which r1′=r1 and r2′=r2r3. After that, C sends cw∗,Tw∗ to A.


#### 6.2.4. Phase 2

The phase is the same as thePhase 1.


#### 6.2.5. Guess

A outputs a guess bit b′, if b=b′, and C outputs 1; else, it outputs 0.In the guess phase, ifQ≠r1r2r3P1, then we have the following:(22)PrAP1,r1P1,r2P1,r3P1,Q=1=12.In addition,(23)PrAP1,r1P1,r2P1,r3P1,Q=1=PrAP1,r1P1,r2P1,r3P1,Q=1|AwinsPrAwins+PrAP1,r1P1,r2P1,r3P1,Q=1|Awins¯PrAwins¯=1⋅ε″λ+121−ε″λ=ε″λ2+12.Consequently,(24)AdvADBDHλ=ε″λ2=ε′.Thus, the probability ofA 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 keywordw is encrypted by the DO’s attribute set Att. The DR uses his/her key ak to generate a search trapdoor Tw, which is related to the access structure. It is used for searching the matching keyword. Only when the attribute Att of keyword ciphertext cw satisfies the access structure of search trapdoor Tw, 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.


## 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 adversaryA 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 algorithmsPrivate key, Trapdoor, and Test are Oak, Otrapdoor, and Otest, respectively. Assume that A is an attacker who has advantage ε to attack the proposed chosen keyword attack game. We build a challenger C. He/she plays game with A to derive the solution to the DBDH problem as follows:Listaklist: record N,ρ,akN,ρ.


### 6.2.1. Setup

Given a security parameterλ and an input tuple r1P1,r2P1,r3P1, challenger C generates the system master public key MPK=H1,e^,g,P1,P2,μ1P1,μ1P2,θiP1,θiP2,H1 and the master secret key MSK=μ1,μ2,θi.(a)
H1w: if the query exists on H1list1 in a tuple w,κ1, κ1 is returned; else, κ1∈RZq∗ is chosen, w,κ1 is added to H1list1, and H1w=κ1 is returned(b)
H1I1,I2,Izz∈Att: if the query exists on H1list2 in a tuple I1,I2,Izz∈Att,κ2, κ2 is returned; else, κ2∈RZq∗ is chosen, I1,I2,Izz∈Att,κ2 is added to H1list2, and H1I1,I2,Izz∈Att=κ2 is returned


### 6.2.2. Phase 1

(a)
OakN,ρ: Since challenger C has knowledge of μ1 and θρi, it can construct private key corresponding to any N,ρ, and next, the tuple is added to aklist. When N,ρ satisfies Att∗, ⊥ is output.(b)
OtrapdoorN,ρ,w: If N,ρ matches Att∗, challenger C outputs ⊥. Else, C can set T2,i,T3,i,b as in Oak. C chooses a random vector V⟶ with the first element μ and next sets ηi=V⟶⋅Ni. It chooses ε1,…,εl∈Zq∗ and constructs the trapdoor Tw as in the real scheme.(c)
OtestN,ρ,w: If the attribute set Att associated with cw is Att∗, C outputs ⊥. Else, C can always compute a trapdoor Tw as in Otrapdoor. Then, it proceeds to the test easily. If the test holds, C outputs 1 and 0 otherwise.


### 6.2.3. Challenge

A outputs w1∗ and w0∗. Challenger C sets the original challenge ciphertext as follows:(a)
I1∗=r1P1, Iz∗=r1r2P1, and I2∗=gH1wr3 are set.(b)
A random coinb∈0,1 is flipped, and an H1 query on wb∗ is issued to achieve κ1∗.(c)
AnH1 query on H1I1∗,I2∗,Iz∗z∈Att∗ is issued to achieve κ2∗.(d)
The challenge original ciphertext is output ascw∗=Att∗,I1∗,I2∗,\\Iz∗z∈Att∗.(e)
IfQ=r1r2r3P1∈G1, then cw∗ generated a valid ciphertext in which r1′=r1 and r2′=r2r3. After that, C sends cw∗,Tw∗ to A.


### 6.2.4. Phase 2

The phase is the same as thePhase 1.


### 6.2.5. Guess

A outputs a guess bit b′, if b=b′, and C outputs 1; else, it outputs 0.In the guess phase, ifQ≠r1r2r3P1, then we have the following:(22)PrAP1,r1P1,r2P1,r3P1,Q=1=12.In addition,(23)PrAP1,r1P1,r2P1,r3P1,Q=1=PrAP1,r1P1,r2P1,r3P1,Q=1|AwinsPrAwins+PrAP1,r1P1,r2P1,r3P1,Q=1|Awins¯PrAwins¯=1⋅ε″λ+121−ε″λ=ε″λ2+12.Consequently,(24)AdvADBDHλ=ε″λ2=ε′.Thus, the probability ofA wining the keyword secrecy game is ε′ at least.


## 6.2.1. Setup

Given a security parameterλ and an input tuple r1P1,r2P1,r3P1, challenger C generates the system master public key MPK=H1,e^,g,P1,P2,μ1P1,μ1P2,θiP1,θiP2,H1 and the master secret key MSK=μ1,μ2,θi.(a)
H1w: if the query exists on H1list1 in a tuple w,κ1, κ1 is returned; else, κ1∈RZq∗ is chosen, w,κ1 is added to H1list1, and H1w=κ1 is returned(b)
H1I1,I2,Izz∈Att: if the query exists on H1list2 in a tuple I1,I2,Izz∈Att,κ2, κ2 is returned; else, κ2∈RZq∗ is chosen, I1,I2,Izz∈Att,κ2 is added to H1list2, and H1I1,I2,Izz∈Att=κ2 is returned


## 6.2.2. Phase 1

(a)
OakN,ρ: Since challenger C has knowledge of μ1 and θρi, it can construct private key corresponding to any N,ρ, and next, the tuple is added to aklist. When N,ρ satisfies Att∗, ⊥ is output.(b)
OtrapdoorN,ρ,w: If N,ρ matches Att∗, challenger C outputs ⊥. Else, C can set T2,i,T3,i,b as in Oak. C chooses a random vector V⟶ with the first element μ and next sets ηi=V⟶⋅Ni. It chooses ε1,…,εl∈Zq∗ and constructs the trapdoor Tw as in the real scheme.(c)
OtestN,ρ,w: If the attribute set Att associated with cw is Att∗, C outputs ⊥. Else, C can always compute a trapdoor Tw as in Otrapdoor. Then, it proceeds to the test easily. If the test holds, C outputs 1 and 0 otherwise.


## 6.2.3. Challenge

A outputs w1∗ and w0∗. Challenger C sets the original challenge ciphertext as follows:(a)
I1∗=r1P1, Iz∗=r1r2P1, and I2∗=gH1wr3 are set.(b)
A random coinb∈0,1 is flipped, and an H1 query on wb∗ is issued to achieve κ1∗.(c)
AnH1 query on H1I1∗,I2∗,Iz∗z∈Att∗ is issued to achieve κ2∗.(d)
The challenge original ciphertext is output ascw∗=Att∗,I1∗,I2∗,\\Iz∗z∈Att∗.(e)
IfQ=r1r2r3P1∈G1, then cw∗ generated a valid ciphertext in which r1′=r1 and r2′=r2r3. After that, C sends cw∗,Tw∗ to A.


## 6.2.4. Phase 2

The phase is the same as thePhase 1.


## 6.2.5. Guess

A outputs a guess bit b′, if b=b′, and C outputs 1; else, it outputs 0.In the guess phase, ifQ≠r1r2r3P1, then we have the following:(22)PrAP1,r1P1,r2P1,r3P1,Q=1=12.In addition,(23)PrAP1,r1P1,r2P1,r3P1,Q=1=PrAP1,r1P1,r2P1,r3P1,Q=1|AwinsPrAwins+PrAP1,r1P1,r2P1,r3P1,Q=1|Awins¯PrAwins¯=1⋅ε″λ+121−ε″λ=ε″λ2+12.Consequently,(24)AdvADBDHλ=ε″λ2=ε′.Thus, the probability ofA 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 keywordw is encrypted by the DO’s attribute set Att. The DR uses his/her key ak to generate a search trapdoor Tw, which is related to the access structure. It is used for searching the matching keyword. Only when the attribute Att of keyword ciphertext cw satisfies the access structure of search trapdoor Tw, 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λ=128. For some prime p=3mod4, we utilize type A pairing on the elliptic curve y2=x3+x over the field Fp. 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 Table3. 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.Table 3
Comparison of security properties.
Properties[25][42][43]The proposedBlockchain integration√××√Privacy preservation√√√√Secure match√××√Fairness and incentive×××√Access control√√√√√: the scheme supports this property; ×: the scheme does not support this property.


### 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 denoteG1, G2, GT, and Q as the size of elements in G1, G2, GT, and Zp. The communication overhead is caused by index generation phase and keyword search phase, shown in Table 4. In index generation phase, DO sends cw to blockchain for searching data, and the total length is n+1G1+GT bytes. The DR sends search trapdoor Tw using the secret key to blockchain for searching the desired data, and the total length is 3lG2 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.Table 4
Communication overhead of proposed protocol.
PhasesThe proposedCui et al. [42]Miao et al. [43]Index generationn+1G1+GTG1+5n+1G2n+1G+GTKeyword search3lG26l+2G+M4n+3G+QWe compare the computational overhead in Table5. 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.Table 5
Computational overhead of cryptographic algorithms (inms).
AlgorithmsSystemInitEncryptTrapdoorTestThe proposedAverage time152547523368Max time665651592376Min time23527482361Cui et al. [42]Average time232550696431Max time746618731457Min time97513672420Liu et al. [43]Average time369610626321Max time766650700367Min time263582581290


### 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 Section7.3, the length of index generation and keyword search is n+1G1+GT and 3lG2. 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.Table 6
Time consumption of transactions.
TransactionsCipheretextPricingFeedbackAverage time (ms)98.8354.8479.49Max time (ms)255469255Min time (ms)8225146Gas cost (ether)0.0146630.03544130.0103504


### 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 Figure5. We set some parameter values, denoted as follows: pmax=5, xmin=10, xmax=100, sj∈0,1, and fj∈1,5. The parameter aj represents the data requester’s willingness to access the data. When aj values are different, we simulate the utility of data owners and data requesters, where aj is equal to B 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.Figure 5
Computational cost taken by (a)aj = 20, (b) aj = 30, (c) aj = 20, and (d) aj = 30.
(a)(b)(c)(d)


## 7.1. Parameter Settings and Platform

The system security parameterλ=128. For some prime p=3mod4, we utilize type A pairing on the elliptic curve y2=x3+x over the field Fp. 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 Table3. 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.Table 3
Comparison of security properties.
Properties[25][42][43]The proposedBlockchain integration√××√Privacy preservation√√√√Secure match√××√Fairness and incentive×××√Access control√√√√√: the scheme supports this property; ×: the scheme does not support this property.


## 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 denoteG1, G2, GT, and Q as the size of elements in G1, G2, GT, and Zp. The communication overhead is caused by index generation phase and keyword search phase, shown in Table 4. In index generation phase, DO sends cw to blockchain for searching data, and the total length is n+1G1+GT bytes. The DR sends search trapdoor Tw using the secret key to blockchain for searching the desired data, and the total length is 3lG2 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.Table 4
Communication overhead of proposed protocol.
PhasesThe proposedCui et al. [42]Miao et al. [43]Index generationn+1G1+GTG1+5n+1G2n+1G+GTKeyword search3lG26l+2G+M4n+3G+QWe compare the computational overhead in Table5. 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.Table 5
Computational overhead of cryptographic algorithms (inms).
AlgorithmsSystemInitEncryptTrapdoorTestThe proposedAverage time152547523368Max time665651592376Min time23527482361Cui et al. [42]Average time232550696431Max time746618731457Min time97513672420Liu et al. [43]Average time369610626321Max time766650700367Min time263582581290


## 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 Section7.3, the length of index generation and keyword search is n+1G1+GT and 3lG2. 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.Table 6
Time consumption of transactions.
TransactionsCipheretextPricingFeedbackAverage time (ms)98.8354.8479.49Max time (ms)255469255Min time (ms)8225146Gas cost (ether)0.0146630.03544130.0103504


## 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 Figure5. We set some parameter values, denoted as follows: pmax=5, xmin=10, xmax=100, sj∈0,1, and fj∈1,5. The parameter aj represents the data requester’s willingness to access the data. When aj values are different, we simulate the utility of data owners and data requesters, where aj is equal to B 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.Figure 5
Computational cost taken by (a)aj = 20, (b) aj = 30, (c) aj = 20, and (d) aj = 30.
(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.



---

*Source: 8293716-2022-02-21.xml*