Fine-grained medical data sharing method

By generating public parameters and master keys through a trusted management center, assigning attribute keys to data users, and constructing an access policy based on a secret sharing matrix, the problems of data leakage and complex access management in medical data sharing are solved, achieving data privacy, sharing trustworthiness, and efficiency.

CN121077640APending Publication Date: 2025-12-05ANHUI NORMAL UNIV
View PDF 0 Cites 0 Cited by

Patent Information

Application Number
CN202511085810.6
Authority / Receiving Office
CN · China
Patent Type
Applications(China)
Current Assignee / Owner
Filing Date
2025-08-04
Publication Date
2025-12-05

AI Technical Summary

Technical Problem

Existing medical data sharing models suffer from problems such as data leakage, privacy breaches, insufficient data credibility, and high complexity in access control. In particular, when sharing data among multiple institutions, ensuring that data can be effectively retrieved in an encrypted state and accessed only by authorized users is a challenge.

Method used

The trusted management center generates public parameters and master keys, assigns attribute keys to each data user, constructs an access policy based on a secret sharing matrix, generates an encryption policy matrix, stores the encrypted medical data in the cloud server, and manages the ciphertext of the symmetric key through a consortium blockchain. Data users generate search trapdoors based on their own attribute sets for verification and decryption.

Benefits of technology

It meets the requirements of data privacy, trustworthy sharing, and high efficiency, ensuring effective retrieval and authorized access to data in an encrypted state, and improving the security and efficiency of data sharing.

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure CN121077640A_ABST
    Figure CN121077640A_ABST
Patent Text Reader

Abstract

The embodiment of the invention provides a fine-grained medical data sharing method, and belongs to the technical field of medical data communication. The sharing method comprises the following steps: a trusted management center generates a public parameter and a master key, allocates an attribute key to each data user according to the master key, and records attribute information to an alliance chain; the data owner generates a 256-bit symmetric key, encrypts the medical data by using a symmetric encryption algorithm, and adds an authentication tag; constructing an access strategy based on a secret sharing matrix, generating an encryption strategy matrix, and embedding the encryption strategy matrix into a ciphertext of the symmetric key when the symmetric key is encrypted; storing the encrypted medical data to a cloud server, and uploading the encrypted ciphertext of the symmetric key to an alliance chain; the data user generates a search trap door according to a self attribute set and submits the search trap door to the cloud server; and the cloud server verifies the search trap door. The sharing method can meet the requirements of data privacy, sharing credibility and high efficiency.
Need to check novelty before this filing date? Find Prior Art

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of medical data communication, in particular to a fine-grained medical data sharing method. BACKGROUND

[0002] With the digital transformation of medical data, the demand for data sharing between medical institutions has increased significantly, and the traditional medical data sharing mode has the following problems: data leakage, privacy leakage, insufficient data credibility and high complexity of permission management. Especially when sharing data between multiple institutions, how to ensure that the data can be effectively retrieved in an encrypted state and can only be accessed by authorized users is a difficulty in current solutions. The blockchain technology provides a new solution for the credibility of medical data sharing with its characteristics of decentralization, non-tamperability and traceability. Azbeg et al. combined blockchain and proxy re-encryption to encrypt data and control access to data to ensure security. Amna et al. used proof of stake (POS) encryption consensus mechanism and secure hash algorithm (SHA256) to verify user identity based on blockchain to protect EHR sharing between different electronic health care systems. In order to solve the problem that malicious users cannot be completely anonymous in the sharing scheme, Li et al. aimed at the problem that private data sharing transactions are easy to cause disputes in the case of anonymity, and used non- repudiation ring signature and Monero technology to realize behavior profile construction prevention and non- framework, which still has room for improvement in storage demand and scalability. But its storage and retrieval performance is limited in large-scale data scenarios. And there are still problems of insufficient keyword privacy protection, complex dynamic permission update and insufficient performance in existing data sharing. Therefore, a fine-grained medical data sharing method is needed. SUMMARY

[0003] The purpose of the embodiments of the present application is to provide a fine-grained medical data sharing method which can meet the requirements of data privacy, sharing credibility and efficiency.

[0004] In order to achieve the above-mentioned purpose, the embodiments of the present application provide a fine-grained medical data sharing method, which comprises: A trusted management center generates public parameters and a master secret key, assigns an attribute secret key to each data user according to the master secret key, and records attribute information to a consortium chain; A data owner generates a 256-bit symmetric secret key, encrypts medical data using a symmetric encryption algorithm, and attaches an authentication tag; An access policy based on a secret sharing matrix is constructed, and an encryption policy matrix is generated, which is embedded in the ciphertext of the symmetric secret key when encrypting the symmetric secret key; The encrypted medical data is stored to a cloud server, and the ciphertext of the encrypted symmetric secret key is uploaded to a consortium chain; The data user generates a search trapdoor according to a set of attributes of the data user, and submits the search trapdoor to the cloud server; The cloud server verifies the search trapdoor; In the case of passing the verification, the encrypted medical data and the ciphertext of the symmetric key are returned to the data user; The data user decrypts the ciphertext of the symmetric key by using the attribute key of the data user, and further decrypts the encrypted medical data.

[0005] Optionally, the trusted management center generates public parameters and a master key, allocates an attribute key for each data user according to the master key, and records attribute information to a consortium chain, including: Defining a bilinear mapping , wherein and is a prime number is an additive group, is a multiplicative group; selecting a collision hash function , respectively used for generating an attribute identifier and a key derivation, representing an integer set of a prime number q; The trusted management center selects random number generation related parameters and aggregates them through specific calculation to obtain public parameters, including: , a generator , and a master key, wherein the public parameters are used to provide uniform cryptographic parameters for all participants to ensure that all participants use the same mathematical settings.

