A medical data storage method oriented to authorized sharing and distributed indexing

Abstract

The application belongs to the field of medical data storage, and relates to technologies such as blockchains, asymmetric encryption and distributed file systems, in particular, a medical data storage method for authorized sharing and distributed indexing, which realizes low-cost and efficient patient self-controllable data sharing under the premise of protecting the safety of patient privacy data; based on the proxy re-encryption method, the data sharing of grouping and user authorization is realized on a semi-honest platform, and the user experience is improved; based on the improved prefix tree algorithm, a distributed index is prepared for the IPFS file, low-cost and efficient search of the IPFS data file is realized, and the system efficiency is improved.

Description

Technical Field

[0001] This invention belongs to the field of medical data storage and involves technologies such as blockchain, asymmetric encryption, and distributed file systems. Specifically, it is a medical data storage method oriented towards authorized sharing and distributed indexing. Background Technology

[0002] Currently, medical data storage and management primarily rely on traditional centralized storage methods, storing data entirely on centralized servers. Centralized storage uses a limited, fixed number of nodes, and data access is handled solely by a centralized controller. Furthermore, different hospitals maintain their own independent database systems, making data silos difficult to access each other. Medical data contains a large amount of sensitive and private patient information; leaks of this data can lead to a range of problems, including but not limited to marketing and fraud. Therefore, patients do not want unauthorized individuals to access their sensitive data, which negatively impacts the sharing and use of medical data.

[0003] Blockchain technology divides data into blocks and stores them sequentially on the blockchain. In a blockchain system, several servers store the data content. The authenticity of the data content and blocks can be verified using hash algorithms. Blockchain is decentralized, and the data on it is immutable. IPFS (InterPlanetary File System) is a decentralized content distribution protocol used to achieve peer-to-peer data distribution. IPFS identifies files based on hashes and establishes distribution relationships by searching for files and their corresponding nodes using a distributed hash table.

[0004] Current technologies can only achieve basic data sharing functions, with little consideration for the convenience of users' data sharing processes. If either the data file or the authorized doctor user differs, the patient needs to grant online authorization, potentially requiring numerous repetitive operations. Furthermore, current technologies for indexing data files within the IPFS system remain at the centralized indexing stage, making it difficult to meet large-scale data indexing requests. Summary of the Invention

[0005] To address the aforementioned technical issues, this invention discloses a medical data storage method oriented towards authorized sharing and distributed indexing. This method meets the distributed storage needs of large-scale medical data to reduce storage costs; based on proxy re-encryption technology, it meets the authorized distribution needs of sensitive and private medical data, and provides a group-based and user-specific authorization function that can be revoked; and it implements a file indexing method on the IPFS system, achieving low-cost indexing of shared content.

[0006] The specific technical solution adopted in this invention is as follows:

[0007] A medical data storage method oriented towards authorized sharing and distributed indexing is proposed. It adopts a proxy re-encryption method with group authorization to realize distributed authorized sharing of medical data based on blockchain and uses an improved prefix tree algorithm to realize distributed indexing of IPFS files.

[0008] In the above technical solution, a group-based, user-authorized sharing method based on proxy re-encryption is used to achieve authorized sharing of patient data. Individual patients are the owners of their medical data and can authorize users to access their data. Doctors are the data access users and can only access the medical data when authorized by the patient. The key feature of this method is that it allows group-based, user-authorized sharing of medical data. Authorization groups are tagged by patients based on factors such as content theme and sensitivity. A patient can have multiple self-defined authorization groups, and any operation within an authorization group can only be performed by the patient. Authorization groups set by different patients are completely independent of each other. After setting up authorization groups, patients need to divide their medical data into corresponding groups. The same patient's medical data file can be assigned to several authorization groups. When a patient authorizes a doctor, it is done in the form of an authorization group. The doctor can access data files within their assigned authorization group but cannot access data files outside the group. If a patient uploads a new data file and assigns it to an existing authorization group, the existing authorized doctors in that group are automatically allowed to access that data file. This method allows for the revocation of authorization for any doctor at any time, and also allows for the addition, deletion, or modification of authorization groups for any data file at any time. Furthermore, this method allows for the semi-honest nodes to respond to the vast majority of user requests, while ensuring data privacy and security. Semi-honest nodes will respond to user requests according to the specified procedure, but may leak information due to curiosity about any related data.

