MDS²-C³PF: A Medical Data Sharing Scheme with Cloud-Chain Cooperation and Policy Fusion in IoT

Abstract

The Internet of Things (IoT) and cloud technologies have significantly facilitated healthcare. In such a context, medical data are collected by the terminals from the patients, manipulated, and stored on the cloud by hospitals (doctors). This brings asymmetry problems in medical data access control, processing, and storage between doctors and patients, which results in medical data sharing face many challenges such as privacy leakage and malicious feedback from cloud servers on queries. To solve these asymmetry problems, this paper proposes a medical data sharing scheme with cloud-chain cooperation and policy fusion in the IoT. Regarding asymmetrical access control rights, a conflict resolution and fusion algorithm that enables co-authorization of medical data by the doctor and the patient is introduced. To balance the symmetry of medical data storage and processing, a cloud-chain cooperation ciphertext retrieval method is proposed by means of two-stage joint searching from cloud servers and the blockchain, which can not only detect malicious medical data feedback from cloud servers, but also improve the data search efficiency. The security analysis showed that this scheme satisfies the confidentiality and verifiability of the retrieved information, and the feasibility of the proposed scheme was demonstrated through experiments.

1. Introduction

The massive amount of data generated by the Internet of Medical Things (IoMT) serves as an important vehicle for recording patient information for treatment and needs to be shared to advance medical information [1,2]. Because of the limited computational power and storage capacity of the terminal, medical data based on the IoMT are generally stored and processed on the cloud, where the data access and usage rights are always in the hands of medical institutions. This brings asymmetries in medical data access control, processing, and storage between doctors and patients. Specifically, patients have little control over their records, which results in privacy disclosure. Furthermore, the unbalanced structure of the terminal collection, cloud storage, and processing may cause malicious tampering or false feedback on queries from the cloud server. These problems due to asymmetry seriously impede medical data sharing.

Current research on IoMT data sharing mainly focuses on the access control of medical data and secure retrieval methods. The common method is to use Attribute-Based Encryption (ABE) [3], especially Ciphertext Policy Attribute-Based Encryption (CP-ABE) [4], access control to encrypt medical data and store them on the cloud server. Most studies based on CP-ABE to solve medical data sharing consider the access control of medical data by hospitals or patients [5,6,7]. However, medical data come from both patients and doctors. Thus, their ownership should be shared between hospitals and patients. Therefore, it is worthwhile to further study the medical data access control method with the co-authorization of doctors and patients.

Furthermore, the ciphertext retrieval of medical data is a hot research topic that addresses the security risks of the cloud. While Searchable Encryption (SE) [8] can prevent the leakage and tampering of medical records by semi-trusted cloud servers, there still remains the risk of the cloud server’s malicious feedback errors or false medical data [9,10]. Since these solutions do not break the centralized imbalanced structure, it is difficult to fundamentally solve the secure storage and processing problems of medical data sharing. Blockchain is open, transparent, tamperproof, and traceable, which can provide a solution to this problem [11]. The existing methods mainly use blockchain to record the query information [12,13,14] or ensure the correctness of the retrieved results by performing ciphertext medical data searching on the blockchain [15]. However, due to blockchain’s special structure and storage limitations, the blockchain ciphertext retrieval efficiency is much lower than cloud services. Although blockchain breaks the asymmetric structure of cloud-based medical data’s centralized storage and processing, it raises efficiency problems and other issues.

To solve the above two asymmetric problems that impede medical data sharing, a Medical Data Sharing Scheme with Cloud-Chain Cooperation and Policy Fusion in the IoT ($MD{S}^2-C^{3}PF$) is proposed. The scheme makes use of cloud-chain cooperation to effectively balance the medical data sharing access control between doctors and patients and resist some of the security risks such as malicious feedback and privacy disclosure caused by the centralized asymmetric structure of cloud data processing.

The main contributions of this article are as follows:

• A multi-stage system model is proposed. The access control right of medical data between doctors and patients becomes symmetric through their co-authorization. A symmetric cloud-chain cooperation storage and retrieval method is designed to detect malicious feedback from the cloud and to improve the medical data retrieval efficiency.
• An attribute-based access policy fusion method is proposed to develop an access control policy created by both doctors and patients. When the medical data access control policies made by doctors and patients conflict, the balance score matrix is calculated to solve this by using the mutual influence weight and intention score of doctors and patients.
• Considering both medical records retrieval efficiency and detecting malicious feedback from cloud servers, a cloud-chain cooperation retrieval method is proposed. It can improve medical records retrieval efficiency by designing the off-chain search structure and performing an initial search on the cloud server with a secondary search on the blockchain.

The rest of this article is arranged as follows. Related work is first discussed in Section 2, followed by Section 3, which presents the background knowledge. Section 4 introduces the $MD{S}^2-C^{3}PF$ model and the security model. The construction and details of the scheme are described in Section 5. Then, Section 6 discusses the security analysis. In Section 7, the experimental analysis of the scheme is carried out. Finally, the whole article is concluded.

2. Related Work

In order to ensure the security of medical data, many works encrypt medical records and store the ciphertext on the cloud. Many IoT-based medical data sharing researchers use ABE and SE to protect data security and privacy in cloud searching and access. In order to overcome the problems caused by the centralized nature of the cloud, recent studies have tried to use blockchain to make an improvement.

Since data sharing requires fine-grained access control methods, Sahai et al. [3] first presented an ABE scheme enabling one-to-many encryption. To improve the performance of ABE, Bethencourt et al. [4] provided a CP-ABE method, which was proven secure in the generic group model. Based on these fundamental works, the state-of-the-art studies on secure data sharing on the cloud, especially medical data sharing, often make use of CP-ABE. Han et al. [16] proposed an attribute-revocable CP-ABE scheme based on privacy protection, which can share data securely by the cloud. In IoT research, Li et al. [17] presented a white-box traceable CP-ABE scheme with accountability in the IoT to address the user key abuse problem. Hu et al. [18] proposed a strategy-hidden sharing method in the IoT to outsource data to the cloud, which can reduce the cost of the user and improve computational efficiency. K. et al. [19] introduced a lightweight key management mechanism based on the IoT to solve the key escrow problem. At the same time, the development of the cloud and the IoT have greatly promoted technological innovation in the medical scene and promoted the secure sharing of medical data. In particular, in order to prevent the disclosure of patients’ privacy, many existing ABE access control studies focus on how to strengthen patients’ control over medical data. Hwang et al. [20] believed that patients have ownership of medical data and used CP-ABE to encrypt medical data to protect the privacy of patient data. Liu et al. [21] proposed an approach based on consortium blockchain to make access control policies by patients. Wang et al. [22] provided a fast, secure patient-controlled access scheme for medical data, which can reduce the storage capacity on the mobile terminal. In fact, the medical data are produced by both the patient and the doctor. Therefore, access to medical data should be decided jointly by doctors and patients, but there are not many studies on co-authorization.