[0006] Optionally, the trusted management center generates public parameters and a master key, allocates an attribute key for each data user according to the master key, and records attribute information to a consortium chain, including: The trusted management center generates an attribute key for each data user according to the registration information of the data user and the attribute and the master key, and distributes the attribute key to the corresponding data user through an encrypted channel; The trusted management center generates a one-time session key when distributing the attribute key, and the consortium chain records the hash evidence of the key distribution; The trusted management center records the attribute information of the data user to the consortium chain to ensure the traceability and integrity of the information.

[0007] Optionally, an access policy based on a secret sharing matrix is constructed, and an encryption policy matrix is generated and embedded into the ciphertext of the symmetric key when encrypting the symmetric key, including: Each attribute is assigned to a unique random index and only record the random index in the subsequent encryption process; representing an original access policy matrix wherein the element in the matrix represents the relationship between the ith attribute and the jth access control rule ; The noise truncation boundary is calculated by formula (1): Formula (1), wherein, represents the noise scale, represents the sensitivity, represents the differential privacy parameter, represents the noise truncation boundary, is a negligible probability, represents the inverse error function, used for noise truncation calculation; A noise matrix is generated by a pseudo-random number generator, and each element in the noise matrix needs to meet the condition: ; The noise matrix is added to the original access policy matrix to obtain a first encrypted matrix; For each element in the first encrypted matrix, encryption is performed by an encryption function , wherein represents each element in the first encrypted matrix, represents an access policy; According to the encrypted element, a final encrypted access control policy matrix is obtained: , wherein, , ... represents the encrypted element.

[0008] Optionally, an access policy based on a secret sharing matrix is constructed, and an encrypted policy matrix is generated and embedded into the ciphertext of the symmetric key when the symmetric key is encrypted, including: The attribute is obtained, and the corresponding encrypted value is calculated by a CP-ABE encryption algorithm, wherein represents a generator, represents a random number, represents the attribute in the CP-ABE encrypted ciphertext value; The symmetric key is obtained and encrypted using the CP-ABE encryption algorithm. During encryption, elements from the final encrypted access control policy matrix are embedded into the ciphertext to generate the ciphertext of the symmetric key. , This represents the encrypted value of each attribute. This indicates encryption using a symmetric key.

[0009] Optionally, the encrypted medical data is stored on a cloud server, and the ciphertext of the encrypted symmetric key is uploaded to the consortium blockchain, including: Medical data encrypted using the AES-GCM algorithm will be stored on a cloud server. Extract a set of searchable keywords from the medical data, and calculate the collision hash of each keyword in the keyword set. ,in, Generate blinding factor ; Generate an encrypted index using the ABSE algorithm. ,in, For attributes public key transformation function, Keywords Associated access policies The public key parameter is randomized and used to hide the keyword search structure. The blinded encrypted value of the keyword "kw" is bound to a master key (MSK) to ensure security; Encrypt index With the final encrypted access control policy matrix Related; The encrypted index Upload the ciphertext of the symmetric key and the hash of the encrypted index to the cloud server and upload them to the consortium blockchain.

[0010] Optionally, data users generate search trapdoors based on their own attribute sets and submit them to the cloud server, including: Data users based on each of their own attributes Calculate the corresponding encrypted value based on the attribute key. ; Based on the access policy, generate a search trap containing encrypted values ​​of all attributes and keywords. ,in, This indicates the keyword kw j A searchable trapdoor component used to match the corresponding encrypted index I in encrypted data. kw , Digital signature The search trap is submitted to the cloud server for verification.

[0011] Optionally, the cloud server verifies the search trapdoor, comprising: The cloud server receives a request query of the search trapdoor ; The cloud server performs a quick filter check on the search trapdoor T through a Bloom filter to filter invalid attributes to match the search trapdoor T and the keywords in the encrypted index , wherein the Bloom filter uses hash functions and bit arrays; After the matching filter passes, the cloud server extracts the encrypted index matched with the search trapdoor T into verifiable structured data; The smart contract screens the attribute secret keys issued by the trusted management center in the structured data to prevent access by fake secret keys or revoked secret keys; According to the structured data corresponding to the screened attribute secret keys, verify whether the hash of the encrypted index in the structured data is consistent with the one stored on the alliance chain; In the case of consistency, the bilinear verification passes the verification of the corresponding final encrypted access control policy matrix in the structured data and the ciphertext of the symmetric key to determine the ciphertext of the corresponding symmetric key and the encrypted medical data.

[0012] Optionally, the data user decrypts the ciphertext of the symmetric key through the attribute secret key to which it belongs, and further decrypts the encrypted medical data, comprising: The data user decrypts the ciphertext of the encrypted symmetric key using the attribute secret key corresponding thereto; According to the decrypted symmetric key; Decrypt the encrypted medical data through the decrypted symmetric key, and verify the additional authentication tag Tag, and finally restore the plaintext of the medical data for the data user to access.

[0013] Optionally, verifying the additional authentication tag Tag comprises: Obtain the plaintext of the decrypted medical data; Recalculate a new additional authentication tag according to the plaintext of the medical data through the AES-GCM algorithm; Verify whether the new additional authentication tag matches the additional authentication tag together with the encrypted medical data; In the case of matching, it is indicated that the medical data has not been tampered with.