[0009] In the group-based, user-authorized sharing method based on proxy re-encryption, participants include patients, doctors, control nodes, and proxy re-encryption nodes. Additionally, there is a public blockchain, a public IPFS system for storing medical records as the data system, a private IPFS system for publicizing user whitelists as the permission list system, and several private IPFS systems for storing access control key files as control key systems. The control node is unique and trustworthy, responsible for updating file metadata and access control information. The control node has full access to the permission list system and all control key systems. There are multiple proxy re-encryption nodes; they are semi-honest, strictly executing provided instructions but showing curiosity about related data. All proxy re-encryption nodes have read-only access to the permission list system, and are divided into groups. Each proxy re-encryption node can only access the control key system portion corresponding to its group in a read-only manner.

[0010] The main process of authorizing and sharing data in the method of group and user authorization sharing based on proxy re-encryption includes an initialization stage, a data upload stage, an authorization stage, and a controlled access stage:

[0011] In the initialization stage, the control node divides the proxy re-encryption nodes into m groups and assigns corresponding control key systems. The doctor generates a set of asymmetric encryption key pairs, denoted as {SKd, PKd}. The patient generates n sets of asymmetric encryption key pairs for dividing different access permission groups, denoted as {SKp_i, PKp_i}, (i = 1, 2, 3, … n). The patient also needs to generate another set of asymmetric key pairs, called the root permission group key, denoted as (SKp_r, PKp_r). Every time the patient generates a set of {SKp_i, PKp_i}, (i = 1, 2, 3, … n), the control node is notified to generate a corresponding access whitelist file WL_i (i = 1, 2, 3, … n) and store it in the permission list system. The request does not include the key pair {SKp_i, PKp_i} itself, so the key pair is always kept by the patient himself.

[0012] In the data upload stage of the user, the patient randomly generates a symmetric encryption key K for the data file and encrypts the file with it. Subsequently, the patient splits the symmetric encryption key into m parts through a secret sharing scheme, called KP_j, (j < m). The patient selects several permission groups and encrypts all KP_j (j < m) using the corresponding public keys PKp_i, (i ∈ G) respectively to obtain eKP_ij, (i ∈ G, j < m). During the process of the patient selecting permission groups and encrypting, the root permission group is always selected, that is, the public key PKp_r of the root permission group is always used to encrypt KP_j (j < m) to obtain eKP_rj (j < m). Then the patient generates m corresponding grouped control key files GCF_j (j < m) for the data file, and each file contains the access permission group G it belongs to and the encrypted key part eKP_ij, (i ∈ G) of the corresponding authorization group. All these files are given to the control node. The control node stores each grouped control key file in different partitions of the control key system, and then generates an access index key and sends it back to the patient. Finally, the index key and the medical data ciphertext are merged into a file and uploaded to the data system for public disclosure. The specific method of how to use the index key to find the corresponding data will be described in Method 2. The index key here is not the same concept as the addressing tag in Method 2.

[0013] In the authorization stage, the doctor uploads their public key PKd to the public blockchain and requests access permission from the patient. The patient sets the permission group i according to their own needs, encrypts the doctor's public key PKd using the corresponding private key SKp_i to obtain the re-encryption key REK_i. The patient sends the permission group i and the doctor's user identifier to the control node, and the control node adds the information to the corresponding whitelist file WL_i, where the doctor's user identifier is stored in the whitelist file in the form of a hash. Subsequently, the patient uploads the re-encryption key REK_i and the permission group i to the public blockchain to indicate the completion of authorization. The doctor learns of the authorization from the public blockchain and records the relevant information.

[0014] In the controlled access stage, the doctor first obtains the encrypted file from the data system and extracts the index of the grouped control key file. Subsequently, the doctor uploads the index of the grouped control key file, the authorization group i, and the re-encryption key REK_i to the public blockchain, indicating a request to access the file. Subsequently, the proxy re-encryption node verifies the doctor's identity from the user whitelist WL_i. If the verification passes, the proxy re-encryption node retrieves eKP_ij from the partition j of the control key system where it is located, re-encrypts it, and uploads it to the blockchain. The doctor can re-decrypt each eKP_ij using their private key SKd. If the part uploaded by the proxy re-encryption node to the blockchain reaches the threshold for secret sharing recovery, the doctor can recover the symmetric key K and then decrypt the file to obtain the plaintext.