Searchable encryption based on ABE is crucial to achieving secure data sharing. Song et al. [8] first introduced the scheme of searchable encryption and solved the problem of ciphertext retrieval. Since this pioneering work, many security research workshave been proposed to improve the efficiency of ciphertext search and improve the search function. Li et al. [23] provided a secure and efficient dynamic searchable encryption scheme on medical cloud data, improving the ciphertext keyword search efficiency. Chen et al. [24] realized an efficient fuzzy search of keywords by encrypting the fuzzy association scores between data and query predicates. Chaudhari et al. [25] proposed a searchable encryption algorithm based on a single keyword that allows a user to access a subset of the documents. Tahir et al. [26] exploited the properties of the modular inverse to generate a probabilistic trapdoor that facilitates the search over the secure inverted index table. Sun et al. [27] proposed an attribute-based searchable encryption scheme that supports multiple data owners and data requesters. Zheng et al. [28] proposed a verifiable-attribute-based keyword search scheme that could prevent false feedback from the cloud. Yu et al. [29] retrieved the required ciphertext medical data in the IoT, reducing the computational load of outsourcing decryption and improving efficiency.

However, semi-trusted cloud servers are vulnerable to providing false feedback and the malicious forging of medical data. Blockchain’s immutable and decentralized characteristics provide new research ideas and solutions. Liu et al. [30] implemented an electronic medical record sharing scheme based on policy hiding, which uses blockchain to store electronic medical record ciphertext and ensure the correctness of data retrieval. Cao et al. [31] presented a cloud-assisted secure medical system that uses blockchain to record the data operation process and ensure the traceability of data. Zhang et al. [32] provided a decentralized personal health record sharing scheme, using blockchain for the keyword search to ensure the correctness of the queried results. Krishna et al. [33] used ciphertext indexing to search data and utilized blockchain to verify every transaction to make medical data transmission more reliable. Zhu et al. [34] proposed a shared electronic medical data system, which used the automatic execution of chain codes to ensure data access security. In addition, there are some literature works on smart contracts in blockchain, which realize secure sharing and retrieval. Saini et al. [35] designed an access control framework based on a smart contract to prevent a single point of failure and ensure data sharing among different entities. Chen et al. [36] ensured the security of medical data through smart authorization contracts. However, the retrieval efficiency of the above research schemes still needs to be improved.

In a word, it can be seen that the existing works mainly focus on the security data access and retrieval in the IoT and cloud environments, while the essential problem of asymmetry in medical data sharing is not discussed. Unlike the above methods, $MD{S}^2-C^{3}PF$ solves the asymmetric access control right of the medical data between doctors and patients and the asymmetric collection and processing capability between the IoT and the cloud. Meanwhile, our scheme can detect false feedback from the cloud server and improve the sharing data retrieval efficiency.

3. Preliminaries

This section sorts out the preliminary knowledge, including the bilinear maps and access structure.

3.1. Bilinear Maps

Let $G_1$, $G_2$ be a multiplicative cyclic group of prime order p [37]; the generating element of $G_1$ is g. The bilinear map $e:G_1\times G_1\to G_2$ has the following characteristics:

• Bilinear: $\forall u,v\in G_1$ and $a,b\in Z_p^{*}$ with $e(u^a,v^b)=e{(u,v)}^{ab}$;
• Non-degeneracy: $e(g,g)\ne 1$;
• Computability: $\forall u,v\in G_1$ with $e(u,v)$ computable.

3.2. Access Structure

Let T be an access control structure tree whose root node is r [38]. Each non-leaf node in the tree is a threshold, and the leaf nodes are attribute values. Let the number of child nodes of node x be $nu{m}_x$ and $k_x$ be a threshold $(0\le k_x\le nu{m}_x)$. If and only if at least $k_x$ child nodes meet the condition, the parent node can obtain the correct result. When $k_x<nu{m}_x$, the current threshold gate is OR; when $k_x=\mathit{nu}{m}_x$, the current threshold gate is AND.

Let $T_x$ be a subtree of tree T, where x is a child node of T:

• If there exists an attribute set S satisfying the access control tree T, then $T_r\left(S\right)=1$;
• If x is a leaf node, if and only if the attribute set S contains the attribute $att\left(x\right)\in S$ of the current leaf node, then $T_x\left(S\right)=1$;
• If x is a non-leaf node, for a child node $x^{\prime }$ of node x, compute $T_{x^{\prime }}\left(S\right)$; if and only if at least $k_x$ children return $T_{x^{\prime }}\left(S\right)=1$, it can be denoted as $T_x\left(S\right)=1$.

4. System and Security Model

This section introduces the system model, algorithm definition, and security model.

4.1. System Model

Figure 1 shows the system model, which involves the following roles:

• Trust Center (TC). The TC generates key pairs for all legitimate users and executes the policy fusion algorithm.
• Blockchain (BC). The BC is a consortium blockchain that consists of multiple medical institutions to store index information.
• Doctor (DOC). The DOC is the medical data owner responsible for encrypting medical data and uploading the encrypted data to the cloud.
• Cloud Server (CS). The CS is responsible for storing the ciphertext of medical data and sending the file storage address to the DOC.
• Patient (PA). The PA is the owner of the medical data, responsible for developing access policies for the medical data.
• Data Requester (DR). The DR generates a search trapdoor to obtain the corresponding type of data from the cloud and decrypts the medical data.

Table 1. Symbols’ description.

Symbols	Description
$pp$	Public parameter
$pk$	System public key
$mk$	Master key
M	Medical data
$C_M$	Medical data ciphertext
$sk$	Private key
H	Medical data ciphertext hash
k	Encryption key for medical data
P	Balance score matrix
Y	Impact score matrix
X	Intention score matrix
W	Keyword set
T	Access control policy tree
$add$	Storage Address

shows the meanings of the symbols in our scheme.

4.2. Scheme Definition

The proposed scheme consists of the following polynomial-time algorithms:

• $ParaSet\left(\lambda \right)\to \left(pp,pk,mk\right)$: Inputs security parameter $\lambda$ and outputs public parameter $pp$ and master key $mk$.
• $KeyGen\left(S,mk,pp\right)\to sk$: The TC inputs attribute set S, master key $mk$, and public parameter $pp$. Then, the TC outputs the attribute key $sk$ for all legitimate users.
• $StrategyFus(A,B)\to T$: The TC inputs the access control policy tree A of the PA and the tree B of the DOC. The TC fuses A and B and expresses the result as T.
• $Enc(k,M)\to C_M$: The DOC inputs the encryption key k and the medical data and outputs the ciphertext $C_M$ of the medical data.
• $IndexGen\left(W,T,v_1,k,mk,pk,pp,v_2\right)\to \left(I,C^{*}\right)$: The DOC inputs the keyword W, access control policy tree T, system public key $pk$, master key $mk$, and public parameter $pp$. Then, the DOC outputs index I and partial index ciphertext $C^{*}$.
• $TrapGen\left(W^{\prime },mk,sk\right)\to Trap$: The DR runs the algorithm to generate trapdoors based on the keyword $W^{\prime }$ that needs to be queried and then uploads the trapdoors to the BC.
• $CloudSearch(Dep,Trap,sk)\to DAT{A}^{*}$: The CS inputs medical type $Dep$, trapdoor $Trap$, and secret key $sk$. Then, the CS outputs the dataset ${DATA}^{*}$.
• $BlockSearch\left(Trap,DAT{A}^{*},I\right)\to Tx$: The BC executes the algorithm and performs the blockchain keyword search operation based on the trapdoor $Trap$ and the initial filtered dataset ${DATA}^{*}$ and outputs the transactions $Tx$.
• $Verify\left(Tx\right)\to l$: The DR obtains the hash value $Tx$, verifies whether the ciphertext is modified, and outputs $l=1$ if the hash value is consistent; otherwise, $l=0$.
• $Decrypt(l,sk,I)\to k$: If the medical data verification is passed, the DR will decrypt the key k of the medical data according to its own attribute private key $sk$ and I.

