EHR data sharing scheme based on block chain and searchable attribute encryption

Abstract

The invention belongs to the technical field of attribute encryption, and provides an EHR data sharing method based on searchable attribute encryption and a block chain. In order to solve the problems of searchable property, revocable property, fine-grained permission control, efficient decryption, data sharing and the like of cloud storage, a searchable property password and a block chain technology are ingeniously combined. By means of the method, efficient ciphertext retrieval is achieved through the keywords, and fine-grained permission control is provided for privacy data through attributes. Meanwhile, the decryption task is outsourced to the agent, an efficient decryption service is provided for the user, a revocable function is realized, and the security and flexibility of data sharing are further improved. Through a detailed simulation test, the EHR data sharing system realized based on the method can meet the requirement of fine-grained efficient sharing of privacy data, and provides powerful support and guarantee for development of the cloud storage field.

Description

Technical Field

[0001] The present invention belongs to the technical field of attribute encryption and provides an EHR data sharing method based on searchable attribute encryption and blockchain. Background Art

[0002] Electronic Health Record (EHR) is a data management method that collects and electronically stores health information of the population in digital format. EHR usually contains demographics, administrative claims, medicine and pharmacy, vital statistics, and patient-centered clinical data storage. With the development of computer science and technology, EHR has become an important means to improve medical care and enhance medical quality.

[0003] Attribute-Based Encryption (ABE) is a cryptographic technique that uses a set of descriptive attributes as identities for generating keys. All ABE systems must be collusion-resistant to prevent users from accessing unauthorized information through collusion. Most attribute cryptographic schemes are in the form of CP-ABE (Ciphertext-Policy Attribute-Based Encryption) or KP-ABE (Key-Policy Attribute-Based Encryption). In addition, researchers have also developed other features of attribute cryptography, such as effective revocation, key delegation, and decentralized permissions. The most notable feature of ABE is its flexible access policy, which can be a threshold access policy, a ciphertext policy, a key policy, and a non-monotonic policy. At the same time, ABE's outstanding features, such as accountability and scalability, help improve cloud distributed systems. Since its birth, attribute encryption has become a research hotspot in cryptography due to its high security.

[0004] As an emerging decentralized technology, blockchain has received widespread attention. Since the birth of Bitcoin, a decentralized cryptocurrency proposed by Satoshi Nakamoto in 2008, cryptocurrency has had a huge impact on traditional financial technology. As the core technology of Bitcoin, blockchain is essentially a distributed shared ledger, and all nodes joining the blockchain can access the data on the chain. Since each node in the blockchain hosts a distributed ledger, the transaction process is completely transparent and does not rely on third-party intermediaries. In addition, the data sharing party's operations on attribute distribution and user management can also become more open and transparent. Blockchain has the characteristics of decentralization, autonomy, transparency, open source, immutability and anonymity. The credibility of the blockchain system comes from its transparency. The record of each node data and the update of data are transparent. The decentralized characteristics make the blockchain independent of the central authority to achieve distributed record storage and update of messages and data. At the same time, as an open source technology, most blockchain systems are open to everyone and can also be publicly checked by everyone. All legitimate nodes can use blockchain technology to create any project and application. The consensus basis enables each legitimate node on the blockchain to safely transmit and update data. In addition, the trust from a single node to the entire system cannot be intervened. The immutability of records will make any record permanently stored on the blockchain. Unless someone can control more than 51% of the nodes at the same time, all records will be immutable. The anonymity of blockchain solves the trust problem between nodes. Only an individual's blockchain address is required for anonymous data storage and transactions, which protects personal privacy to a great extent. At the same time, blockchain can also call the smart contract functions deployed on it. Blockchain was first used in the field of digital currency, and later gradually expanded to various industries, such as education, Internet of Things engineering, electronic medical systems, supply chain management, etc. The implementation of blockchain technology integrates cryptography, distributed systems, mathematical algorithms, economic models and other technologies to form a new distributed environment. In this distributed environment, transactions can be carried out safely even without mutual trust, and there is no need to worry about data storage security issues caused by failures of central agencies.