[0015] This method allows for dynamic modification or revocation of authorization. For revoking the authorization for a single doctor, the patient sends the permission group i where the doctor belongs and the doctor's user identifier to the control node, and the control node removes the doctor's user from the user whitelist WL_i, thus completing the revocation of the authorization for a single doctor. For revoking the entire authorization group, the patient sends the corresponding permission group i to the control node, and the control node removes the whitelist file from the index, completing the revocation of the entire authorization group. For modifying the authorization group to which the file belongs, the patient first recovers the symmetric encryption key K. Subsequently, the patient regenerates m2 corresponding grouped control key files GCF_j (j < m2) for the data file and uploads the grouped control key files to the control node. The control node uploads the key files to the control key system and updates the location pointed to by the original index address to the modified new key file.

[0016] In the aforementioned technical solutions, IPFS is distributed and uses data hashes as data access addresses. If the data changes, the updated data cannot be retrieved using the original access address. Furthermore, IPFS's existing indexing method, IPNS, is a centralized index, which has high indexing costs and cannot withstand single points of failure. To alleviate the cost of data indexing, this paper proposes using an improved prefix tree to implement a distributed index for IPFS. Participants include index maintainers and index users. The index maintainer is unique and responsible for maintaining and updating the index. There are multiple index users who use the index to find data but cannot directly modify the index data. The search targets of index users are not definitively related to each other, but index users can obtain cached portions of the index from other trusted index users.

[0017] In this indexing method, participants include index maintainers and index users. There is only one index maintainer, responsible for maintaining and updating the index. There are multiple index users who use the index to find data but cannot directly modify the index data. The lookup targets of index users are not necessarily related to each other, but index users can obtain cached portions of the index from other trusted index users.

[0018] This method uses a tree structure to implement the index, where each node in the index tree corresponds to an independent IPFS file. To ensure that node data updates are synchronously updated on IPFS, this method stipulates that each node has an addressing tag, and changes to the node data will not change its addressing tag. The index maintainer needs to maintain a set of key-value indexes to serve index users, which are used to implement addressing indexes from addressing tags to IPFS file addresses. The node content of the index tree includes its addressing tag, update time, and list of child nodes. The list of child nodes represents the range of keys and addressing tags of the next-level index node, and can also store the final key-value data. To ensure that node data is not tampered with during distribution, the index maintainer signs the node data and distributes the signature along with the data. Each index user caches the indexed IPFS file and the addressing index to form their own local index.

[0019] This method supports sortable key-value indexes. When searching for data, it first undergoes a local search phase. The search starts from the root node data, searches for the address tag of the corresponding child node in the child node list based on the search key, and then searches for the corresponding data in the local IPFS based on the address tag. This process repeats until the search is successful or fails. If the local search fails, it attempts to request a newer data IPFS address from another trusted index user based on the last address tag and retrieves the data from IPFS. If other index users do not have the newer data, it requests the corresponding IPFS address from the index maintainer.

[0020] This method only supports updating indexes by adding new index entries. Adding an index entry will generate a write event for the index node, and in some cases, it will also generate a split or merge event for the index node.

[0021] When adding a new index item to the index tree, the system first searches the last node in the index tree, and then adds the key-value data to the list of child nodes of that node, thus completing the write event.

[0022] After the write event is completed, if the length of the child node list of the modified node exceeds the threshold A1, and the number of items with the same prefix exceeds the threshold A2, then the data with the same prefix is ​​written to a new node, the data is deleted from the current node, and the new node is inserted as a child node into the current child node list, thus completing the split event.

[0023] After the splitting event is completed, if the length of the current node's child node list is less than or equal to the threshold B, then the current node is deleted from the parent node's child node list, and all the data in the current node's child node list is inserted into the parent node's child node list, thus completing the merge event.

[0024] After the merge event is completed, the current node is no longer reachable from the root node. Simultaneously, the parent node should check whether a split event should be triggered.