4.3. Security Model

$MD{S}^2-C^{3}PF$ performs keyword retrieval on the blockchain to improve searching security and address the issue of false feedback from the cloud servers. Two security models are defined: the Indistinguishability of Ciphertext under the Selectively Chosen Keyword Attack (INDC-SCKA) and the Keyword Secrecy under the Selectively Chosen Secret Key Attack (KS-SCSKA).

4.3.1. The Definition of INDC-SCKA

Theorem 1. 

To prove the INDC-SCKA of $MD{S}^2-C^{3}PF$, in this paper, let attacker $A_1$ and challenger $B_1$ play a secure game $Gam{e}_1$. $MD{S}^2-C^{3}PF$ is said to be indistinguishable with keywords if the probability of attacker $A_1$ winning the game is negligible in polynomial time.

Initialization:$B_1$ inputs the security parameter $\lambda$ and runs $ParaSet\left(\lambda \right)$. Finally, the initialized algorithm returns the system parameter $pp$ and the master key $mk$.

Phase 1: $A_1$ initiates a trapdoor query on the keyword set $W_1,\cdots ,W_t$.

-$TrapGen(W,mk,sk)$: $B_1$ runs the trapdoor generation algorithm $Trap(W_m,mk,sk)$ to return the trapdoor $T_{W_m}$ and then returns it to $A_1$.

Challenge: $A_1$ sends the keyword set $(W_0,W_1)$ to $B_1$, where $W_0,W_1$ is of equal length. $B_1$ selects a bit $c\in \{0,1\}$. $B_1$ generates $I_c=IndexGen\left(W_c,T^{\prime },v_1,k,mk,pk,pp,v_2\right)$ and sends $I_c$ to $A_1$.

Phase 2: $A_1$ issues a trapdoor query for the keyword set $W_{m+1},\cdots ,W_{\tau }$.

-$Trap(W_i\ne W_0,W_1,mk,sk)$: $B_1$ runs $Trap(W_i,mk,sk)$ to obtain the trapdoor $T_{W_i}$, which is sent to $A_1$.

Guess: $A_1$ outputs guess $c^{\prime }\in \{0,1\}$. If $c=c^{\prime }$, $A_1$ wins the game.

The probability of success of $A_1$ attacking the model is $Ad{v}_{A_1}\left(1^k\right)=|Pr[c=c^{\prime }]-\frac{1}{2}|$.

4.3.2. The Definition of KS-SCSKA

Theorem 2. 

To prove the KS-SCSKA, a secure game $Gam{e}_2$ is defined between attacker $A_1$ and challenger $B_1$. If the probability of $A_1$ completing the keyword secrecy game in polynomial time is negligible, then $MD{S}^2-C^{3}PF$ can achieve the keyword security.

Initialization: $B_1$ inputs the security parameter $\lambda$ and runs $ParaSet\left(\lambda \right)$. Finally, the initialized algorithm returns the system parameter $pp$ and the master key $mk$.

Phase 1: $A_1$ interrogates the following algorithm in polynomial time.

-$KeyGen\left(S,mk,pp\right)$: $B_1$ first gives the key $sk$ to $A_1$ and adds the key set to $l_{KeyGen}$.

-$TrapGen(W,mk,sk)$: Given $sk$ and W, $B_1$ executes the trapdoor generation algorithm to generate the trapdoor. $B_1$ sends the result to $A_1$.

Challenge: $A_1$ selects the challenge key $sk$ and gives it to $B_1$. $B_1$ selects the key set $W^{\prime }$ from the information space and executes the $IndexGen$ algorithm, and then, $B_1$ gives the index to $A_1$.

Guess: After $A_1$ obtains a different set of keywords $\tau$, the adversary outputs $W^{\prime }$. If $W^{\prime }=W$, then $A_1$ wins.

$MD{S}^2-C^{3}PF$ can achieve keyword security if the probability of $A_1$ winning the game is no more than for ${\left(\right|\mathcal{W}|-\tau )}^{-1}+ϵ$. $\tau$ denotes the number of keyword sets; $ϵ$ is the negligible probability in the security parameter k; $\mathcal{W}$ is the keyword space.

5. Scheme Construction

Our scheme includes five stages, shown in Figure 2. In the first stage, the system initializes the parameters. Then, the TC sends private keys to the users. In order to form one consistent access policy, in Stage 2, a policy fusion algorithm is presented to merge and resolve conflicts between the access control policies proposed by the patient and the doctor, respectively. In the data generation and storage stage, a doctor uses the fused policy to encrypt and upload the medical data. The original ciphertexts are stored on the cloud, and the index information is stored on the blockchain. The following two stages leverage cloud-chain cooperation mapping and searching to implement controlled secure access to the medical data. The following subsections will thoroughly discuss the access control policy fusion algorithm and the detailed working process of the five stages.

5.1. Access Control Policy Fusion Algorithm

The first step of our scheme is to create one authorization policy that considers User A and B’s access control over medical data. User A generates policy set $Str{a}_A$, which contains n policies, where $a_i$ is the policy of $Str{a}_A$. Similarly, User B produces a policy set $Str{a}_B$ that contains m policies, where $b_j$ is a policy of $Str{a}_B$. The TC takes charge of generating a co-authorization policy set $Str{a}_T$ by comparing $Str{a}_A$ and $Str{a}_B$. Firstly, the TC puts the same policies from setting $Str{a}_A$ and $Str{a}_B$ into the new policy set $Str{a}_T$. Then, different and non-conflicting policies from $Str{a}_A$ and $Str{a}_B$ are also added to $Str{a}_T$. The most critical work is to call the policy conflict resolution algorithm when there are conflicting policies in $Str{a}_A$ and $Str{a}_B$.

Figure 3 shows the flowchart of the algorithm.

5.1.1. Policy Conflict Resolution Algorithm

The strategy conflict resolution is an improved algorithm presented by Tan et al. [28]. They indicated a peer-aware collaborative access control based on identity, which achieves policy equilibrium through peer influence. Differently, our method achieves attribute-based policy equilibrium, referring to players’ influence and using the strategy to update the rules. In this paper, the intention score is defined as the user’s willingness intensity score for policy $a_i$. The impact score is the intensity of user interaction. The balance score is the user’s final willingness value for a policy after being influenced by others:

• Initialize the matrix:
  Let it contain n users (resource owners) and f conflicting attributes, then initialize user i’s intention score for conflicting attribute $a_k$ as $x_i\left(a_k\right)$, where $i\in (1,\cdots ,n),k\in (1,\cdots ,f)$. The value range of the intention score is 0 to 5. Intention score matrix X is denoted as   

  $$X=\left[\begin{array}{ccc}{x}_1\left(a_1\right)& \cdots & x_1\left(a_f\right)\\ ⋮& \ddots & ⋮\\ x_n\left(a_1\right)& \cdots & x_n\left(a_f\right)\end{array}\right]=\left[\begin{array}{ccc}{I}_1& \cdots & I_f\end{array}\right]$$

  (1)
  Suppose the initialized user i is influenced by user j’s influence score $w_{ij}$, taking values in the range of 0–1. Impact score matrix Y is denoted as

  $$Y=\left[\begin{array}{ccc}{w}_{11}& \cdots & w_{1n}\\ ⋮& \ddots & ⋮\\ w_{n1}& \cdots & w_{nn}\end{array}\right]$$

  (2)
• Generate the balance score matrix:
  Let the sentiment gain of user $i\in U$ for an attribute $a_k$ be

  $$pa{y}_i=x_i\left(a_k\right)p_i\left(a_k\right)-\frac{1}{2}{\left(p_i\left(a_k\right)\right)}^2+\sum _{j\ne i}{w}_{ij}{p}_i\left(a_k\right)x_j\left(a_k\right)$$

  (3)

  where $x_i\left(a_k\right)$ is the initial willingness value set by the user and $p_i\left(a_k\right)$ is the final willingness value influenced by other users.

  $$\frac{dpa{y}_i}{d{p}_i\left(a_k\right)}=x_i\left(a_k\right)-p_i\left(a_k\right)+\sum _{j\ne i}{w}_{ij}{x}_j\left(a_k\right)$$

  (4)
  Let $\frac{dpa{y}_i}{d{p}_i\left(a_k\right)}=0$, which gives

  $$p_i\left(a_k\right)=x_i\left(a_k\right)+\sum _{j\ne i}{w}_{ij}{x}_j\left(a_k\right)$$

  (5)
  That is, when $p_i\left(a_k\right)=x_i\left(a_k\right)+\sum _{j\ne i}{w}_{ij}{x}_j\left(a_k\right)$, the user has the highest gain. From Equation (5), the final user’s intention is the sum of his/her own and the player’s influence score. If there is no player influence, then $p_i\left(a_k\right)=x_i\left(a_k\right)$. The final willingness value of each player is calculated by computing the user’s initial settings.
  Therefore, the column vector P of the balance score matrix $p_k$ is denoted as

  $$\begin{array}{cc}\hfill & p_k=Y\cdot I_k=\left[\begin{array}{ccc}{w}_{11}& \cdots & w_{1n}\\ ⋮& \ddots & ⋮\\ w_{n1}& \cdots & w_{nn}\end{array}\right]\cdot \left[\begin{array}{c}{x}_1\left(a_k\right)\\ ⋮\\ x_n\left(a_k\right)\end{array}\right]\hfill \\ \hfill & =\left[\begin{array}{c}{w}_{11}\cdot x_1\left(a_k\right)+\cdots +w_{1n}\cdot x_n\left(a_k\right)\\ ⋮\\ w_{n1}\cdot x_1\left(a_k\right)+\cdots +w_{nn}\cdot x_n\left(a_k\right)\end{array}\right]\hfill \end{array}$$

  (6)
  Let $p_i\left(a_k\right)=w_{i1}\cdot x_i\left(a_k\right)+\cdots +w_{in}\cdot x_i\left(a_k\right)$, and thus, P is denoted as

  $$\begin{array}{cc}\hfill & P=\left[\begin{array}{ccc}{p}_1& \cdots & p_f\end{array}\right]=\left[\begin{array}{c}{q}_1\\ ⋮\\ q_n\end{array}\right]\hfill \\ \hfill & =\left[\begin{array}{ccc}{p}_1\left(a_1\right)& \cdots & p_1\left(a_f\right)\\ ⋮& \ddots & ⋮\\ p_n\left(a_1\right)& \cdots & p_n\left(a_f\right)\end{array}\right]\hfill \end{array}$$

  (7)
• Judge rule:
  This rule determines whether the policy is successfully merged. Firstly, it compares the size of each value of $q_i$ in the row vector, selects the attribute $a_k$ corresponding to the largest value, and stores it in the attribute selection set $\gamma$. Next, the rule judges whether the attribute $a_k$ in the set $\gamma$ is the same attribute and outputs the result.
• Modify the intention matrix:
  Calculate the probability that user j is referenced by other users.

  $$Pr{o_{i\to }}_j\left(a_k\right)=1/\left(1+e^{\left(p_i\left(a_k\right)\right)-p_j\left(a_k\right)/w_{ij}}\right)$$

  (8)

  where $Pr{o_{i\to }}_j\left(a_k\right)$ denotes the probability that i imitates j’s strategy under attribute $a_k$ and $w_{ij}$ denotes the fraction of i influenced by j. $p_i\left(a_k\right)$ and $p_j\left(a_k\right)$ denote the equilibrium fraction of users i and j choosing attribute $a_k$. For each user j, the average probability:

  $$P_j\left(a_k\right)=\frac{{\displaystyle \sum _{i=1,i\ne j}^n}{P_{i\to }}_j}{\left(n-1\right)}$$

  (9)

  where the user j with the highest probability is selected and all other users modify the intention score referring to the policy of j. The balance matrix P is recalculated to determine whether the users’ choices are consistent.

5.1.2. Policy Conflict Resolution Algorithm Process

Compared with the mechanism proposed by Tan et al. [39], the policy conflict resolution algorithm can achieve finer-grained conflict resolution and is suitable for co-authorization scenarios such as the IoMT. Algorithm 1 shows the detailed policy fusion algorithm.

Algorithm 1 Policy conflict resolution algorithm.

Input: $X,Y,S^{*},\gamma =\left[\right]$ Output: $\gamma \left[i\right]$ 1. while $S^{*}\ne \mathrm{null}$ do 2.       $S^{*}=S^{*}-\left\{a_k\right\}$ 3.       compute $p_i=Y\cdot I_k$ 4. end while 5. while true do 6.       let $P=\left[\begin{array}{ccc}{p}_1& \cdots & p_f\end{array}\right]$ 7.       $result=JudgeRule\left(P\right)$ 8.       if $result=\mathrm{Y}$ do 9.             break 10.       end if 11.       if $result=\mathrm{N}$ do 12.             for $i=1;i<f;i++$ do 13.                   $user=getMaxUser(Y,P,f)$ 14.                   for $j=1;j<n;j++$ do 15.                         if $j\ne user$ do 16.                               update $x_j\left(a_f\right)$ according to $x_{\mathrm{user}}\left(a_f\right)$ 17.                         end if 18.                   end for 19.             end for 20.             Compute $p_i=Y\cdot I_k$ 21.       end if 22. end while 23. return $\gamma \left[i\right]$