[0005] Hyperledger is a non-profit open source project of the Linux Foundation, and its framework is widely used in the smart healthcare industry. Hyperledger Fabric is a module in the Hyperledger project that allows organizations to share data on a distributed database without requiring individual users to trust other users. Hyperledger Fabric supports the use of PBFT (Practical Byzantine Fault Tolerance), Raft, and Kafka mechanisms to verify transactions and create blocks. These consensus mechanisms provide different features and applicability to meet the different needs of various scenarios.

[0006] The present invention uses the access control tree as the access structure to implement a fine-grained policy system. Before the system is started, it is necessary to prepare the input access control tree. Each non-leaf node in the access control tree represents a threshold gate and a threshold value described by its child nodes. Generally, num x Indicates the number of child nodes of node x, k x Indicates its threshold. Each node in the access control tree must satisfy 0<k x ≤num x When x=1, the threshold gate is an OR gate. x When , the threshold gate is an AND gate. In the access control tree, each leaf node x consists of an attribute and a threshold k x = 1. The system must use the threshold matching function T(γ) to match each child node layer by layer from the root node downward to determine whether it meets the authorization requirements. Summary of the invention

[0007] The purpose of this invention is to propose an EHR data sharing scheme based on blockchain and searchable attribute encryption, and to provide a reasonable and effective solution to the problems of searchability, revocability, fine-grained permission control, efficient decryption, data sharing, etc. faced by cloud storage.

[0008] The scheme based on searchable attribute encryption proposed in this invention is different from the general attribute encryption scheme. It is an innovative scheme that integrates the characteristics of searchability, revocability, decentralization, efficient encryption and decryption, and flexible data sharing. The overall model of the scheme is as follows: Figure 1 shown.

[0009] Data owner: The data owner is usually the patient, who is responsible for creating electronic health records and setting access control policies. They will set private keys and access time periods for authorized access users and extract file keywords. The data owner is also responsible for creating all key ciphertexts and encrypted files, uploading the final encrypted files to the cloud server provider, and uploading the key ciphertexts to the blockchain. At the same time, they will set access control policies and keyword indexes for shared data.

[0010] Data users: Data users are authorized entities that can search the index and obtain the corresponding electronic health records. They transmit the search request to the blockchain through the trapdoor. If the attributes of the data user meet the access control policy of the key ciphertext and the keywords meet the key ciphertext search requirements, the blockchain smart contract logic will send the key ciphertext and encrypted files to the data user. If the access control policy is not met or the keywords are incorrect, the search request will be rejected. After the matching files are returned, the proxy server and the data user will perform the corresponding decryption algorithm to recover the plaintext.

[0011] Blockchain: The blockchain in the electronic health system is a network of trusted consensus nodes. In this solution, the blockchain collects encrypted transaction data and records all access requests for auditing. At the same time, the blockchain smart contract verifies whether the user's search algorithm meets the conditions. If so, the key ciphertext and encrypted file are sent to the data user.

[0012] Proxy decryption server: The proxy decryption server is responsible for proxy decryption calculations to reduce the computing overhead of data users. It assists data users in performing a decryption operation and provides the computing resources required for decryption.

[0013] Cloud server provider: The cloud server provider provides the business needs of the electronic health record storage space and system. It stores the encrypted files of the data user, generates the relative address of the encrypted file, and sends the address to the data user. The cloud server provider also receives the signature of the data user, executes the second part of the trapdoor generation algorithm, and sends the generated trapdoor to the blockchain.

[0014] The scheme includes seven algorithms, as follows:

[0015] 1. System initialization algorithm:

[0016] Setup(1 λ )→(PK, MK): Let G be a multiplicative cyclic group of prime order p, g be a generator of G, and there is a bilinear map e: G×G→G T , the size is the security parameter λ. Suppose there are three hash functions: At the same time, define the Lagrange coefficient Δ i，S (x) = ∏ i∈S，i≠j (xj) / (ij), where S is The system initialization algorithm takes λ as input and randomly selects w∈G, for all attributes attr i ∈U, randomly selected U is the set of system attributes. The data owner executes the initialization algorithm to obtain the system public key PK and the system master private key MK, where MK is kept secret and PK is published.

[0017]

[0018]

[0019] 2. Key generation algorithm:

[0020] KeyGen(PK,MK,S,P)→(SK,pk DO , pk DU ,S°): The key generation algorithm is executed by the data owner and is divided into three parts.