[0025] A further improvement to the present invention can be summarized in the following steps:

[0026] Step 1: Initialization

[0027] Process 1.1: The control node initializes the IPFS index system, establishes the IPFS index, and partitions the private IPFS.

[0028] Step 1.2: The proxy re-encryption node registers with the control node to access the system.

[0029] Process 1.3: Doctors register as users and generate keys.

[0030] Process 1.4: Patients register as users, set up sharing permission groups, generate keys, and register with the control node.

[0031] Process 1.5: The control node registers the permission group information to the permission list system and updates the index;

[0032] Step 2: Data Upload

[0033] Process 2.1: After the patient receives the original medical data, a symmetric encryption key is generated and used to encrypt the data. Then, a secret-sharing algorithm is used to split the symmetric encryption key.

[0034] In process 2.2, the patient sets permission groups for files, generates several block control key files based on the symmetric encryption key, and submits them to the control node.

[0035] In process 2.3, the control node uploads the group control key file to the key system, establishes the corresponding index, and returns the corresponding index address to the patient.

[0036] Step 2.4: The patient merges the index address and encrypted data and uploads it to the data system to complete the data upload;

[0037] Step 3: Request authorization:

[0038] Step 3.1: The doctor publicly discloses their public key via a public blockchain to request data access from the patient.

[0039] Step 3.2: After the patient agrees to the authorization request, an authorization group is assigned and a re-encryption key is generated. The control node is notified to add the doctor to the whitelist file. Subsequently, the permission group ID and the re-encryption key are published on the public blockchain.

[0040] In process 3.3, after receiving the request, the control node adds the doctor to the whitelist and updates the index.

[0041] Step 3.4: The doctor obtains the authorization record from the public blockchain, saves the relevant information, and completes the authorization;

[0042] Step 4: Analyze the data:

[0043] Step 4.1: The doctor downloads the encrypted data and block control key file index from the data system, initiates a request on the blockchain using the re-encryption key, and the patient is notified that their data has been attempted to be accessed.

[0044] Process 4.2: Proxy re-encryption nodes in different groups receive requests and access their respective whitelist nodes. If a corresponding doctor user exists in the whitelist, the node accesses the key system of its group to obtain the key, encrypts the key using the proxy re-encryption algorithm, and uploads it to the public blockchain.

[0045] Process 4.3: The doctor uses the proxy re-encryption algorithm to decrypt the on-chain data. If the number of code re-encryption node groups that successfully upload the key exceeds the secret sharing recovery threshold, the doctor can obtain the symmetric encryption key and then decrypt the original medical data.

[0046] The beneficial effects of this invention are as follows: The technical solution proposed in this invention achieves low-cost, high-efficiency, and patient-controlled data sharing while protecting patient privacy and data security. Based on cryptographic algorithms such as proxy re-encryption, it realizes data sharing with group-based and user-authorized access on a semi-honest platform; and based on an improved prefix tree algorithm, it compiles a distributed index for IPFS files, achieving low-cost and high-efficiency searching of IPFS data files. Attached Figure Description

[0047] Figure 1 This is a flowchart of the initialization phase for the authorized sharing in this invention.

[0048] Figure 2 This is a flowchart of the data upload phase for authorized sharing in this invention.

[0049] Figure 3 This is a flowchart of the data authorization stage in the present invention.

[0050] Figure 4 This is a flowchart of the authorized data access phase in this invention.

[0051] Figure 5 This is a schematic diagram of the data structure of the index file in this invention.

[0052] Figure 6 This is a flowchart illustrating the request process for the index file in this invention.

[0053] Figure 7 This is a flowchart of the index update process in this invention. Detailed Implementation

[0054] To enhance understanding of the present invention, the invention will be further described in detail below with reference to the accompanying drawings and embodiments. These embodiments are only used to explain the invention and do not limit the scope of protection of the invention.

[0055] Example: A medical data storage method for authorized sharing and distributed indexing adopts a proxy re-encryption method with group authorization to realize distributed authorized sharing of medical data based on blockchain, and uses an improved prefix tree algorithm to realize distributed indexing of IPFS files.