Firstly, the TC initializes intention matrix $X=[I_1,\cdots ,I_f]$, impact matrix Y, and conflicting attribute set $S^{*}$. It initializes attribute selection set $\gamma$, which here is represented as an array $\gamma =\left[\right]$. The TC calculates the balanced matrix P for the conflicting attributes and checks if all users select the same conflicting attribute. If yes, the algorithm ends. Otherwise, the TC calculates the probability of the user being imitated and selects the user with the highest probability. Other users follow the highest-probability user to modify the intention matrix. After that, the balanced matrix P is recalculated. Figure 4 shows the specific process of the algorithm.

5.2. Details of Five Stages

The project consists of five stages: system initialization, access control policy fusion, data generation and storage, cloud-chain cooperation retrieval, and data verification and decryption.

Stage 1. System initialization:

The TC initializes the parameter and generates the private key for the PA, DOC, and DR, respectively.

• System parameter setting:
  Given security parameter $\lambda$ and mapping parameter $(G_1,G_2,q,g,e)$, the TC executes $ParaSet\left(\lambda \right)$ to generate parameter $pp$, system public key $pk$, and master key $mk$. Then, it selects two hash functions $H_1{\{0,1\}}^{*}\to G_1,H_2{\{0,1\}}^{*}\to Z_q$. Besides, the TC chooses $\alpha ,\beta ,\gamma \in Z_q$ and computes $t_1=g^{\alpha }$, $t_2=g^{\beta }$, $t_3=g^{\gamma }$. Finally, the TC generates public parameter $pp=(G_1,G_2,q,g,e,H_1,H_2)$, system public key $pk=(t_1,t_2,t_3)$, and master key $mk=(\alpha ,\beta ,\gamma )$.
• Key generation:
  The TC executes $KeyGen\left(S,mk,pp\right)$ and generates key $sk$ for the user who owns attribute set S. Firstly, the TC selects random $r\in Z_q$ and chooses $r_s\in Z_q$ for every attribute $s\in S$. Then, it computes $D_1=g^{(\alpha \gamma -r)/\beta }$, $D_2=g^{(\alpha +r)/\beta }$ and calculates $A{}_s=g^r{H}_1{\left(s\right)}^{r_s}$, $B_s=g^{r_s}$. Finally, it generates the user’s attribute key $sk=(D_1,D_2,{\{A_s,B_s\}}_{s\in S})$.

Stage 2. Access control policy fusion:

In this stage, the TC is responsible for executing the access policy fusion algorithm to create a new policy set ${stra}_T$. Here, an example is given to show how the conflict of a policy is fused.

For the conflicting attributes $a_1$ and $a_2$, the TC obtains the intention scores of the conflicting attributes of the DOC and PA, as shown in

Table 2. Intention score matrix X.

	${\mathit{a}}_1$	${\mathit{a}}_2$
PA	$x_1\left(a_1\right)$	$x_1\left(a_2\right)$
DOC	$x_2\left(a_1\right)$	$x_2\left(a_2\right)$

. Besides, the TC obtains the impact scores of the attributes, as expressed in

Table 3. Impact score matrix Y.

	PA	DOC
PA	1	$w_{12}$
DOC	$w_{21}$	1

. Then, the balance score matrix $P=\left[\begin{array}{cc}{p}_1& p_2\end{array}\right]$ is calculated, where $p_1=Y\cdot {\left(\begin{array}{cc}{x}_1\left(a_1\right)& x_2\left(a_1\right)\end{array}\right)}^T$, $p_2=Y\cdot {\left(\begin{array}{cc}{x}_1\left(a2\right)& x_2\left(a_2\right)\end{array}\right)}^T$, as shown in

Table 4. Balance score matrix P.

	${\mathit{a}}_1$	${\mathit{a}}_2$
PA	$x_1\left(a_1\right)+x_2\left(a_1\right)\cdot w_{12}$	$x_1\left(a_2\right)+x_2\left(a_2\right)\cdot w_{12}$
DOC	$x_1\left(a_1\right)\cdot w_{21}+x_2\left(a_1\right)$	$x_1\left(a_2\right)\cdot w_{21}+x_1\left(a_2\right)$

.

The current user’s choice is the highest score in the row vector of P. If the attributes corresponding to the highest scores of the DOC and PA are the same, this attribute is the final result. If there is no agreement on the attribute, the TC calculates the probability ${P_{1\to }}_2\left(a_1\right)=1/(1+e^{\left(p_1\left(a_1\right)-p_2\left(a_1\right)\right)/w_{12}})$ of the PA imitating the DOC’s strategy under attribute $a_1$. Similarly, the TC calculates the probability ${P_{2\to }}_1\left(a_1\right)$ of the PA being imitated. Under attribute $a_1$, the average probability of the PA being imitated is $P_1\left(a_1\right)={P_{2\to }}_1\left(a_1\right)$, and the average probability of the DOC being imitated is $P_2\left(a_1\right)={P_{1\to }}_2\left(a_1\right)$. If $P_1\left(a_1\right)>P_2\left(a_1\right)$, the DOC modifies the intention score to attribute $a_1$ according to the PA. Furthermore, the TC calculates $P_1\left(a_2\right)$ and $P_2\left(a_2\right)$. If $P_1\left(a_2\right)<P_2\left(a_2\right)$, the PA modified the intention score to attribute $a_2$ according to the DOC. Finally, the balance score matrix P is recalculated, and the algorithm ends when the highest score of row vectors in P is the same attribute.

Stage 3. Data generation and storage:

The DOC first encrypts the medical data with a symmetric encryption algorithm to obtain the ciphertext of the medical data and sends it to the CS for storage. Next, he/she encrypts the keyword set with policy tree T to generate the keyword index. Finally, he/she uploads the index information to the blockchain and stores the transaction information table on the cloud:

• Encryption of medical data:
  The DOC inputs the medical data M and randomly selects a symmetric key k from the key space, then outputs $C_M$. The DOC stores $C_M$ to the CS and obtains the storage address $add$. Moreover, the DOC performs a hash operation for ciphertext $C_M$ to obtain the result $h_1=h\left(C_M\right)$, which ensures that the medical data on the cloud are neither tampered with nor forged.
• Index generation:
  The DOC selects random $v_1,v_2\in Z_q$ and generates an access control policy tree T with $v_2$ as the secret value. Then, the DOC encrypts the keyword set W. The specific algorithm is shown below:
  (1) The DOC computes $C_{{}^{{}_0}}={t_1}^{v_2}$, $C_1={t_2}^{v_2}$, $C_2={t_3}^{v_1}$, and $K=ke{(g,g)}^{\alpha v_2}$.
  (2) For each keyword $m\in \{1,\dots ,t\}$, the DOC computes ${\{{\rho }_m={t_1}^{v_1{H}_2\left({\omega }_m\right)}\}}_{m\in \{1,\dots ,t\}}$.
  (3) For each leaf node $z\in Z$, the DOC computes ${\rho }_z=g^{q_z\left(0\right)}$, ${\zeta }_z=H_1{\left(att\right(z\left)\right)}^{q_z\left(0\right)}$.
  (4) Finally, $I=(C_0,C_1,C_2,K)$, $C^{*}={\left\{{\rho }_m\right\}}_{m\in \{1,\dots ,t\}},{\{{\rho }_z,{\zeta }_z\}}_{z\in Z}$.