[0014] By the technical scheme, the fine-grained medical data sharing method generates public parameters and a master key through a trusted management center, and can assign an attribute key to a data user according to the master key, and then record attribute information to a consortium chain. A data owner can generate a 256-bit symmetric key through a random number generator, and can encrypt medical data using a symmetric encryption algorithm ASE-GCM, and can attach an authentication tag. An access policy based on a secret sharing matrix can be constructed, and a policy matrix can be generated, and the encrypted policy matrix can be embedded into the ciphertext of the symmetric key when the symmetric key is encrypted. After the medical data is encrypted, the encrypted medical data can be stored to a cloud server, and the ciphertext of the encrypted symmetric key can be uploaded to the consortium chain. A data user can generate a search trapdoor according to its own attribute set, and can submit it to the cloud server. The cloud server can verify the search trapdoor, and if the verification is passed, the encrypted medical data and the ciphertext of the symmetric key can be returned to the data user. The data user can decrypt the ciphertext of the symmetric key through its attribute key, and can further decrypt the encrypted medical data, so that the plaintext of the medical data can be obtained. The sharing method can meet the requirements of data privacy, sharing credibility and high efficiency.

[0015] Other features and advantages of the embodiments of the present application will be described in detail in the following detailed description. BRIEF DESCRIPTION OF DRAWINGS

[0016] The accompanying drawings are included to provide a further understanding of the embodiments of the present application, and constitute a part of the specification, and are used to explain the embodiments of the present application together with the following detailed description, but do not constitute a limitation of the embodiments of the present application. In the drawings: Figure 1 is a flowchart of a fine-grained medical data sharing method according to an embodiment of the present application; Figure 2 is a flowchart of obtaining a master key of a fine-grained medical data sharing method according to an embodiment of the present application; Figure 3 is a flowchart of assigning an attribute key of a fine-grained medical data sharing method according to an embodiment of the present application; Figure 4 is a flowchart of obtaining an encrypted policy matrix of a fine-grained medical data sharing method according to an embodiment of the present application; Figure 5 is a flowchart of embedding an encrypted policy matrix into a ciphertext of a symmetric key of a fine-grained medical data sharing method according to an embodiment of the present application; Figure 6is a flow chart of generating an encrypted index of a fine-grained medical data sharing method according to an embodiment of the present application; Figure 7 is a flow chart of generating a search trapdoor of a fine-grained medical data sharing method according to an embodiment of the present application; Figure 8 is a flow chart of verifying a search trapdoor of a fine-grained medical data sharing method according to an embodiment of the present application; Figure 9 is a flow chart of decrypting ciphertext of a symmetric key of a fine-grained medical data sharing method according to an embodiment of the present application; Figure 10 is a flow chart of verifying an attachment label of a fine-grained medical data sharing method according to an embodiment of the present application. DETAILED DESCRIPTION

[0017] The specific embodiments of the present application will be described in detail below with reference to the accompanying drawings. It should be understood that the specific embodiments described herein are merely intended to illustrate and explain the present application, and are not intended to limit the present application.

[0018] In the embodiments of the present application, some software, components, models, etc. in the industry may be mentioned, which should be considered as exemplary, and the purpose is only to illustrate the feasibility of the technical solutions of the present application, but it does not mean that the applicant has or will necessarily use the scheme.

[0019] Figure 1 is a flow chart of a fine-grained medical data sharing method according to an embodiment of the present application. In Figure 1 , the flow of the sharing method can include: In step S1, the trusted management center generates public parameters and a master key, assigns attribute keys to each data user according to the master key, and records attribute information to the consortium chain.

[0020] In step S2, the data owner generates a 256-bit symmetric key, encrypts the medical data using a symmetric encryption algorithm, and adds an authentication label.

[0021] In step S3, an access policy based on a secret sharing matrix is constructed, and an encrypted policy matrix is generated and embedded into the ciphertext of the symmetric key when encrypting the symmetric key.

[0022] In step S4, the encrypted medical data is stored to the cloud server, and the ciphertext of the encrypted symmetric key is uploaded to the consortium chain.

[0023] In step S5, the data user generates a search trapdoor according to the attribute set of itself and submits it to the cloud server.

[0024] In step S6, the cloud server verifies the search trapdoor.

[0025] In step S7, in case of verification, the encrypted medical data and the ciphertext of the symmetric key are returned to the data user.

[0026] In step S8, the data user decrypts the ciphertext of the symmetric key by the attribute secret key of itself, and further decrypts the encrypted medical data.

[0027] In the present application, when sharing and transmitting the medical data, the trusted management center can generate a public parameter and a master key, and can assign an attribute secret key to each data user according to the master key, and then can record the attribute information to the consortium chain. The public parameter can provide a unified cryptographic parameter for all participants, ensuring that everyone uses the same mathematical setting, so that encryption and decryption can be correctly matched. The data owner can generate a 256-bit symmetric key by a random number generator, and can encrypt the medical data using the symmetric encryption algorithm ASE-GCM, and can attach an authentication tag. An access policy based on a secret sharing matrix can be constructed, a strategy matrix can be generated, and the encrypted strategy matrix can be embedded into the ciphertext of the symmetric key when encrypting the symmetric key. After encrypting the medical data, the encrypted medical data can be stored to the cloud server, and the ciphertext of the encrypted symmetric key can be uploaded to the consortium chain. The data user can generate a search trapdoor according to the attribute set of itself, and can submit it to the cloud server. The cloud server can verify the search trapdoor, and in case of verification, the encrypted medical data and the ciphertext of the symmetric key can be returned to the data user. The data user can decrypt the ciphertext of the symmetric key by the attribute secret key of itself, and can further decrypt the encrypted medical data, so as to obtain the plaintext of the medical data. The sharing method can meet the requirements of data privacy, sharing credibility and high efficiency.