[0056] The participants in the group-authorized proxy re-encryption method include patients, doctors, control nodes, and proxy re-encryption nodes. It also includes a public blockchain, a public IPFS system for storing medical record data as a data system, a private IPFS system for publicizing user whitelists as a permission list system, and several private IPFS systems for storing access control key files as control key systems. The data sharing process using the group-authorized proxy re-encryption method includes an initialization phase, a data upload phase, an authorization phase, and a controlled access phase.

[0057] like Figure 1As shown in the figure, in the initialization stage, the control node divides the proxy re-encryption nodes into m groups and assigns the corresponding control key system division. The doctor generates a set of asymmetric encryption key pairs, denoted as {SKd, PKd}, and the patient generates n sets of asymmetric encryption key pairs for dividing different access permission groups, denoted as {SKp_i, PKp_i} (i = 1, 2, 3,... n). The patient also generates a set of asymmetric key pairs, called the root permission group key, denoted as (SKp_r, PKp_r). Each time the patient generates a set of {SKp_i, PKp_i} (i = 1, 2, 3,... n), the control node is notified to generate a corresponding access whitelist file WL_i (i = 1, 2, 3,... n) and store it in the permission list system. The request does not include the key pair {SKp_i, PKp_i} itself, so the key pair is always kept by the patient himself;

[0058] As Figure 2 shown in the figure, in the data upload stage, the patient randomly generates a symmetric encryption key K for the data file and encrypts the file with it. Subsequently, the patient splits the symmetric encryption key into m parts through a secret sharing scheme, called KP_j (j < m). The patient selects several permission groups and encrypts all KP_j (j < m) using the corresponding public keys PKp_i (i ∈ G) respectively to obtain eKP_ij (i ∈ G, j < m). During the process of the patient selecting permission groups and encrypting, the root permission group is always selected, that is, the public key PKp_r of the root permission group is always used to encrypt KP_j (j < m) to obtain eKP_rj (j < m). Then the patient generates m corresponding grouped control key files GCF_j (j < m) for the data file. Each file contains the belonging access permission group G and the encrypted key part eKP_ij (i ∈ G) of the corresponding authorization group. All these files are given to the control node. The control node stores each grouped control key file in a different division of the control key system, then generates an access index key and sends it back to the patient. Finally, the index key and the medical data ciphertext are merged into a file and uploaded to the data system for public disclosure;

[0059] As Figure 3 shown in the figure, in the authorization stage, the doctor uploads his public key PKd to the public chain and requests to apply for access permission to the patient. According to his own needs, the patient sets the permission group i for it and encrypts the doctor's public key PKd using the corresponding private key SKp_i to obtain the re-encryption key REK_i. The patient sends the permission group i and the doctor's user identification to the control node. The control node adds the information to the corresponding whitelist file WL_i, where the doctor's user identification is stored in the whitelist file in the form of a hash. Subsequently, the patient uploads the re-encryption key REK_i and the permission group i to the public chain to indicate the completion of authorization. The doctor learns that he is authorized from the public chain and records the relevant information;

[0060] As Figure 4 As shown, in the controlled access phase, the doctor first obtains the encrypted file from the data system and extracts the grouped control key file index from it. Subsequently, the doctor uploads the grouped control key file index, the authorized group i, and the re-encryption key REK_i to the public chain, indicating a request to access the file. Then, the proxy re-encryption node verifies the doctor's identity from the user white list WL_i. If the verification passes, the proxy re-encryption node extracts eKP_ij from the partition j of the control key system where it is located, re-encrypts it, and uploads it to the chain. The doctor can re-decrypt each eKP_ij with his private key SKd. If the part uploaded by the proxy re-encryption node to the chain reaches the threshold for secret sharing recovery, the doctor can recover the symmetric key K, and then decrypt the file to obtain the plaintext.

[0061] The proxy re-encryption method with grouped authorization also includes dynamic modification or revocation of authorization operations. For revoking the authorization of a single doctor, the patient sends the permission group i where the doctor is located and the doctor user identifier to the control node, and the control node removes the doctor user from the user white list WL_i, thus completing the revocation of the authorization of a single doctor. For revoking the entire authorization group, the patient sends the corresponding permission group i to the control node, and the control node removes the white list file from the index, completing the revocation of the entire authorization group. For modifying the authorization group to which the file belongs, the patient first recovers the symmetric encryption key K. Subsequently, the patient regenerates m2 corresponding grouped control key files GCF_j (j < m2) for the data file and uploads the grouped control key files to the control node. The control node uploads the key files to the control key system and updates the position pointed to by the original index address to the modified new key file.