• Data storage:
  The DOC puts n$\{I,add,H\}$ in a transaction sheet $TX={\{I,add,h_1\}}_n$. If the number of correct node verification results is more than 2/3, the transaction is uploaded to the blockchain. The system obtains the transaction information from the blockchain, constructs the cloud-chain cooperation mapping table according to Dep, and stores it on the cloud, as shown in

  Table 5. Cloud-chain cooperation mapping table.

  Department	Ledger ID	Block Number	Transaction Hash	Partial Ciphertext Index
  $Dep$	$id$	$Blocknum$	$TxHash$	$C^{*}$

  .

Stage 4. Cloud-chain cooperation retrieval:

When the DR wants to obtain medical data, he/she generates a trapdoor by $sk$ and sends it to the cloud server for retrieval. Then, the DR uploads the matching dataset to the consortium blockchain for secondary retrieval and performs a ciphertext keyword search operation. The specific process is as follows:

• Trapdoor generation:
  (1) The DR selects random $p\in Z_q$ and chooses the keyword set $W^{\prime }=\{{w_1}^{\prime },\dots ,{w_m}^{\prime }\}(m\in \{1,\dots ,t\})$.
  (2) The DR calculates $R_1={\prod }_{m=1}^t{g}^{p\alpha H_2\left(w{{}^{\prime }}_m\right)}$,$R_2=g^{p\gamma }$, $R_3={D_1}^p$, ${A_s}^{\prime }={A_s}^p$, and ${B_s}^{\prime }={B_s}^p$, where $s\in S$.
  (3) The DR generates the trapdoor $Trap=(S,R_1,R_2,R_3,{\{{A_s}^{\prime },{B_s}^{\prime }\}}_{i\in S})$.
• Cloud search:
  The CS runs $CloudSearch(Dep,Trap,sk)$. According to the medical data type $Dep$, the CS finds the corresponding medical dataset $DATA$ from the cloud-chain cooperation mapping table and then performs access control policy matching to select the dataset $DAT{A}^{*}$ that satisfies the conditions.
  (1) If x is a leaf node, let $i^{\prime }=att\left(x\right)$, then the CS calculates $D_x=\frac{e({A_{i^{\prime }}}^{\prime },{\rho }_x)}{e({B_{i^{\prime }}}^{\prime },{\zeta }_x)}=e{(g,g)}^{r\mathrm{p}{q}_x\left(0\right)}$.
  (2) If x is a non-leaf node, let $x^{\prime }$ be a child node of x. The CS computes if $D_x={\prod }_{x^{\prime }\in {\omega }_x}{D}_{x^{\prime }}^{{\mathrm{\Delta }}_{i,{{\omega }_x}^{\prime }}\left(0\right)}$$=e{(g,g)}^{r\mathrm{p}{q}_x\left(0\right)}$ holds, where $i=index\left(x^{\prime }\right)$. If not, $D_{x^{\prime }}=\perp$.
  (3) Let $data=(\mathrm{id},Blocknum,TxHash)$, $D_r=e{\left(g,g\right)}^{rp{q}_r\left(0\right)}=e{\left(g,g\right)}^{rp{v}_2}$.
  (4) Finally, the CS outputs the dataset $DAT{A}^{*}={\{data,D_r\}}_d,d\in D$.
• Blockchain search:
  The BC executes $BlockSearch\left(Trap,DAT{A}^{*},I\right)$. According to the trapdoor uploaded by the DR, the nodes on the blockchain carry out keyword matching by Equation (10).

  $$e(\prod _{m=1}^t{\rho }_m{C}_0,R_2)=e(C_2,R_1)D_{r}e(C_1,R_3)$$

  (10)
  If Equation (10) holds, it means that the relevant data are queried and index I is returned; otherwise, ⊥ is returned. The correctness of Equation (10) is verified as follows:

  $$\begin{array}{cc}\hfill & e(C_2,R_1)D_{r}e(C_1,R_3)\hfill \\ \hfill & =e({t_3}^{v_1},{\displaystyle \prod _{i=1}^t}{g}^{p\alpha H_2\left({w^{{}^{\prime }}}_{m^{\prime }}\right)})e{(g,g)}^{rp{v}_2}e({t_1}^{v_2},D^p)\hfill \\ \hfill & =e(g^{y{v}_1},{\displaystyle \prod _{i=1}^t}{g}^{p\alpha H_2\left({w^{{}^{\prime }}}_{m^{\prime }}\right)})e{(g,g)}^{rp{v}_2}e(g^{\beta v_2},g^{(\alpha \gamma -r)·p/\beta })\hfill \\ \hfill & =e{(g,g)}^{y{v}_{1}p\alpha {\displaystyle \sum _{i=1}^t}{H}_2\left({w^{{}^{\prime }}}_{m^{\prime }}\right)}·e{(g,g)}^{rp{v}_2}·e{(g,g)}^{v_{2}p(\alpha \gamma -r)}\hfill \\ \hfill & =e{(g,g)}^{p\alpha \gamma (v_2+v_1{\displaystyle \sum _{i=1}^t}{H}_2\left({{\omega }^{\prime }}_{m^{\prime }}\right))}\hfill \\ \hfill & =e({\displaystyle \prod _{m=1}^t}{\rho }_m{C}_0,R_2)\hfill \end{array}$$

  (11)

Stage 5. Data verification and decryption:

• Medical data validation:
  After successful retrieval, the DR obtains the medical data ciphertext $C{T}_M$ from the CS. The DR executes $Verify\left(Tx\right)$ to verify the hash value. The DR calculates $h_2=h\left(C{T}_M\right)$. If $h_2=h_1$, it outputs $l=1$; otherwise, it returns $l=0$.
• Ciphertext decryption:
  If $l=1$, the DR calculates

  $$k=\frac{K}{({\left(e(C_1,D_2)\right)}^p/D_x{)}^{\frac{1}{\mathrm{p}}}}$$

  (12)
  If Equation (12) holds, the DR can recover k by $Decrypt(l,sk,I)$ and further recover plaintext data M.
  The correctness of Equation (12) is verified as follows:

  $$\begin{array}{cc}\hfill & \frac{K}{({\left(e(C_1,D_2)\right)}^p/D_x{)}^{\frac{1}{\mathrm{p}}}}\hfill \\ \hfill & =\frac{ke{(g,g)}^{\alpha v_2}}{\frac{e{(g,g)}^{(\alpha +r)v_{2}p}}{e{(g,g)}^{rp{v}_2}}}\hfill \\ \hfill & =\frac{ke{(g,g)}^{\alpha v_2}}{{\left(\frac{e{(g,g)}^{\alpha v_{2}p}e{(g,g)}^{r{v}_{2}p}}{e{(g,g)}^{rp{v}_2}}\right)}^{\frac{1}{\mathrm{p}}}}\hfill \\ \hfill & =\frac{ke{(g,g)}^{\alpha v_2}}{e{(g,g)}^{\alpha v_2}}\hfill \\ \hfill & =k\hfill \end{array}$$

  (13)