[0021] (1) The data owner selects a random number As its private key, pk DO =g ξ As its public key, and pk DO Upload to blockchain BC. The data owner selects a random number as its private key, as its public key, and pk DU Upload to blockchain BC.

[0022] (2) The data owner first selects an initialized Bloom filter and formulates an access control policy $P$ based on the system attribute set $U$. Based on this, all attribute sets Z that satisfy the access control policy are determined, where the attribute set Z satisfies the condition Z = (z1, z2, ..., z t )∈P. For further processing, the data owner randomly selects three sets of parameters Next, calculate a i =H1(z i )modL,b i =H2(z i )modL,c i =H3(z i )modL, where L represents the size of the Bloom filter algorithm array (GBFA). Subsequently, the data owner will i ],GBFA[b i ],GBFA[c i ] The corresponding position is incremented by 1. Before this, the initial values ​​of all positions in the Bloom filter algorithm array are 0. After that, the data owner uploads the Bloom filter algorithm array GBFA to the blockchain BC. The data user sends the attribute $S$ to the data owner, and the data owner selects a random number And run the key generation algorithm according to the attribute S to obtain the user decryption key SK, as shown below.

[0023]

[0024] (3) The attribute set S of the data user DU = (x1, x2, ..., x n ), perform three hash operations modulo L on all attributes in S, and embed the values ​​into the initial empty set S° to obtain the hidden attribute mapping set S° = (x′1, x′2, ..., x′ 3n ). Finally, the hidden attribute mapping set S° is uploaded to the blockchain BC.

[0025] 3. Encryption algorithm:

[0026] Encrypt(KW, PK, sk DO , P, ck, m)→(CT, σ i , I, Addr): In the encryption algorithm, the plaintext m is first encrypted by AES symmetric encryption to obtain E(m), and the encrypted file is stored in the cloud server provider CSP, and the encrypted file storage relative address Addr is returned to the data user. Then, according to the public key $PK$ access control policy P and the symmetric encryption key ck, the key ciphertext CT is output, and then according to the data owner's private key sk DO Generate signature σ i Finally, the data owner selects the ciphertext keyword KW to generate the index I, and converts CT, σ i , I upload to blockchain BC.

[0027] (1) Ciphertext generation:

[0028] CTEncrypt(PK, P, ck) → CT: The data owner formulates the access control policy P according to the system attribute set U, and constructs the corresponding access control tree Y according to the access policy P, setting a polynomial q for each node x from the root node to the bottom. x . Each node polynomial q x The highest coefficient d x Satisfy x =t x , $t_x$ represents the threshold of node x. Starting from the root node, a random value number r1 is selected as the hidden secret number. Let q Root (0) = r1. For all nodes x in the access control tree Y, there is an equation q x (0) = q parent(x) (index(x)). Where index(x) in the equation represents the index value of the child node x of the parent node parent(x). Let Y be the attribute set of the leaf node Y of the access control tree. Therefore, the following construction is performed:

[0029]

[0030]

[0031]

[0032]

[0033] CT={C,C0,C1,{C y} att(y)∈Y}

[0034] (2) Signature generation:

[0035] SigEncrypt(PK, CT, sk DO )→{σ i} i＝1，...，n : Signing the key ciphertext can ensure the integrity of the data transmission process. The data owner has full control over all key ciphertext CT i (i=1, ..., n) generates a signature {σ i} i＝1，...，n As shown below:

[0036]

[0037]

[0038]

[0039] (3) Index generation:

[0040] IndexGen(KW, PK, sk DO )→I: After obtaining the key ciphertext, the data owner selects a keyword KW=(kw1, kw2, ..., kw l ), enter the keyword KW, the data owner's private key sk DO and the public key PK, the data owner then randomly selects Generate the following index:

[0041]

[0042]

[0043] I3=w ξ

[0044]

[0045] 4. Trapdoor generation algorithm:

[0046] Trapdoor(KW′,pk DO,sk DU )→TW: The goal of the data user is to find the data containing the keyword KW = (kw1, kw2, ..., kw l )’s key ciphertext. To achieve this goal, the data user and the cloud server provider jointly generate a total trapdoor. At this stage, the data user provides the input pk DO ,sk DU and keyword KW′=(kw′1,kw′2,...,kw′ l ). Then, the data user selects a random number And generate a signature σ=ψΩ. Then the keyword KW′ is hashed and hidden to generate Sec as shown below. After the calculation is completed, the data user sends the signature and hidden keyword information to the cloud service provider (CSP). CSP calculates the trapdoor TW as shown below and uploads it to the blockchain BC.

[0047]

[0048] TW1=ψΩ,

[0049]

[0050] TW3=e(w,g) ψΩ

[0051] TW={TW1,TW2,TW3}

[0052] 5. Search Algorithm:

[0053] Search(I, TW, S°)→(0, 1): The search algorithm inputs the trapdoor TW, and the hidden attribute mapping set S°=(x′1,x′2,...,x′ 3n )$ and ciphertext index I. In this process, if the following conditions are met, the user's search algorithm verification is a match.

[0054] (1) If for i∈[1,3n], GBFA[x′ i ] are not equal to 0, then S°∈P, that is, the data user attribute set matches the access policy of the corresponding key ciphertext.

[0055] (2) If condition (1) is met, the smart contract will verify whether the following equation holds:

[0056]

[0057] e(g,σ i2 )=e(σ i1 , I3)

[0058] If condition (1) is met and the above equation is established, then output "1" and send the key ciphertext CT and relative address Addr to the data user; otherwise, output "0".

[0059] 6. Decryption algorithm:

[0060] Decrypt(SK, CT, Addr)→m: The decryption algorithm includes two parts: server proxy decryption and data user secondary decryption. The decryption algorithm receives the user key SK, key ciphertext CT and relative address Addr as input, and after two decryptions, calculates the plaintext m.

[0061] (1) Proxy decryption:

[0062] ProDec(SK, CT)→(CT1, SK′): The proxy decryption algorithm is executed by the proxy server, and the data user randomly selects And generate the private key middleware SK′ as shown below, and then send {SK′, CT} to the proxy server.

[0063]

[0064] In the proxy decryption process, the user's private key information is non-public and is obtained through recursive calculation. Assuming that the root node of the access control tree is root, for each leaf node y in the set Y, p(y) is defined as the set of all nodes on the path from y to the root node root. For a node x in the access control tree, Sib_{x} is used to represent the node and the set of all its sibling nodes, and we can get Δy = ∏ x∈p(y)，x≠root Δ i，S (0), where i = index(x), S = {index(z)|z∈Sib x}, if the data user attributes satisfy the access policy, the following calculation can be performed based on the private key middleware SK′:

[0065]

[0066] If it cannot be calculated, output F root =⊥, if F root Can be calculated, the proxy server performs the next step of calculation:

[0067]

[0068] If D is calculated successfully, the proxy server sends CT1 = {D, C} to the data user.

[0069] (2) User decryption:

[0070] DecryptDU→(f, CT1, Addr): The data user first obtains the encrypted file E(m) according to the relative address Addr, and obtains CT1. Only one exponential operation is required to obtain the key ck:

[0071]

[0072] After obtaining the key ck, the data user uses ck to decrypt the ciphertext to obtain the plaintext file m.

[0073] 8.Revocation algorithm:

[0074] If there is a property set that needs to be revoked For all Data owners are randomly selected And calculate Then, update UK as follows i for And Lk i Sent to authorized users.

[0075]

[0076] After obtaining the authorized user, update your own attribute private key as follows:

[0077]

[0078] Authorized users can then revoke the attribute set Delete the corresponding element after the hash operation from the mapping set S°. At the same time, for any attribute The data owner updates the ciphertext component in the following manner, and according to the logic of the pre-written smart contract, re-uploads the updated ciphertext component to the blockchain and updates the user access period.

[0079]

[0080] Finally, when operating on the Bloom filter, considering the overlapping characteristics of the mapping, the Bloom filter array value corresponding to the revoked position cannot be directly set to 0, but only the original number can be reduced by 1. Then, GBFA[A i ],GBFA[B i ],GBFA[C i ] minus 1. BRIEF DESCRIPTION OF THE DRAWINGS

[0081] Figure 1 The figure shows the overall model of the scheme.

[0082] Figure 2 The figure shows the overall system architecture.