[0028] In one embodiment of the present application, as shown in Figure 2 , the process of obtaining the master key can include: In step S9, a bilinear mapping is defined, where and are a multiplicative group when is an additive group of prime number .

[0029] In step S10, a collision hash function is selected, which is used for generating attribute identifier and key derivation, respectively. represents an integer set of prime number q.

[0030] In step S11, the trusted management center selects random number generation related parameters and aggregates them through specific calculation to obtain public parameters, including: , a generator , and a master key, wherein the public parameters are used to provide uniform cryptographic parameters for all participants to ensure that all participants use the same mathematical settings.

[0031] In the present application, when generating attribute keys, a bilinear mapping can be defined first, and then a collision hash function can be selected to generate attribute identifiers and key derivation. Through the trusted management center, random number generation related parameters can be selected and aggregated through specific calculation to obtain public parameters, and the public parameters can be generated at the same time as the master key . After generation, threshold secret sharing (TSS) can be used to split it into n pieces of shards, at least pieces of shards are needed to recover together, and only the trusted management center can control it.

[0032] In an embodiment of the present application, as Figure 3 shown, the process of allocating attribute keys can include: In step S12, the trusted management center generates attribute keys for each data user according to the registration information of the data user and the attribute and the master key, and distributes the attribute keys to the corresponding data user through an encrypted channel.

[0033] In step S13, when distributing the attribute keys, the trusted management center generates a one-time session key, and the alliance chain records the hash evidence of the key distribution.

[0034] In step S14, the trusted management center records the attribute information of the data user to the alliance chain to ensure the traceability and integrity of the information.

[0035] In the present application, when allocating attribute keys, the trusted management center can generate attribute keys for each data user according to the registration information of the data user and the attribute and the master key . Among them, represents a data user, represents a set of attributes of the data user. After generating the attribute keys, the attribute keys can be distributed to the data user through a TLS 1.3 encrypted channel, and a one-time session key is generated each time the distribution is performed, and the alliance chain can record the hash evidence of the key distribution. At the same time, the trusted management center can record the attribute information of the data user to the alliance chain, so as to determine the traceability and integrity of the information.

[0036] In an embodiment of the present application, asFigure 4 As shown, the process of obtaining the encryption policy matrix can include: In step S15, each attribute is assigned to a unique random index , and only the random index is recorded in the subsequent encryption process.

[0037] In step S16, the access control policy is represented as an original access policy matrix , where the element in the matrix represents the relationship between the i-th attribute and the j-th access control rule .

[0038] In step S17, the noise truncation boundary is calculated by formula (1): Formula (1), where denotes the noise scale, denotes the sensitivity, denotes the differential privacy parameter, denotes the noise truncation boundary, is a negligible probability, denotes the inverse error function, used for noise truncation calculation.

[0039] In step S18, a noise matrix is generated by a pseudo-random number generator, and each element in the noise matrix needs to satisfy the condition: .

[0040] In step S19, the noise matrix is added to the original access policy matrix to obtain the first encryption matrix.

[0041] In step S20, for each element in the first encryption matrix, encryption is performed by the encryption function , where denotes each element in the first encryption matrix, denotes the access policy.

[0042] In step S21, according to the encrypted elements, the final encrypted access control policy matrix is obtained: , where , ...denotes the encrypted elements.

[0043] In the present application, in order to flexibly encode and hide the access policy while ensuring security, we adopt a secret sharing scheme. At present, the mainstream secret sharing schemes include the access control tree-based scheme and the secret sharing matrix-based scheme. To improve efficiency, the secret sharing matrix-based method can be used. By sharing the matrix to represent the access control policy and combining the noise introduction and random index allocation technology, the access policy can be effectively hidden and the security of the encrypted data can be ensured. When generating the encrypted policy matrix, the access control policy can be represented as an original access policy matrix M. The matrix can be represented as The elements in the matrix represent the control policy as: Each attribute is allocated to a unique random index , and only the random index is recorded in the ciphertext without directly exposing the specific meaning of the attribute. The random index can be represented as To enhance the invisibility of the access policy and resist the statistical analysis attack of the enemy, truncated Laplace noise can be introduced, and zero-knowledge proof can be combined to ensure the correct generation of the noise. When introducing the truncated Laplace noise, the differential privacy parameter can be selected (usually ), and then the noise truncation boundary can be calculated by formula (1). According to the calculated noise truncation boundary, it is ensured that the noise value falls within the interval. The noise matrix can be generated by the lattice-based random number generator (CSPRNG), and each element in the noise matrix needs to satisfy the condition To resist quantum computing attacks, the CSPRNG is instantiated by the LWE (Learning With Errors) problem to ensure pseudo-randomness. The noise term needs to pass the zero-knowledge verification of its correctness, and the data owner submits the noise commitment to the consortium chain. The smart contract randomly samples to verify whether the distribution of satisfies the condition of , and verifies that the generation path has not been tampered with. In this way, even if the attacker obtains part of the ciphertext, the presence of noise makes it difficult for them to recover the effective access policy information from it. After obtaining the noise matrix, the noise matrix and the original access policy matrix can be added to obtain the first encrypted matrix. The first encrypted matrix can contain the original access policy information and the interference of random noise. For each element in the first encrypted matrix, the random index and the access policy can be encrypted. The encryption function Each element can be encrypted, so that the final encrypted access control policy matrix can be obtained. Through the above encryption process, the finally generated access control policy matrix effectively hides the access policy and increases the difficulty of cracking by attackers.