[0062] As Figure 5-7 shown, the participants in the improved prefix tree algorithm include an index maintainer and index users. The index maintainer is unique and is responsible for maintaining and updating the index. There are multiple index users who use the index to search for data but cannot directly modify the index data. The search targets among the index users have no definite association with each other, but the index users can obtain partial cached indexes from other trusted index users.

[0063] The improved prefix tree algorithm uses a tree structure to implement indexing. Each node in the index tree corresponds to an independent IPFS file, and each node has an addressing tag. Changes in node data do not change its addressing tag. The node content of the index tree includes its addressing tag, update time, and a list of child nodes. The list of child nodes represents the range of keys and addressing tags of the next-level index node and stores the final key-value data. Each index user caches the index IPFS file and the addressing index to form its own local index. When searching for certain data, the improved prefix tree algorithm first goes through a local search phase. The search starts from the root node data, searches for the addressing tag of the corresponding child node in the child node list according to the key to be searched, and then searches for the corresponding data in the local IPFS according to the addressing tag. This process is repeated until the search is successful or fails. If the local search fails, it will try to request the IPFS address of the newer data from other trusted index users based on the last addressing tag and retrieve the data through IPFS. If other index users do not have the newer data, they will request the corresponding IPFS address from the index maintainer.

[0064] The above technical solution specifically includes the following steps:

[0065] Step 1: Initialization

[0066] Process 1.1: The control node initializes the IPFS index system, establishes the IPFS index, and partitions the private IPFS.

[0067] Step 1.2: The proxy re-encryption node registers with the control node to access the system.

[0068] Process 1.3: Doctors register as users and generate keys.

[0069] Process 1.4: Patients register as users, set up sharing permission groups, generate keys, and register with the control node.

[0070] Process 1.5: The control node registers the permission group information to the permission list system and updates the index;

[0071] Step 2: Data Upload

[0072] Process 2.1: After the patient receives the original medical data, a symmetric encryption key is generated and used to encrypt the data. Then, a secret-sharing algorithm is used to split the symmetric encryption key.

[0073] In process 2.2, the patient sets permission groups for files, generates several block control key files based on the symmetric encryption key, and submits them to the control node.

[0074] In process 2.3, the control node uploads the group control key file to the key system, establishes the corresponding index, and returns the corresponding index address to the patient.

[0075] Step 2.4: The patient merges the index address and encrypted data and uploads it to the data system to complete the data upload;

[0076] Step 3: Request authorization:

[0077] Step 3.1: The doctor publicly discloses their public key via a public blockchain to request data access from the patient.

[0078] Step 3.2: After the patient agrees to the authorization request, an authorization group is assigned and a re-encryption key is generated. The control node is notified to add the doctor to the whitelist file. Subsequently, the permission group ID and the re-encryption key are published on the public blockchain.

[0079] In process 3.3, after receiving the request, the control node adds the doctor to the whitelist and updates the index.

[0080] Step 3.4: The doctor obtains the authorization record from the public blockchain, saves the relevant information, and completes the authorization;

[0081] Step 4: Analyze the data:

[0082] Step 4.1: The doctor downloads the encrypted data and block control key file index from the data system, initiates a request on the blockchain using the re-encryption key, and the patient is notified that their data has been attempted to be accessed.

[0083] Process 4.2: Proxy re-encryption nodes in different groups receive requests and access their respective whitelist nodes. If a corresponding doctor user exists in the whitelist, the node accesses the key system of its group to obtain the key, encrypts the key using the proxy re-encryption algorithm, and uploads it to the public blockchain.

[0084] Process 4.3: The doctor uses the proxy re-encryption algorithm to decrypt the on-chain data. If the number of code re-encryption node groups that successfully upload the key exceeds the secret sharing recovery threshold, the doctor can obtain the symmetric encryption key and then decrypt the original medical data.