[0083] Figure 3 This is a system timing diagram. DETAILED DESCRIPTION

[0084] According to the above scheme, the application layer and service layer development of the present invention are based on this machine, using the Windows 11 operating system, the processor is AMD Ryzen 7 5800H CPU@3.20GHz, and the memory is 32GB. The front-end uses the Vue framework and the back-end uses the Gin framework. The Node.js version is v16.16.0, and the npm version is 8.11.0. The Vue CLI version is 5.0.8, the Axios version is 1.12.1, the Element UI version is 2.15.9, and the front-end page is accessed through the Edge browser. In terms of back-end development, the Gin framework is selected, and the version is v1.8.3. The back-end service is bound to listen on port 8080, and the MySQL 5.7 database service is started. The back-end application connects to the MySQL database, stores the business data in the database, and connects to the blockchain service at the same time. The Hyperledger Fabric blockchain is built at the contract layer and storage layer. According to the recommendations and best practices of the official documentation of Hyperledger Fabric, the Hyperledger Fabric blockchain is built on the latest long-term support version Ubuntu 20.04. The Fabric version used is v1.4.0, and each component in the Fabric network is started through Docker Compose, including 4 peer nodes and 1 orderer node. To ensure performance and stability, the system is configured with 8GB of memory. Kafka is used for communication to realize message passing between nodes. Alibaba Cloud is used as the cloud server provider, and the OSS (Object Storage Service) and Elastic Compute Service (ECS) it provides are used to store encrypted files and perform intermediate calculations. During the construction process, Docker24.0.2 and Docker Compose v2.18.1 are used to manage containers. The overall architecture of the system is as follows Figure 2 shown.

[0085] The application layer is the view for users to interact with the system. The application layer of this solution system includes user registration and login page, attribute management page, keyword management page, etc. The application layer will respond to user operations and feedback the interaction results between the application layer and the business layer to the user. This system uses the Vue framework, the development language is based on JavaScript, the installation relies on Axios to complete interface interaction, and uses Element UI to enrich PC-side components.

[0086] The business layer is the backend, which mainly handles business logic and data operations. It implements functions such as user management, attribute management, and keyword management. This solution uses the backend framework Gin based on the Golang language. At the same time, this article implements the separation of the front and back ends, and uses Vue and Gin frameworks together to realize the data interaction between the front and back ends through API interface calls. The front end sends an HTTP request to the Gin backend. After receiving the request, the Gin framework processes the business logic to read or write data, and returns the result to the front end, and calls Fabric-Go-SDK to complete the interaction with the contract layer.

[0087] The contract layer is to deploy smart contracts, also known as chaincodes. This solution uses Golang language to write chaincodes to control the business logic between blockchain nodes. In Fabric, smart contracts can be called and interacted through rich chaincode interfaces, including GetState, DelState, and InvokeChaincode. Different interface methods provide operations such as querying, deleting, and interacting with the state of the ledger. Smart contracts can call interface methods according to business logic to perform ledger operations and state transitions. Smart contracts implement the algorithm functions of the solution, mainly including encryption and decryption functions, trapdoor generation functions, search functions, and revocation functions.

[0088] The storage layer is the foundation of the platform architecture. In the local deployment, the MySQL database is used to store the relevant information and business data of different users. MySQL 5.7 is selected as the database version to ensure the reliability and stability of the data. In Hyperledger Fabric, the main storage is the world state. The world state is a state snapshot during the execution of the smart contract. The storage layer is responsible for storing the changes to the ledger state during the execution of the chain code, thereby maintaining the consistency of the chain code data and achieving persistent storage and fast access. In Hyperledger Fabric, the commonly used database choices are LevelDB and CouchDB for storing the world state. Considering that CouchDB has stronger scalability and security than LevelDB, this solution decides to use CouchDB to store ledger information to improve the system's ability to process data on the chain.

[0089] The EHR data sharing system of this solution includes six key modules, such as Figure 3 As shown, it includes registration / login, account management, attribute management, keyword management, user search and data decryption, as shown below.

[0090] Registration / login stage. In this stage, the patient user initializes the system, generates a system public-private key pair, sends the system public key to the medical institution, and saves the system master private key. The medical institution completes the login and initialization operations.