[0044] In an embodiment of the present application, as shown in Figure 5 The process of embedding the encrypted policy matrix into the ciphertext of the symmetric key can include: In step S22, the attributes are obtained, and the corresponding encrypted values are calculated by the CP-ABE encryption algorithm represents a generator, represents a random number, represents an attribute In the ciphertext value of CP-ABE encryption; In step S23, the symmetric key is obtained, and the symmetric key is encrypted by the CP-ABE encryption algorithm, and the elements in the final encrypted access control policy matrix are embedded into the ciphertext during encryption, to generate the ciphertext of the symmetric key: , represents the encrypted value of each attribute, represents the encryption of the symmetric key.

[0045] In the present application, when the ciphertext of the symmetric key is obtained, the access policy based on the secret sharing matrix and the generated encrypted policy matrix, that is, the finally generated access control policy matrix, can be embedded into the ciphertext of the symmetric key. When generating the ciphertext, the symmetric key can be encrypted using the CP-ABE algorithm. The CP-ABE encryption process represents the access policy as a tree structure or a gate formula, and each node of the tree represents an attribute or a combination of attributes. The ciphertext of each attribute will be generated according to the attribute key, and combined with the access policy. For each attribute in the access policy , represents a generator, which is used to enhance the security of the encryption. After obtaining the symmetric key, the symmetric key can be encrypted by the CP-ABE encryption algorithm, and during encryption, the elements in the final encrypted access policy matrix can be embedded into the ciphertext, so that the ciphertext of the symmetric key can be generated.

[0046] In an embodiment of the present application, as shown in Figure 6 The process of generating the encrypted index can include: In step S24, the medical data encrypted by the AES-GCM algorithm is stored to the cloud server.

[0047] In step S25, a set of searchable keywords is extracted from the medical data, and the collision hash of each keyword in the keyword set is calculated. ,in, Generate blinding factor .

[0048] In step S26, an encrypted index is generated using the ABSE algorithm. ,in, For attributes public key transformation function, Keywords Associated access policies The public key parameter is randomized and used to hide the keyword search structure. The keyword kw is encrypted using a blinded key (MSK) to ensure security.

[0049] In step S27, the encrypted index is... With the final encrypted access control policy matrix Related.

[0050] In step S28, the encrypted index is... Upload the ciphertext of the symmetric key and the hash of the encrypted index to the cloud server and then upload them to the consortium blockchain.

[0051] In this invention, after completing the symmetric encryption and key encapsulation of medical data, the data owner can upload the relevant information to a cloud server and a consortium blockchain. The data owner can store the medical data encrypted using the AES-GCM algorithm in the cloud server. A set of searchable keywords (such as disease names and patient IDs) can be extracted from the medical data. The collision hash of each keyword is calculated, and then an encrypted index can be generated using the ABSE algorithm. This can extract the searchable fields of the medical data into an index sequence, used to match user-submitted search keywords, allowing users to search for specific content without decrypting the data. After obtaining the encrypted index, it can be associated with the final encrypted access control policy matrix, and then the encrypted index can be uploaded to the cloud server, while the ciphertext of the symmetric key and the hash of the encrypted index can be uploaded to the consortium blockchain. This design ensures that data users can subsequently perform encrypted retrieval by constructing search trapdoors without exposing the keyword content; simultaneously, on-chain policy verification and index matching enable the judgment and traceability of data access permissions.

[0052] In one embodiment of the present invention, such as Figure 7 As shown, the process of generating a search trapdoor may include: In step S29, the data user determines the data based on each of its attributes. Calculate the corresponding encrypted value based on the attribute key. .

[0053] In step S30, a search trapdoor containing encrypted values ​​of all attributes and keywords is generated according to the access policy. in, The keyword kw is represented. j A searchable trapdoor component used to match the corresponding encrypted index I in encrypted data. kw , This refers to a digital signature.

[0054] In step S31, the search trapdoor is submitted to the cloud server for verification.

[0055] In this invention, data users can generate a search trapdoor T with an attached digital signature based on their own attribute set S. Furthermore, the data can be submitted to the cloud server for verification. Data users can calculate the corresponding encrypted value based on each of their attributes and the attribute key. Then, according to access policy A, they can generate a search trapdoor containing the encrypted values ​​of all attributes and keywords. After obtaining the search trapdoor, it can be submitted to the cloud server for verification.

[0056] In one embodiment of the present invention, such as Figure 8 As shown, the process of verifying a search trapdoor may include: In step S32, the cloud server receives the search trapdoor. The request query.

[0057] In step S33, the cloud server performs a quick filtering check on the search trapdoor T using a Bloom filter to filter out invalid attributes in order to match the search trapdoor T with the encrypted index. The keywords in the text, where Bloom filters are used hash functions and Bit array.

[0058] In step S34, after the matching filter passes, the cloud server extracts the encrypted index that matches the search trap T and converts it into verifiable structured data.

[0059] In step S35, the smart contract filters the attribute keys issued by the trusted management center in the structured data to prevent access by forged keys or revoked keys.

[0060] In step S36, based on the structured data corresponding to the selected attribute key, the hash of the encrypted index in the structured data is verified to be consistent with that stored on the consortium blockchain.