[0085] The foregoing has shown and described the basic principles, main features, and advantages of the present invention. Those skilled in the art should understand that the present invention is not limited to the above embodiments. The embodiments and descriptions in the specification are merely illustrative of the principles of the invention. Various changes and modifications can be made to the invention without departing from its spirit and scope, and all such changes and modifications fall within the scope of the present invention as claimed. The scope of protection of this invention is defined by the appended claims and their equivalents.

Claims

1. A method for storing medical data with authorization sharing and distributed indexing, characterized in that, The method for proxy re-encryption of grouped authorization realizes distributed authorization sharing of medical data based on a block chain, and an improved prefix tree algorithm is used to realize distributed indexing of IPFS files; the method for proxy re-encryption of grouped authorization includes a patient, a doctor, a control node, a proxy re-encryption node, a public chain, a public IPFS system for storing medical record data as a data system, a private IPFS system for publicizing a user whitelist as a permission list system, and a plurality of private IPFS systems for storing access control key files as control key systems; the data sharing process of the method for proxy re-encryption of grouped authorization includes an initialization stage, a data uploading stage, an authorization stage, and a controlled access stage; In the initialization stage, the control node divides the proxy re-encryption node into m groups and allocates corresponding control key systems, the doctor generates a set of asymmetric encryption key pairs, denoted as {SKd, PKd}, and the patient generates n sets of asymmetric encryption key pairs for dividing different access permission groups, denoted as {SKp_i, PKp_i} (i = 1, 2, 3, … n), and additionally generates a set of asymmetric key pairs, referred to as root permission group keys, denoted as (SKp_r, PKp_r); the patient notifies the control node to generate an access whitelist file WL_i (i = 1, 2, 3, … n) corresponding to each set of {SKp_i, PKp_i} (i = 1, 2, 3, … n) generated by the patient and stored in the permission list system, and the request does not include the key pair {SKp_i, PKp_i} itself, so the key pair is always kept by the patient; In the data uploading stage, the patient randomly generates a symmetric encryption key K for the data file and encrypts the file with the symmetric encryption key, then the patient splits the symmetric encryption key into m parts through a secret sharing scheme, referred to as KP_j (j < m), the patient selects a plurality of permission groups G ⊆ { i | i = 1, 2, 3,... n} and encrypts all KP_j (j < m) using the corresponding public keys PKp_i (i∈G) to obtain eKP_ij (i ∈G, j< m), in the process of selecting permission groups and encryption, the root permission group will always be selected, that is, the root permission group public key PKp_r is always used to encrypt KP_j (j < m) to obtain eKP_rj (j < m), then the patient generates m group control key files GCF_j (j < m) corresponding to the data file, each file includes the corresponding access permission group G and the encrypted key part eKP_ij (i ∈G), and these files are all given to the control node, the control node stores each part of the group control key file in different divisions of the control key system, then generates an access index key and returns it to the patient, finally, the index key and the medical data ciphertext are combined into one file and uploaded to the data system for public disclosure. The authorization stage, the doctor uploads the public key PKd to the public chain, requests to apply for access permission to the patient, and the patient sets the permission group i according to the needs, encrypts the doctor's public key PKd using the corresponding private key SKp_i, obtains the re-encryption key REK_i, and sends the permission group i and the doctor's user identifier to the control node, and the control node adds the information to the corresponding white list file WL_i, wherein the doctor's user identifier is stored in the white list file in the form of a hash, then the patient uploads the re-encryption key REK_i and the permission group i to the public chain to indicate that the authorization is completed, and the doctor learns from the public chain that the authorization is granted and records the relevant information; The controlled access stage, the doctor first obtains the encrypted file from the data system and extracts the group control key file index, then uploads the group control key file index, the authorized group i and the re-encryption key REK_i to the public chain to indicate the request to access the file, then the proxy re-encryption node checks the doctor's identity from the user white list WL_i, if the check is passed, the proxy re-encryption node takes eKP_ij from the control key system division j where it is located, re-encrypts and uploads it to the chain, and the doctor can re-decrypt each eKP_ij through its private key SKd, if the part uploaded to the chain by the proxy re-encryption node reaches the threshold of secret sharing recovery, the doctor can recover the symmetric key K and then decrypt the file to get the plaintext; The improved prefix tree algorithm participants include index maintainers and index users, the index maintainers are unique and responsible for maintaining and updating the index, the index users are multiple and use the index to find data but cannot directly modify the index data, and the search targets of the index users have no definite correlation with each other, but the index users obtain cached partial indexes from other trusted index users; The improved prefix tree algorithm uses a tree structure to realize the index, each node of the index tree corresponds to an independent IPFS file, each node has an addressing marker, and the node data change will not change the addressing marker, the node content of the index tree includes the addressing marker, the update time and the child node list, wherein the child node list represents the range and addressing marker of the next level index node key and stores the final key value data, each index user will cache the index IPFS file and the addressing index to form his own local index; when searching for a certain data, the improved prefix tree algorithm first undergoes a local search stage, the search starts from the root node data, finds the addressing marker of the corresponding child node in the child node list according to the search key, then finds the corresponding data in the local IPFS according to the addressing marker, and the cycle continues until the search hits or fails, if the local search fails, the last addressing marker is requested to obtain the newer data IPFS address from other trusted index users, and the data is obtained through IPFS, if other index users have no newer data, the corresponding IPFS address is requested from the index maintainer.