[0091] Account management stage. In this stage, patients and medical institutions generate their own public and private key pairs and upload the public keys to the blockchain.

[0092] Attribute management stage. In this stage, the medical institution sends the attribute information to the patient user. The patient user then generates a medical institution decryption private key based on the attributes of the medical institution and uploads the private key to the chain. The medical institution obtains the decryption private key from the blockchain according to the logical rules of the smart contract. The patient user symmetrically encrypts the plaintext and stores it in the cloud server provider, which sends the relative address of the symmetrically encrypted ciphertext to the patient user. Assuming that there is a revoked attribute set S, the patient user first updates the system public key component and selects fixed parameters to send to authorized users who have not been revoked, and then updates the private key component and some ciphertext components of the revoked attributes. Unauthorized users will not be able to decrypt the new ciphertext.

[0093] Keyword management stage. In this stage, the patient user selects keywords for the ciphertext, and then uploads the relative address of the encrypted ciphertext, the asymmetrically encrypted ciphertext, the generated signature and the index to the blockchain. After that, the medical institution generates a trapdoor. Trapdoor generation is divided into two parts. The medical institution uploads the keywords and user private keys to the cloud server provider, and the cloud server provider generates a trapdoor based on the keywords and private keys of the medical institution and uploads it to the blockchain.

[0094] In the user search stage. At this stage, the blockchain will verify the correctness of the search algorithm. If the verification is successful, the relative address and key ciphertext of the symmetric encryption ciphertext will be sent to the medical institution, and the medical institution will obtain the symmetric encryption ciphertext through the relative address.

[0095] Data decryption stage. In this stage, data decryption is divided into two parts. The medical institution sends the asymmetric encrypted ciphertext and the user decryption private key middleware to the proxy server. The proxy server performs proxy decryption and sends the semi-decrypted ciphertext to the medical institution. The medical institution then performs full decryption to obtain the plaintext information.

[0096] The algorithm efficiency of each major stage of the system was simulated under different system attributes, user attributes, and the number of revoked attributes. The results are shown in the following table:

[0097]

[0098] We will focus on testing the four key algorithm modules: trapdoor generation algorithm, decryption algorithm, search algorithm, and revocation algorithm. Experiments show that for trapdoor generation algorithm, decryption algorithm, and search algorithm, changes in different system attributes and the number of user attributes will not cause changes in algorithm time, that is, the time overhead of key algorithms is independent of the number of attributes. For application scenarios with large attribute sets, users can achieve decryption and key functions such as search with a relatively fixed overhead. The revocation algorithm is proportional to the number of revoked attributes. Mobile users with large attribute sets have obvious advantages in participating in the system.

[0099] Under different threshold values, the efficiency of the algorithm related to system organization is simulated, and the results are shown in the following table:

[0100]

[0101] As the number of keywords increases, the verification time of the search algorithm remains constant. Therefore, for application scenarios with a large enough number of keywords, the fixed overhead of this solution is obvious. The trapdoor generation algorithm will increase linearly with the increase in the number of keywords, but the time is basically controlled within a few milliseconds, with obvious performance advantages, which shows that the algorithm of the present invention is very practical.

Claims

1. An EHR data sharing solution based on blockchain and searchable attribute encryption, characterized in that: It is mainly divided into five entities: data owner DO, data user DU, blockchain BC, proxy decryption server DS, and cloud server provider CSP, among which: The data owner DO is usually a patient, who is responsible for creating electronic health records and setting access control policies. They will set private keys and access time periods for authorized access users and extract file keywords. The data owner DO is also responsible for creating all key ciphertexts CT and encrypted files, and uploading the final encrypted files to the cloud server provider CSP, and uploading the key ciphertext CT to the blockchain BC. At the same time, they will set access control policies and keyword indexes I for shared data. The data user DU is an authorized entity that can search the index I and obtain the corresponding electronic health record; they transmit the search request to the blockchain BC through the trapdoor TW; if the attributes of the data user DU meet the access control policy of the key ciphertext CT and the keywords meet the search requirements of the key ciphertext CT, the blockchain smart contract logic will send the key ciphertext CT and the encrypted file to the data user DU; if the access control policy is not met or the keywords are incorrect, the search request will be rejected; after the matching file is returned, the proxy server and the data user DU will perform the corresponding decryption algorithm to restore the plaintext; The blockchain BC is a group of trusted consensus node networks. In this solution, the blockchain BC collects encrypted transaction data and records all access requests for auditing. At the same time, the blockchain smart contract verifies whether the user's search algorithm meets the conditions. If so, it sends the key ciphertext CT and encrypted files to the data user DU. The proxy decryption server DS is responsible for proxy decryption calculations to reduce the computing overhead of the data user DU; it assists the data user DU in performing a decryption operation and provides the computing resources required for decryption; The cloud server provider CSP provides the business needs of the electronic health record storage space and the system; it stores the encrypted files of the data user DU, generates the relative address Addr of the encrypted file, and sends the address to the data user DU; the cloud server provider CSP also receives the signature of the data user DU, executes the second part of the trapdoor generation algorithm, and sends the generated trapdoor TW to the blockchain BC.