6. Security Analysis

We provide two detailed safety analyses of the proposed scheme, including the indistinguishability of ciphertext under the selectively chosen keywords attack and the keyword secrecy under the selectively chosen secret key attack.

6.1. The Security Analysis of Our Scheme under the INDC-SCKA

Theorem 3. 

This scheme is selection-safe under the adaptive selection keyword attack based on the general bilinear group model.

Proof. 

The challenger first establishes the general bilinear group model assumption. Let the hash functions $H_1,H_2$ be one-way hash functions, and the specific challenge process is as follows.

Initialization: $B_1$ selects $\alpha ,\beta ,\gamma \in Z_q$ and generates public parameter $pp$ for $A_1$ and system public key $pk=(t_1,t_2,t_3)$. $A_1$ selects policy tree $T^{\prime }$ and returns it to $B_1$. $H_1\left(i\right)$ simulates: If the attribute s has been queried, then challenger $B_1$ selects ${r^{\prime }}_s\in Z_q$, inputs $(s,{r^{\prime }}_s)$ into $O_{H_1}$, and returns $g^{{r^{\prime }}_s}$. Otherwise, challenger $B_1$ retrieves ${r^{\prime }}_s$ from $O_{H_1}$ and returns $g^{{r^{\prime }}_s}$.

Phase 1: Adversary $A_1$ asked $O_{KeyGen}$ and $O_{Trap}$ as follows:

- $O_{KeyGen}(S,mk,pp)$: Challenger $B_1$ chooses $r^{*}\in Z_q$ and calculates $D_1={\mathrm{g}}^{(\alpha \gamma -r^{*})/\beta }$, then randomly selects $r_s^{*}\in Z_q$ and calculates $A_s=g^{r^{*}}{H}_1{\left(i\right)}^{r_s^{*}}$, $B_s=g^{r_s^{*}}$ for the attribute $s\in S$. Finally, $B_1$ returns $(D_1,D_2,{\{A_s,B_s\}}_{s\in S})$.

- $O_{Trapdoor}(sk,W^{*},mk)$: Challenger $B_1$ interrogates $KeyGen(S,mk,pp)$ to obtain $sk=(S,D_1,D_2,{\{A_s,B_s\}}_{s\in S})$. After that, $B_1$ randomly selects $s\in Z_q$ and computes $R_1={\mathrm{\Pi }}_{i=1}^t{g}^{s\alpha H_2\left({\omega }_s\right)},R_2=g^{s\gamma },R_3=D_1^s$. If S satisfies $T^{\prime }$, $W^{*}$ is added to the keyword set list $L_W$.

Challenge phase: Letting $W_0,W_1$ that does not belong to $L_W$, $B_1$ chooses $v_1,v_2\in Z_q$, $v\in Z_q$ and calculates the secret value for each leaf node in $T^{\prime }$. After that, $B_1$ selects random element $b^{*}\in \{0,1\}$. If $b^{*}=0$, $B_1$ outputs ${\{{\rho }_i=g^{v{H}_2\left(w_m\right)}\}}_{m\in \{1,...,t\}}$, $C_0={t_1}^{v_2}$, $C_1={t_2}^{v_2}$, ${\{{\rho }_y=g^{q_z\left(0\right)},{\zeta }_y=H_1\left(att{\left(z\right)}^{q_z\left(0\right)}\right)\}}_{z\in ln}$,$C_2={t_3}^{v_1}$; otherwise, $B_1$ returns ${\{{\rho }_m={t_1}^{v_2{H}_2\left(w_m\right)}\}}_{m\in \{1,...,t\}}$, ${\{{\rho }_z=g^{q_z\left(0\right)},{\zeta }_z=H_1\left(att{\left(z\right)}^{q_z\left(0\right)}\right)\}}_{z\in ln}$, $C_0={t_1}^{v_2}$, $C_1={t_2}^{v_2}$, $C_2={t_3}^{v_1}$.

Phase 2: Generate queries on the key generation algorithm and trapdoor algorithm as in Phase 1.

Guess: $A_1$ outputs guess $c^{\prime }\in \{0,1\}$. If $c=c^{\prime }$, $A_1$ will succeed in the challenge and outputs 1; otherwise, $A_1$ fails in this challenge.

Analysis: If $A_1$ can construct ${t_t}^{\psi v_1{H}_2\left(w_i\right)}$ for $g^{\psi }$ contained in the output of the data that have been queried, $A_1$ is able to distinguish between ${t_t}^{v_1{H}_2\left(w_i\right)}$ and $g^v$. Therefore, it is necessary to prove that $A_1$ can construct $e{(g,g)}^{\psi \alpha v_1{H}_2\left({\omega }_i\right)}$ from $g^{\psi }$ with negligible probability. Because $v_1$ is only in $\gamma v_1$, let $\psi ={\psi }^{\prime }\gamma$. $A_1$ only needs to construct $e{(g,g)}^{{\psi }^{\prime }\gamma \alpha v_1}$ through the term $\gamma v_1$. When ${}^{\beta v_2(\alpha \gamma -r^{*})}/{}_{\beta }=v_2(\alpha \gamma -r^{*})$, $A_1$ needs to eliminate $v_2{r}^{*}$ by $r^{*}$ and $q_r\left(0\right)$. However, it is difficult to construct $v_2{r}^{*}$. Therefore, $A_1$ needs to have properties that satisfy the access control tree $T^{\prime }$ to return the correct indexed result. Therefore, $A_1$ can win with negligible probability. Finally, the INDC-SCKA is implemented, which can effectively detect malicious feedback from the cloud server. □

6.2. The Security Analysis of Our Scheme under the KS-SCSKA

Theorem 4. 

When a one-way hash function $H_2$ is given, this method is the keyword secrecy under selectively chosen secret key attack.

Proof. 

$B_1$ plays the following KS-SCSKA game.

Initialization: $B_1$ chooses $\alpha ,\beta ,\gamma \in Z_q$, selects hash function $H_1:{\{0,1\}}^{*}\to Z_q$, and finally, generates public keys $pk=(g^{\alpha },g^{\beta })$, $pp=(e,g,q)$, $mk=(\alpha ,\beta ,\gamma )$.

$B_1$ simulates $O_{H_1}\left(s\right)$ as follows: If the attribute s has not been queried before, $B_1$ randomly selects element $r_s\in Z_q$, adds $(s,r_s)$ to $O_{H_1}$, and outputs $g^{r_s}$. Otherwise, $B_1$ retrieves $r_s$ from $O_{H_1}$ and returns $g^{r_s}$.

Phase 1: $A_1$ adaptively interrogates $O_{KeyGen}$ and $O_{Trapdoor}$ in polynomial time:

- $O_{KeyGen}(S,mk,pp)$: $B_1$ interrogates the key generation algorithm and returns $sk$ to $A_1$, then adds the access policy T to the list $l_{KeyGen}$.

- $O_{Trapdoor}(sk,W^{*},mk)$: Challenger $B_1$ first interrogates the trapdoor generation algorithm to obtain $sk=(T,\{A_z,B_z|z\in ln\left(T\right)\})$ and then interrogates the trapdoor algorithm to return the trapdoor to adversary $A_1$.