[0061] In step S37, in the case of consistency, the bilinear verification passes the verification of the consistency of the final encrypted access control policy matrix in the structured data and the ciphertext of the corresponding symmetric key. The ciphertext of the corresponding symmetric key and the encrypted medical data are determined according to the consistency of the ciphertext of the symmetric key.

[0062] In the present application, when verifying the search trapdoor, the cloud server can receive a request query of the search trapdoor T. After searching the trapdoor T, the cloud server can perform a quick filtering check on the search trapdoor T through a Bloom filter, so as to filter out invalid attributes, and the filtering check can match the search trapdoor T and the keywords in the encrypted index. After the matching filtering passes, the cloud server can extract the encrypted index matched with the search trapdoor T and convert it into verifiable structured data for subsequent verification. The smart contract can screen the attribute keys issued by the trusted management center in the structured data, so as to prevent access by fake keys or revoked keys. According to the structured data corresponding to the screened attribute keys, it can be verified whether the hash of the decrypted index in the structured data and the alliance chain storage are consistent, and in the case of consistency, the bilinear verification can pass the verification of the consistency of the final encrypted access control policy matrix in the structured data and the ciphertext of the corresponding symmetric key, so as to determine the ciphertext of the corresponding symmetric key and the encrypted medical data. In this way, the final encrypted access control policy matrix and the ciphertext of the corresponding key can be searched and verified through the search trapdoor.

[0063] In one embodiment of the present application, as shown in Figure 9 The process of decrypting the ciphertext of the symmetric key can include: In step S38, the data user decrypts the ciphertext of the encrypted symmetric key using the corresponding attribute key thereof.

[0064] In step S39, the symmetric key is obtained by decryption.

[0065] In step S40, the encrypted medical data is decrypted by the symmetric key obtained by decryption, and the additional authentication tag Tag is verified, and finally the plaintext of the medical data is recovered for the data user to access.

[0066] In the present application, when decrypting the medical data, the data user can decrypt the ciphertext of the encrypted symmetric key using the corresponding attribute key thereof. After decryption, the symmetric key can be obtained. After obtaining the symmetric key, the encrypted medical data can be decrypted by the symmetric key obtained by decryption, and the additional authentication tag can be verified, and in the case of verification, the plaintext of the medical data can be finally recovered for the data user to access.

[0067] In one embodiment of the present application, as shown inFigure 10 As shown, the process of verifying the attachment tag can include: In step S41, the plaintext of the decrypted medical data is obtained.

[0068] In step S42, a new attachment authentication tag is recalculated according to the plaintext of the medical data by the AES-GCM algorithm.

[0069] In step S43, it is verified whether the new attachment authentication tag matches the attachment authentication tag accompanying the encrypted medical data.

[0070] In step S44, in the case of matching, it is indicated that the medical data has not been tampered with.

[0071] In the present application, when verifying the attachment authentication tag, the plaintext of the decrypted medical data can be obtained first. After obtaining the plaintext, a new attachment authentication tag can be recalculated according to the plaintext of the medical data by the AES-GCM algorithm. After obtaining the new attachment authentication tag, it can be verified whether the new attachment authentication tag matches the attachment authentication tag accompanying the encrypted medical data, and in the case of matching, it can be indicated that the medical data has not been tampered with, and then the plaintext of the medical data can be restored.

[0072] Through the above technical solution, the fine-grained medical data sharing method provided by the present application generates public parameters and master keys through a trusted management center, and can assign attribute keys to data users according to the master keys, and then record the attribute information to a consortium chain. The data owner can generate a 256-bit symmetric key through a random number generator, and can encrypt the medical data using the symmetric encryption algorithm ASE-GCM, and can attach an authentication tag. An access policy based on a secret sharing matrix can be constructed, and a strategy matrix can be generated, and when encrypting the symmetric key, the encrypted strategy matrix can be embedded into the ciphertext of the symmetric key. After encrypting the medical data, the encrypted medical data can be stored to a cloud server, and the ciphertext of the encrypted symmetric key can be uploaded to the consortium chain. The data user can generate a search trapdoor according to its own attribute set, and can submit it to the cloud server. The cloud server can verify the search trapdoor, and in the case of passing the verification, the encrypted medical data and the ciphertext of the symmetric key can be returned to the data user. The data user can decrypt the ciphertext of the symmetric key through its own attribute key, and can further decrypt the encrypted medical data, so as to obtain the plaintext of the medical data. The sharing method can meet the requirements of data privacy, sharing credibility and high efficiency.

[0073] Those skilled in the art will appreciate that embodiments of the application can be readily used as software, hardware, or a combination of software and hardware. In a typical configuration, a computing device includes one or more processors (CPUs), input / output interfaces, network interfaces, and memory.

[0074] The computer program instructions can also be loaded onto a computer or other programmable data processing apparatus to cause a series of operational steps to be performed on the computer or other programmable apparatus to produce a computer-implemented process such that the instructions which execute on the computer or other programmable apparatus provide steps for implementing the functions specified in the flowchart block or blocks. Figure 1 The computer program instructions can also be loaded onto a computer or other programmable data processing apparatus to cause a series of operational steps to be performed on the computer or other programmable apparatus to produce a computer-implemented process such that the instructions which execute on the computer or other programmable apparatus provide steps for implementing the functions specified in the flowchart block or blocks. Figure 1 The computer program instructions can also be loaded onto a computer or other programmable data processing apparatus to cause a series of operational steps to be performed on the computer or other programmable apparatus to produce a computer-implemented process such that the instructions which execute on the computer or other programmable apparatus provide steps for implementing the functions specified in the flowchart block or blocks.