2. The solution according to claim 1 specifically comprises 7 algorithms: 1) System initialization algorithm: Use the generator to generate bilinear groups and other common parameters; 2) Key generation algorithm: output the user decryption key, generate the user public key and hidden mapping set at the same time, and upload the user public key and hidden attributes to the blockchain BC; 3) Encryption algorithm: Generate ciphertext CT, index I, signature and encrypted file relative address Addr, and upload ciphertext CT, index I and signature to blockchain BC; 4) Trapdoor generation algorithm: output the trapdoor component TW and upload it to the blockchain BC; 5) Search algorithm: In the case of verification, output "1", and output the ciphertext CT and the relative address Addr of the encrypted file; otherwise, output "0"; 6) Decryption algorithm: The cloud server provider CSP outsources decryption and sends the semi-decrypted file CT to the data user DU, who decrypts it to obtain the final plaintext; 7) Revocation algorithm: According to the revocation attribute set, modify the public key component and the ciphertext component, authorize the user to update the user's private key component, and update the access period of the revoked user.

3. According to the scheme of claim 1, its working stages are as follows: 1) Registration / login stage: In this stage, the patient user initializes the system, generates a system public-private key pair, sends the system public key to the medical institution, and saves the system master private key; The medical institution completes the login and initialization operations; 2) Account management stage: In this stage, patients and medical institutions generate their own public and private key pairs and upload the public keys to the blockchain BC; 3) Attribute management stage: In this stage, the medical institution sends the attribute information to the patient user; the patient user then generates the medical institution decryption private key based on the medical institution's attributes and puts the private key on the chain. The medical institution obtains the decryption private key from the blockchain BC according to the logical rules of the smart contract; the patient user symmetrically encrypts the plaintext and stores it to the cloud server provider CSP, and the cloud server provider CSP sends the relative address Addr of the symmetrically encrypted ciphertext to the patient user; assuming that there is a revoked attribute set S, the patient user first updates the system public key component, selects fixed parameters and sends them to authorized users who have not been revoked, and then updates the private key component and part of the ciphertext component of the revoked attribute. Unauthorized users will not be able to decrypt the new ciphertext CT; 4) Keyword management stage: In this stage, the patient user selects keywords for the ciphertext CT, and then uploads the obtained encrypted ciphertext CT relative address Addr, the asymmetrically encrypted ciphertext CT, the generated signature and index I to the blockchain BC; then, the medical institution generates a trapdoor TW; the trapdoor generation is divided into two parts. The medical institution uploads the keywords and user private keys to the cloud server provider CSP, and the cloud server provider CSP generates the trapdoor TW based on the keywords and private keys of the medical institution and uploads it to the blockchain BC; 5) In the user search stage: In this stage, the blockchain BC will verify the correctness of the search algorithm. If the verification is successful, the relative address Addr of the symmetric encrypted ciphertext and the key ciphertext CT will be sent to the medical institution, and the medical institution will obtain the symmetric encrypted ciphertext CT through the relative address Addr; 6) Data decryption stage: In this stage, data decryption is divided into two parts. The medical institution sends the key ciphertext CT and the user decryption private key middleware to the proxy server. The proxy server performs proxy decryption and sends the semi-decrypted ciphertext to the medical institution. The medical institution then performs full decryption to obtain the plaintext information.

Images