2. The method of claim 1, wherein, The proxy re-encryption method of the group authorization further comprises a dynamic modification or revocation operation. For revoking the authorization of a single doctor, the patient sends the permission group i in which the doctor is located and the doctor user identifier to the control node, the control node removes the doctor user from the user whitelist WL_i, thereby completing the revocation of the authorization of the single doctor. For revoking the entire authorization group, the patient sends the corresponding permission group i to the control node, the control node removes the whitelist file from the index, thereby completing the revocation of the entire authorization group. For modifying the authorization group to which the file belongs, the patient first restores the symmetric encryption key K, then the patient regenerates m2 corresponding group control key files GCF_j (j < m2) for the data file, and uploads the group control key files to the control node, the control node uploads the key files to the control key system, and updates the position pointed to by the original index address to the modified new key file.

3. The method of claim 2, wherein, Specifically, the following steps are included: Step one, initialization: Process 1.1, the control node initializes the IPFS index system, the control node establishes the IPFS index and divides the private IPFS, Process 1.2, the proxy re-encryption node registers with the control node to enter the system, Process 1.3, the doctor registers the user and generates the key, Process 1.4, the patient registers the user, sets the sharing permission group, generates the key, and registers with the control node, Process 1.5, the control node registers the permission group information to the permission list system, and updates the index; Step two, data upload: Process 2.1, after the patient obtains the original medical data, the patient generates a symmetric encryption key and encrypts the data, and then splits the symmetric encryption key using a secret sharing algorithm, Process 2.2, the patient sets the permission group for the file, generates a plurality of group control key files according to the symmetric encryption key, and submits them to the control node, Process 2.3, the control node uploads the group control key files to the key system, establishes the corresponding index, and returns the corresponding index address to the patient, Process 2.4, the patient combines the index address and the encrypted data, and uploads them to the data system, thereby completing the data upload; Step three, request authorization: Process 3.1, the doctor discloses the public key through the public chain, and applies for data access permission to the patient, Process 3.2, after the patient agrees to the authorization request, the patient allocates the authorization group and generates the re-encryption key, notifies the control node to add the doctor to the whitelist file, and then discloses the permission group id and the re-encryption key on the public chain, Process 3.3, the control node receives the request, adds the doctor to the whitelist, and updates the index, Process 3.4, the doctor learns the authorization record from the public chain, saves the relevant information, and completes the authorization; Step four, data analysis: Process 4.1, the doctor downloads the encrypted data and the group control key file index from the data system, initiates a request on the blockchain using the re-encryption key, and the patient can learn that the data is being accessed, Process 4.2: different proxy re-encryption nodes of the group accept the request, access the whitelist nodes in the group to which they belong, and if the corresponding doctor user exists in the whitelist, access the key system of the group to obtain the key, and use the proxy re-encryption algorithm to encrypt the key and upload it to the public chain, Flow 4.3: The doctor decrypts the on-chain data using the proxy re-encryption algorithm. If the number of code re-encryption nodes that successfully upload the key exceeds the secret sharing recovery threshold, the doctor learns the symmetric encryption key and, in turn, decrypts the original medical data.

Images