[0075] The computer program instructions can also be loaded onto a computer or other programmable data processing apparatus to cause a series of operational steps to be performed on the computer or other programmable apparatus to produce a computer-implemented process such that the instructions which execute on the computer or other programmable apparatus provide steps for implementing the functions specified in the flowchart block or blocks. Figure 1 The computer program instructions can also be loaded onto a computer or other programmable data processing apparatus to cause a series of operational steps to be performed on the computer or other programmable apparatus to produce a computer-implemented process such that the instructions which execute on the computer or other programmable apparatus provide steps for implementing the functions specified in the flowchart block or blocks. Figure 1 The computer program instructions can also be loaded onto a computer or other programmable data processing apparatus to cause a series of operational steps to be performed on the computer or other programmable apparatus to produce a computer-implemented process such that the instructions which execute on the computer or other programmable apparatus provide steps for implementing the functions specified in the flowchart block or blocks.

[0076] The computer program instructions can also be loaded onto a computer or other programmable data processing apparatus to cause a series of operational steps to be performed on the computer or other programmable apparatus to produce a computer-implemented process such that the instructions which execute on the computer or other programmable apparatus provide steps for implementing the functions specified in the flowchart block or blocks. Figure 1 The computer program instructions can also be loaded onto a computer or other programmable data processing apparatus to cause a series of operational steps to be performed on the computer or other programmable apparatus to produce a computer-implemented process such that the instructions which execute on the computer or other programmable apparatus provide steps for implementing the functions specified in the flowchart block or blocks. Figure 1 The computer program instructions can also be loaded onto a computer or other programmable data processing apparatus to cause a series of operational steps to be performed on the computer or other programmable apparatus to produce a computer-implemented process such that the instructions which execute on the computer or other programmable apparatus provide steps for implementing the functions specified in the flowchart block or blocks.

[0077] In a typical configuration, a computing device includes one or more processors (CPUs), input / output interfaces, network interfaces, and memory.

[0078] The memory can include non-persistent memory and / or volatile memory, such as random access memory (RAM) and / or cache memory, for storing, in general, data and / or program instructions. The memory can also include non-volatile memory, such as read-only memory (ROM), electrically programmable read-only memory (EPROM), or electrically erasable programmable read-only memory (EEPROM), for storing, in general, static data and / or program instructions. The memory can also include removable media, such as flash memory, for storing, in general, program instructions and / or data. The memory is an example of computer-readable media.

[0079] Computer-readable media includes permanent and non-permanent, movable and non-movable media that can be implemented by any method or technology to store information. The information can be computer-readable instructions, data structures, program modules or other data. Examples of computer storage media include, but are not limited to, phase change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technologies, compact disc read-only memory (CD-ROM), digital versatile disc (DVD) or other optical storage, magnetic cassette, magnetic tape disk storage or other magnetic storage devices, or any other non-transmission medium that can be used to store information accessible by a computing device. According to the definition herein, computer-readable media does not include transitory media such as modulated data signals and carriers.

[0080] It should also be noted that the terms "comprising", "containing", or any other variant thereof are intended to cover non-exclusive inclusions, so that a process, method, article or apparatus that includes a list of elements does not only include those elements, but also includes other elements not explicitly listed, or further includes elements inherent in such a process, method, article or apparatus. Without more limitations, the element defined by the statement "comprising a" does not exclude the presence of additional identical elements in the process, method, article or apparatus that includes the element.

[0081] The above only is an embodiment of the present application, and is not used to limit the present application. For those skilled in the art, the present application can have various changes and variations. Any modification, equivalent replacement, improvement, etc. within the spirit and principle of the present application shall be included in the scope of claims of the present application.

Claims

1. A fine-grained medical data sharing method, characterized in that, The sharing method comprises: The trusted management center generates public parameters and a master secret key, allocates an attribute secret key to each data user according to the master secret key, and records attribute information to a consortium chain; The data owner generates a 256-bit symmetric secret key, encrypts the medical data using a symmetric encryption algorithm, and attaches an authentication tag; An access policy based on a secret sharing matrix is constructed, and an encrypted policy matrix is generated, which is embedded into the ciphertext of the symmetric secret key when the symmetric secret key is encrypted; The encrypted medical data is stored to a cloud server, and the ciphertext of the encrypted symmetric secret key is uploaded to the consortium chain; The data user generates a search trapdoor according to an attribute set of the data user, and submits the search trapdoor to the cloud server; The cloud server verifies the search trapdoor; In the case of verification, the encrypted medical data and the ciphertext of the symmetric secret key are returned to the data user; The data user decrypts the ciphertext of the symmetric secret key through the attribute secret key of the data user, and further decrypts the encrypted medical data.

2. The sharing method of claim 1, wherein, The trusted management center generates public parameters and a master secret key, allocates an attribute secret key to each data user according to the master secret key, and records attribute information to a consortium chain, comprising: Defining a bilinear mapping where and is a prime number is an additive group, is a multiplicative group; Selecting a collision-resistant hash function for generating an attribute identifier and a key derivation, respectively, a set of integers representing a prime number q; The trusted management center selects random number generation related parameters and aggregates them through specific calculation to obtain public parameters, including: , a generation element , and a master key, wherein the public parameters are used to provide uniform cryptographic parameters for all participants to ensure that all participants use the same mathematical settings.