Challenge phase: $A_1$ selects the attribute set $S^{\prime }$, $B_1$, then selects $T^{\prime }$ to interrogate $KeyGen$ to obtain $sk$. Given $S^{\prime }$ and $s{k}^{\prime }$, $A_1$ randomly selects $W^{\prime }$ to compute the ciphertexts $C{T}^{\prime }{}_M$ and trapdoor.

Guess: $A_1$ outputs keyword $W^{\prime }$ and sends it to $B_1$, then $B_1$ asks the IndexGen algorithm to obtain index $I^{\prime }$. If the keywords ciphertext is searched, $A_1$ wins the game.

Analysis: Since $\left|\mathcal{W}\right|-\tau$ is the space size of the remaining keyword set, the probability of $A_1$ computing $W^{\prime }$ from $H_2\left(W^{\prime }\right)$ is negligible. If $A_1$ queries $\tau$ different keywords, the maximum probability of winning the game is ${\left(\right|\mathcal{W}|-\tau )}^{-1}+ϵ$. Therefore, it is proven that this scheme can achieve keyword secrecy. □

7. Experiments and Performance Analysis

The experiment was implemented on the Ubuntu operating system and Intel Core i5 processor 2.3GHz. Fabric was used to set up a 4-node blockchain and Caliper to perform the stress test.

7.1. Blockchain Performance Analysis

As shown in Figure 5, the blockchain throughput was tested by increasing the transaction number from 1000 to 12,000 and using medical data index information to form a transaction. From the figure, it can be seen that the throughput is proportional to the number of transactions, and the change is relatively smooth. This indicates that the system performance improves steadily with the increase of transactions and has good scalability. Since upload indicates writing data to the blockchain, the uploading throughput is lower than downloading. The experiment shows that the proposed scheme in this paper can support data transactions in large quantities.

Figure 6 shows the time comparison between the blockchain search and the cloud-chain combined search. As shown in the figure, a medical data requester should first obtain the dataset that satisfies the access policy from the cloud and then perform a secondary search on the blockchain. During access policy matching, the number of attributes in the user’s private key affects the policy execution time, eventually affecting the search time. As illustrated, the cloud-chain searching scheme is better than blockchain searching. Because centralized cloud searching is more efficient than on-chain searching, our solution combines them together to ensure search efficiency while preventing centralized cloud false feedback.

7.2. Experimental Analysis

The functional analysis and complexity analysis of the $MD{S}^2-C^{3}PF$ scheme are analyzed in this section.

7.2.1. Function Comparison

Table 6. Function comparison.

Scheme	[27]	[28]	[29]	[30]	[31]	${\mathit{MDS}}^2-{\mathit{C}}^3\mathit{PF}$
Multi-keyword search	√	×	√	×	√	√
Co-authorization	×	×	×	×	×	√
Policy hiding	×	×	×	√	×	√
Data sharing	√	√	√	√	√	√

lists the functional benefits of the $MD{S}^2-C^{3}PF$ scheme. As mentioned in the related work, the works [27,28,29,30,31] showed a good performance on data sharing. Reference [29] and the $MD{S}^2-C^{3}PF$ scheme implement policy hiding. The works [27,29,31] and our scheme all realize multi-keyword search operations. However, the $MD{S}^2-C^{3}PF$ scheme implements co-authorization to further ensure the balance of access control among data owners.

7.2.2. Complexity Analysis

Table 7. Comparison computational overhead of our scheme.

Scheme	[27]	[28]	${\mathit{MDS}}^2-{\mathit{C}}^3\mathit{PF}$
Setup	$(3n+1)T_e+T_p$	$3T_e$	$3T_e$
KeyGen	$(3n+1)T_e$	$\left(2n+2\right)T_e+n{T}_h$	$\left(2n+3\right)T_e+n{T}_h$
IndexGen	$\left(3l+3\right)T_e+m{T}_h$	$\left(2l+4\right)T_e+(l+1)T_h$	$T_p+\left(2l+4\right)T_e+(m+l)T_h$
TrapGen	$\left(3l+1\right)T_e+T_h$	$\left(2n+4\right)T_e+T_h$	$\left(t+2\right)T_e+t{T}_h$
Search	$\left(3l+1\right)T_p+T_e$	$\left(2n+3\right)T_p+T_e$	$\left(t+2\right)T_p$

shows the comparison of the computational algorithm complexity in different operation stages. The works [27,28] are similar to the relevant algorithm proposed in this paper, which adopt CP-ABE and SE to solve the problem of data sharing. Therefore, they were compared with the algorithms in the $MD{S}^2-C^{3}PF$ scheme. Compared with [27,28], the overhead of the proposed method in the setup is lower than [27]. It also has advantages over [27,28] in terms of the exponential operational overhead of the search phase. The bilinear matching time is denoted by $T_p$, and $T_e$ is the exponential time. The hash operation time is represented by $T_h$. Let n denote the number of attributes of the authorized user, and l is the number of attributes in the policy. m denotes the keyword count, and t denotes the number of keywords that the authorized user wants to find.

In order to make further comparisons and analysis, the runtimes of $Keygen$, $IndexGen$, and $TrapGen$ were tested through experiments. Attribute numbers were used as a variable because they can significantly affect the runtime.

The time comparison of the $KeyGen$ algorithm is shown in Figure 7. From the figure, it can be seen that the key generation time rises as the number of attributes increases. Figure 8 shows the time comparison of trapdoor generation. As can be seen from the figure, the trapdoor generation time increases with the number of attributes. The key generation time and trapdoor generation time of the scheme are basically the same as those of the schemes in [27,28].

Figure 9 shows the comparison of the index generation time. From the figure, the time of the index generation algorithm rises with increasing attribute number. Compared with [27,28], the $MD{S}^2-C^{3}PF$ scheme implements an index generation algorithm with policy hiding to improve its security. Therefore, our $IndexGen$ algorithm’s time consumption is a little higher. However, the scheme in this paper can realize multiple times of searching following one generated index, which further ensures the feasibility of our solution.

8. Conclusions

In view of the asymmetric access control right of the medical data between doctors and patients and the asymmetric collection and processing capability of IoT terminals and the cloud, medical data sharing is faces the problems of privacy leakage, malicious tampering, and false feedback by the cloud. $MD{S}^2-C^{3}PF$ was proposed to address these asymmetries. For data privacy, a conflict access policy fusion algorithm is used to achieve co-authorization, ensuring that doctors and patients have equal rights to control the medical data. To improve retrieval efficiency and detect spurious feedback from cloud servers, a cloud-chain cooperation retrieval scheme was proposed to balance the asymmetry structure of medical data storage and processing under IoT. Experimental results showed that our scheme can improve search efficiency and is suitable for the secure sharing of medical data with a symmetry structure. In fact, some weaknesses still exist in our work. Policy fusion and conflict resolution need to be completed by a trust center. Such a centralized approach may have some security risks. In future work, the access control policy fusion will be manipulated in a more symmetric way by using blockchain. Inter-domain dynamic access control for medical data sharing will also be further discussed.