3. The sharing method of claim 2, wherein, The trusted management center generates public parameters and a master secret key, allocates an attribute secret key to each data user according to the master secret key, and records attribute information to a consortium chain, comprising: The trusted management center generates an attribute secret key for each data user according to the registration information, attributes and the master secret key of the data user, and distributes the attribute secret key to the corresponding data user through an encryption channel; The trusted management center generates a one-time session secret key when distributing the attribute secret key, and the consortium chain records the hash evidence of the secret key distribution; The trusted management center records the attribute information of the data user to the consortium chain to ensure the traceability and integrity of the information.

4. The sharing method of claim 1, wherein, An access policy based on a secret sharing matrix is constructed, and an encrypted policy matrix is generated, which is embedded into the ciphertext of the symmetric secret key when the symmetric secret key is encrypted, comprising: Assigning each attribute to a unique random index and only recording the random index in subsequent encryption processes; representing an access control policy as a raw access policy matrix wherein the elements of the matrix represent a relationship between the ith attribute and the jth access control rule ​ The noise truncation boundary is calculated by formula (1): Formula (1), wherein, denotes a noise scale, denotes a sensitivity, denotes a differential privacy parameter, denotes a noise truncation boundary, is a negligible probability, denotes an inverse error function, for noise truncation computation; generating a noise matrix by a pseudo-random number generator, and each element in the noise matrix needs to satisfy the condition: ; adding the noise matrix to the original access policy matrix to obtain a first encrypted matrix; for each element in the first encryption matrix, encrypting by an encryption function wherein denotes each element in the first encryption matrix, denotes an access policy; According to the encrypted elements, the final encrypted access control policy matrix is obtained: , wherein , ... denotes the encrypted element.

5. The sharing method of claim 4, wherein, An access policy based on a secret sharing matrix is constructed, and an encrypted policy matrix is generated, which is embedded into the ciphertext of the symmetric secret key when the symmetric secret key is encrypted, comprising: Obtain the attribute and calculate the corresponding encryption value through CP-ABE encryption algorithm wherein, denotes a generating element, denotes a random number, denotes an attribute CP-ABE encrypted ciphertext value; The symmetric key is acquired and encrypted by a CP-ABE encryption algorithm, and elements in the final encrypted access control policy matrix are embedded into the ciphertext during encryption to generate ciphertext of the symmetric key: , represents an encryption value of each attribute, represents an encryption of the symmetric secret key.

6. The sharing method of claim 5, wherein, The encrypted medical data is stored to a cloud server, and the ciphertext of the encrypted symmetric secret key is uploaded to the consortium chain, comprising: The medical data encrypted by the AES-GCM algorithm is stored to the cloud server; extracting a set of searchable keywords from the medical data and computing a collision hash for each keyword in the set of keywords wherein, generating a blinding factor, ; Generating encrypted index by ABSE algorithm wherein, is a public key transformation function of attribute , is a keyword associated access policy, is a randomized public key parameter for hiding the search structure of the keyword, is a blind encryption value of the keyword kw, and the binding master key (MSK) ensures security; Encrypting index With final encrypted access control policy matrix Associations; uploading the encrypted index uploading the ciphertext of the symmetric key and the hash of the encrypted index to a consortium chain.

7. The sharing method of claim 6, wherein, The data user generates a search trapdoor according to an attribute set of the data user, and submits the search trapdoor to the cloud server, comprising: Data users calculate the corresponding encryption value according to the attribute key of each attribute of themselves , according to the attribute secret key to calculate the corresponding encryption value ; According to the access policy, a searchable trapdoor is generated containing the encryption value of all attributes and the keyword wherein, denotes a searchable trapdoor component for matching the corresponding encrypted index I in the encrypted data j kw , denotes a digital signature;​ The search trapdoor is submitted to the cloud server for verification.

8. The sharing method of claim 7, wherein, The cloud server verifies the search trapdoor, comprising: The cloud server receives the request query for the search trapdoor ; The cloud server performs a quick filtering check on the search trapdoor T by a Bloom filter to filter out invalid attributes to match the search trapdoor T and the keywords in the encrypted index , wherein the Bloom filter employs hash functions and bit arrays; After the matching filter passes, the cloud server extracts the encrypted index matched with the search trapdoor T into verifiable structured data; The smart contract screens the attribute secret key issued by the trusted management center in the structured data to prevent access by a fake secret key or a revoked secret key; According to the structured data corresponding to the attribute key screened, verify whether the hash of the encrypted index in the structured data is consistent with the one stored on the alliance chain; In consistent case, bilinear verification passes verification with the corresponding final encrypted access control policy matrix in the structured data The ciphertext consistency with the symmetric key determines the ciphertext of the corresponding symmetric key and the encrypted medical data.

9. The sharing method of claim 8, wherein, The data user decrypts the ciphertext of the symmetric key through the attribute key corresponding to the data user, and further decrypts the encrypted medical data, including: The data user decrypts the ciphertext of the encrypted symmetric key through the attribute key corresponding to the data user; According to the decrypted symmetric key; The encrypted medical data is decrypted through the decrypted symmetric key, and the additional authentication tag Tag is verified, and finally the plaintext of the medical data is recovered for the data user to access.

10. The sharing method of claim 9, wherein, The additional authentication tag Tag is verified, including: The plaintext of the decrypted medical data is obtained; A new additional authentication tag is recalculated through the AES-GCM algorithm according to the plaintext of the medical data; Verify whether the new additional authentication tag and the additional authentication tag together with the encrypted medical data match; In the case of matching, it is indicated that the medical data is not tampered with.