Method for secure sharing of medical data and right ownership by policy full-hidden multi-attribute-based encryption (CP-ABE)

Abstract

This invention belongs to the field of medical information security and discloses a policy-hidden, multi-attribute authorization CP-ABE method for secure sharing of medical data and ownership. This method first establishes globally public parameters; multi-attribute authorization institutions generate public and private keys, classify and manage medical attributes, and establish redundant backups; and assigns exclusive attribute keys bound to the identity of data users. The data owner associates medical data with ownership beacons, constructs an access policy, and encrypts and generates complete ciphertext, while simultaneously constructing an attribute cuckoo filter. Data users, relying on their own identity attributes and exclusive keys, complete zero-knowledge proof verification, match the hidden access policy, and decrypt the ciphertext upon successful verification to obtain the original medical data. This invention integrates a multi-authorization architecture, an attribute cuckoo filter, and zero-knowledge proofs, solving the problems of centralized permissions, policy leakage, and unreliable ownership verification in traditional solutions. It meets the needs of secure sharing across institutions and has good practical value and application prospects.

Description

Technical Field

[0001] This invention relates to the field of medical information security technology, specifically to a method for secure sharing of medical data and ownership through CP-ABE (Content-Based Allocation and Behavior-Based) with fully hidden multi-attribute authorization. Background Technology

[0002] As a core foundational resource for public health prevention and control, precision medicine implementation, and life science research, the secure sharing of medical and health data across institutions can effectively reduce the cost of duplicate diagnosis and treatment and improve the efficiency of medical service collaboration. It is a key way to break down medical data barriers and achieve efficient resource utilization.

[0003] Cited Policy Attribute-Based Encryption (CP-ABE), with its fine-grained "one-to-many" authorization advantage, has become an ideal technology for solving flexible access control in cross-institutional data sharing and is widely used in health information systems. However, traditional CP-ABE solutions still have many technical shortcomings in actual medical collaboration scenarios: their single-authorization institution model not only poses risks of single-point trust and key escrow, but also cannot adapt to the needs of large attribute domain expression and cross-institutional attribute key management; at the same time, storing access policies in plaintext is extremely easy to leak patient information and medical privacy, while existing policy hiding schemes generally suffer from high computational overhead and are unable to resist access pattern analysis attacks; in addition, the schemes generally lack a data ownership verification mechanism before decryption, making it difficult to guarantee the authenticity and compliance of the ciphertext source. Even attempts to combine it with zero-knowledge proofs have not yet formed a feasible solution for deep integration with CP-ABE. As a result, existing medical data sharing solutions cannot simultaneously meet the core requirements of multi-institutional collaboration trust, full access policy hiding, and ownership confirmation before decryption, making it difficult to adapt to the high security and high privacy application requirements of medical scenarios.

[0004] To address this, we have introduced a multi-authorized institution CP-ABE and zero-knowledge proof-based medical data security sharing model, thereby resolving the core pain points of existing technologies. Summary of the Invention

[0005] To address the above technical problems, this invention provides a method for securely sharing CP-ABE medical data and ownership with full policy concealment and multi-attribute authorization. The method includes the following steps: S1. Obtain security parameters, generate bilinear pairs, cyclic groups, and generators based on these parameters; implement identity mapping and compatibility with large attribute domains by defining a hash function, and finally output globally public parameters. S2. Based on the globally public parameters, each attribute authorization agency randomly selects private parameters and generates its own public and private keys. These are then managed according to the medical attribute type. For each medical attribute, a multi-agency association is implemented, the management authority of each associated agency is clarified, and a redundant backup mechanism is established. S3. Data users submit a key application containing identity identifiers and attribute sets. Authorizing institutions combine their own private keys, globally public parameters, and user information to generate exclusive attribute keys that are bound to the user's identity. S4. The data owner associates the original medical data with the ownership beacon, constructs a linear secret sharing scheme access strategy, selects parameters to encrypt data based on globally public parameters, and generates complete ciphertext. S5. For the access strategy, extract each attribute and its corresponding identifier information, perform hash operation and randomization, determine the storage location through a configurable hash function family, use a multi-table expansion mechanism to handle conflicts, and generate an attribute cuckoo filter. S6. The data user generates a zero-knowledge proof based on their own identity, attribute set, and exclusive attribute key. The data user calls the globally public parameters, ownership beacon, and the attribute cuckoo filter to verify the matching of the zero-knowledge proof and user attributes with the hidden access policy. After passing the verification, the user decrypts the ciphertext with the exclusive key to obtain the original medical data.

[0006] As a further improvement of the present invention, step S1 specifically includes the following steps: Obtain security parameters Generate non-degenerate bilinear pairs Cyclic group and The order is a prime number Generator ; The hash functions are of two types: , ; Among them, Used for mapping identity identifiers to circular groups. Used to map cross-institutional medical attribute strings to To achieve compatibility with large attribute domains; The output of globally public parameters is as follows: .

[0007] As a further improvement of the present invention, step S2 specifically includes the following steps: Authorization agencies for various attributes ,exist Randomly select private parameters , Calculate the public and private keys: ; The scope of responsibility is divided according to the type of medical attribute, and each type of medical attribute is assigned to at least two individuals. Joint management is implemented to ensure the allocation of resources among multiple agencies; The management authority of each affiliated institution includes receiving user key applications related to this attribute, calculating key components based on its own private key, and participating in collaborative processes for authorization verification. The redundancy backup mechanism specifically means that when any In the event of a failure or unavailability, data users can contact other associated entities of that medical attribute. Initiate a request to ensure service continuity.

[0008] As a further improvement of the present invention, step S3 specifically includes the following steps: The key application submitted by the data user contains a unique identifier. and attribute set Each attribute authorization agency According to attributes Selecting random numbers from the generated data Calculate the key components: ; The key is concatenated to form a unique attribute key that is bound to the user's identity. .

[0009] As a further improvement of the present invention, step S4 specifically includes the following steps: The data owner records the original shared medical data as The ownership beacon is marked as ,in Includes the owner's identity information, data Description information.

[0010] Develop access policies , for A linear secret sharing matrix of dimension 1. The number of rows in the matrix. The number of columns in the matrix; A mapping function between matrix rows and medical attributes. Random selection ; Let vector , ,calculate and ,in yes The OK, Is s relative to the first Line sharing, It is 0 relative to the first Line sharing; for each line The data owner selects the encrypted random factor. Calculate the ciphertext components. Calculate the core encrypted components of the data: The ownership-bound ciphertext component is calculated, and the original data, ownership beacon, and master key are fused and bound together to ensure traceability of data ownership. ; Calculate the ciphertext component for multi-authorized agency collaborative verification, and fuse the master key shared value with the private key parameters of the authorized agencies to achieve multi-agency collaborative encryption verification: Calculate the inverse ciphertext components of the random factor: ciphertext components for verifying the legitimacy of the computing organization and shared values: Calculate attribute matching to verify ciphertext components: ; Finally, the ciphertext is output: .

[0011] As a further improvement of the present invention, step S5 specifically includes the following steps: Define the target access strategy and input the corresponding LSSS matrix parameters. Initialize the cuckoo attribute filter to an empty state; Based on the input matrix parameters Extract all attributes from the access policy. , ..., At the same time, associate the matrix row numbers corresponding to each attribute. , serving as a unique identifier for the attribute; For each attribute And its corresponding identifier row number i, construct the combined element Perform a hash operation on the core attributes of the element to obtain a unique hash value. ; The hash value is processed using the XOR partitioning algorithm. Perform randomization to generate Independent random partitions ; Calling configurable hash function family Each random shard is assigned an independent candidate bucket location, so that shards with the same attribute are distributed and mapped to different storage buckets, thereby achieving attribute privacy hiding; If a bucket position conflict occurs during the insertion of shards into a storage bucket, the remaining shards that could not be inserted normally are stored by creating a new empty filter table through a multi-table expansion method. Configure independent hash seeds for each newly created extended filter table to make the mapping rules between the filter tables independent of each other, reduce the probability of bucket collisions and prevent access pattern association attacks. After completing all attribute shard insertions and conflict resolution, the final attribute cuckoo filter is generated. Finally, the data owner will encrypt the text. Upload it along with the completed attribute cuckoo filter and store it on the shared cloud service platform.

[0012] As a further improvement of the present invention, in step S6, the zero-knowledge proof generation, blockchain notarization and verification process is specifically as follows: Without disclosing the original medical data and master key, the data owner randomly selects two sets of random parameters and calculates the commitment value, challenge value and two sets of response values ​​through bilinear pairing and hash operations to generate a zero-knowledge proof. The data owner stores the ownership-binding ciphertext component, zero-knowledge proof, and ownership beacon together in the complete ciphertext on the blockchain; As the data user acting as the verifier, the user requests the complete ciphertext and attribute cuckoo filter from the shared cloud service platform. The user queries and reads the evidence information corresponding to the ciphertext component bound to the ownership from the blockchain. After confirming that the shared object pointed to by the ownership beacon is itself, the user recalculates the challenge value through hash operation and verifies that the complete ciphertext contains a legitimate ownership beacon that is consistent with the on-chain evidence. If the verification is successful, the ownership beacon is determined to be genuine and valid.

[0013] As a further improvement to the present invention, the process of attribute matching, data decryption, and final ownership verification is as follows: Data users use the attribute matching algorithm of the attribute cuckoo filter to verify whether their own medical attributes meet the access strategy of the linear secret sharing scheme. If the attributes do not match, an invalid result is returned. If the attributes match, the coefficient parameters that meet the conditions for linear secret sharing matrix operation are selected. Data users perform bilinear pairing integration operations on each component of the complete ciphertext based on their own exclusive attribute key to restore the master key encryption parameters, and then decrypt the data by performing inverse operations on the core ciphertext components and the master key encryption parameters. Data users first verify the consistency of the ownership binding ciphertext component with the original medical data, ownership beacon, and master key. If the verification is successful, the ownership of the original medical data is confirmed to be legal and valid, and the original medical data is finally obtained.

[0014] Based on this, the present invention also provides a strategy-fully hidden multi-attribute authorized CP-ABE medical data and ownership security sharing system, which is used to implement the above-mentioned method; The system includes a multi-attribute authorization agency, a data owner's end, cloud services, blockchain, and a data user's end; The multi-attribute authorization authority is used to initialize and generate public-private key pairs, and generate exclusive attribute keys based on the data user's identity and attribute set; The data owner's end is used to combine access policies, original medical data and ownership beacons to encrypt and generate complete ciphertext, generate attribute cuckoo filters, generate zero-knowledge proofs, and upload the ownership binding component, zero-knowledge proof and ownership beacon in the ciphertext to the blockchain, and then store the complete ciphertext and attribute cuckoo filters in the cloud service. The cloud service is used to store the complete encrypted data and attribute cuckoo filter uploaded by the data owner, for data users to access; The blockchain is used to store zero-knowledge proofs, ownership beacons, and encrypted evidence uploaded by data owners, providing on-chain trusted verification evidence; The data user terminal is used to obtain the complete encrypted text and attribute cuckoo filter from the cloud service, read the evidence information from the blockchain and verify the matching of zero-knowledge proof, ownership beacon and its own attributes with the access policy. After the verification is successful, the encrypted text is decrypted using the exclusive attribute key to obtain the original medical data.

[0015] Based on this, a computer-readable storage medium stores a computer program that, when executed, performs the following steps: acquiring security parameters; generating bilinear pairs, cyclic groups, and generators based on these parameters; defining a hash function to achieve identity mapping and compatibility with large attribute domains, ultimately outputting globally public parameters; each attribute authorization agency randomly selecting private parameters based on the globally public parameters and generating its own public and private keys, managing them according to medical attribute types, implementing multi-agency association allocation for each medical attribute, clarifying the management authority of each associated agency, and establishing a redundant backup mechanism; data users submitting key applications containing identity identifiers and attribute sets; authorization agencies combining their own private keys, globally public parameters, and user information to generate exclusive attribute keys bound to the user's identity; data owners associating original medical data with ownership beacons, constructing a linear secret sharing scheme access strategy, selecting parameters based on globally public parameters to encrypt data, generating complete ciphertext; for the access strategy, extracting each attribute and corresponding identifier information, performing hash operations and randomized segmentation, determining the storage location through a configurable hash function family, handling conflicts using a multi-table expansion mechanism, and generating an attribute cuckoo filter. The data owner generates a zero-knowledge proof based on their own identity, attribute set, and exclusive attribute key. The data user calls globally public parameters, ownership beacons, and the attribute cuckoo filter to verify the matching of the zero-knowledge proof and user attributes with the hidden access policy. After passing the verification, the user decrypts the ciphertext with their exclusive key and obtains the original medical data.

[0016] Compared with the prior art, the beneficial effects of the present invention are as follows: This invention effectively solves the problems of centralized permissions, policy leakage, and untrusted ownership verification in traditional medical data sharing schemes by combining a multi-attribute authorization agency architecture, an improved attribute cuckoo filter, zero-knowledge proofs, and blockchain notarization. It achieves decentralized fine-grained access control, fully hidden access policies, and trusted zero-knowledge ownership verification for cross-institutional medical data. While ensuring the privacy and security of medical data, it completes efficient, secure, and reliable cross-institutional data sharing, and has good practical value and application prospects. Attached Figure Description

[0017] To more clearly illustrate the technical solution of the present invention, the drawings used in the embodiments are briefly introduced below. Obviously, the drawings described below are only some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0018] Figure 1 This is a flowchart of the medical data sharing method in an embodiment of the present invention; Figure 2 This is a diagram illustrating the LSSS matrix to ACF processing procedure according to an embodiment of the present invention. Figure 3 This is a schematic diagram of the attribute cuckoo filter according to an embodiment of the present invention; Figure 4 This is a block diagram of the medical data sharing system in an embodiment of the present invention; Figure 5 The attribute insertion time under different fragment numbers and bucket capacities in the embodiments of the present invention. Figure 6 The attribute matching time under different numbers of fragments in the embodiments of the present invention Figure 7 This is a test of the zero-knowledge proof generation time in an embodiment of the present invention. Figure 8 This is a test of the zero-knowledge proof verification time in the embodiments of the present invention; Figure 9 Encryption time overhead under different attribute sizes and message sizes in embodiments of the present invention. Figure 10 This refers to the decryption time overhead under different attribute sizes and message sizes in the embodiments of the present invention; Figure 11 This is a schematic diagram of a cuckoo filter in current technology. Detailed Implementation

[0019] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0020] It should be noted that, unless otherwise defined, the technical or scientific terms used in the embodiments of this disclosure should have the ordinary meaning understood by one of ordinary skill in the art to which this disclosure pertains. The terms "first," "second," and similar terms used in the embodiments of this disclosure do not indicate any order, quantity, or importance, but are merely used to distinguish different components. Terms such as "comprising" or "including" mean that the element or object preceding the word encompasses the elements or objects listed following the word and their equivalents, without excluding other elements or objects. Terms such as "connected" or "linked" are not limited to physical or mechanical connections, but can include electrical connections, whether direct or indirect. Terms such as "upper," "lower," "left," and "right" are used only to indicate relative positional relationships; when the absolute position of the described object changes, the relative positional relationship may also change accordingly.

[0021] First, some technical terms used in this invention will be explained: 1) Assumptions on the q-parallel BDHE difficult problem The difficult problem hypothesis is a mathematical hypothesis widely used to prove the security of cryptographic schemes based on bilinear mappings. It is mainly used to analyze the security of cryptographic systems in the presence of adversaries.

[0022] set up and G is a multiplicative cyclic group of order p with two prime numbers p. generators, bilinear mappings Random selection , Public vectors Given a probabilistic multinomial-time algorithm, send a vector Y and its elements... Algorithm judgment or for A random element R in the array. If... If the condition is met, the algorithm outputs 0; otherwise, it outputs 1. Advantages of the algorithm in solving the q-parallel BDHE problem. as follows: If there is no non-negligible advantage of polynomial-time algorithms Lower Division and random elements If the condition is met, then the hypothesis of a difficult q-parallel BDHE problem holds.

[0023] 2) LSSS linear secret sharing Let the access strategy be defined by a matrix. and mapping function constitute. matrix line number Mapping to property .make , It is a random element. Regarding the secret sharing scheme A vector consisting of shared shares Secretly shared shares Assigned to property If the user attribute set satisfies the authorization structure, it can be achieved through a set of weights. Reconstructing the secret .

[0024] 3) Cuckoo Filter and the Properties of This Article Cuckoo Filter The Cuckoo Filter (CF) is a data structure based on CuckooHash, serving as an alternative to the Bloom Filter (BF). CF does not store the entire element, but only its fingerprint information. This retains the advantages of BF in handling near-perfect member queries while providing better query efficiency and space utilization. The basic principle of CF is to map elements to two locations in a hash table and store the element's fingerprint in one of those locations. When querying whether an element is in the set, CF checks if the element's fingerprint exists in either of the element's two corresponding buckets. If it does, the element is in the set; otherwise, it is not. Figure 11 As shown in the image.

[0025] Figure 11 This is a CF (Cross-Complete) operation process with 8 buckets, each containing 3 lines. CF uses a hash function. fingerprint hash function calculate and Get the positions of two buckets. Check if either of these two candidate buckets is free. If both buckets are free, then... Insert into an empty bucket. If both candidate buckets are occupied, randomly select one bucket from the CF and use it as the reference. Replace the fingerprint of data y in this bucket. Then, randomly select a bucket in CF and... Insert the bucket into this group.

[0026] However, the design goal of traditional CF is mainly focused on improving data retrieval efficiency. Its storage elements only reflect the existence of members, which cannot meet the needs of access policy privacy protection and attribute hiding verification in data sharing systems.

[0027] To address this, this paper proposes an Attribute Cuckoo Filter (ACF) based on the traditional Cuckoo Filter. ACF generates fragmentable encrypted elements by structurally concatenating row numbers and attribute values ​​in the access policy matrix, thereby achieving attribute matching and verification without exposing the specific attribute content. Compared to traditional CF, ACF can hide attribute correspondences during access control and policy verification, significantly enhancing the system's privacy and policy security.

[0028] 4) Non-interactive zero-knowledge proofs Zero-knowledge proof is a cryptographic privacy-preserving technique that allows a prover to demonstrate to a verifier that they know certain information or facts without revealing any specific details. Zero-knowledge proofs can be divided into interactive and non-interactive types. Non-interactive zero-knowledge proofs are more efficient because they do not require multiple rounds of interaction. This paper constructs a non-interactive zero-knowledge proof scheme, which mainly includes the following steps: Initialize the system and generate system parameters. .

[0029] The prover will provide system parameters and As input, first select randomly. calculate and Secondly, the prover calculates... and Finally, the prover will and Send to the verifier without revealing the information. In the case of proving that he knew .in yes Zero-knowledge proofs.

[0030] The verifier will use the system parameters and Substitute this into the equation. If true, it indicates that the prover is... The holder of. 5) Multi-attribute authorization agencies: Different cross-domain medical institutions have their own attribute authorization agencies. Different attribute authorization agencies manage the attribute set of their respective attribute domains and are responsible for distributing attribute keys that satisfy their respective attribute domains.

[0032] The data owner can be either the owner of the medical data (patient) or the manager of the medical data (medical management institution). They formulate fine-grained access policies, construct ownership beacons containing the identity of the medical data source owner and data source metadata, and encrypt the data source and ownership beacons to obtain shared ciphertext data. Then, using the ACF fully hidden access policy, the shared ciphertext C and the fully hidden access policy are shared and stored via cloud services. Finally, the data owner generates a zero-knowledge proof containing the ownership beacon within the ciphertext and stores the ownership beacon and zero-knowledge proof on the blockchain for evidence.

[0033] Data users: These are the users of medical data. They possess a cross-institutional attribute set associated with the attribute key. They can request the cloud service to obtain shared ciphertext and a fully hidden access policy, and determine whether the attribute set satisfies the fully hidden access policy. If so, they decrypt using the attribute set. Furthermore, before decryption, they must read the ownership beacon and zero-knowledge proof from the blockchain, and use the zero-knowledge proof to verify that the shared ciphertext data contains the on-chain ownership beacon they read, confirming that the beacon owner is the data owner with whom they intend to share the data source.

[0034] Blockchain: Securely and reliably stores ownership beacons and zero-knowledge proofs, ensuring the immutability of ownership beacons and their zero-knowledge proofs, and guaranteeing the credibility and traceability of ownership verification.

[0035] Cloud services: cross-organizational shared storage for encrypted data and fully hidden access policies.

[0036] To make the above-mentioned objects, features and advantages of the present invention more apparent and understandable, the present invention will be further described in detail below with reference to the accompanying drawings and specific embodiments.

[0037] Example 1 As the background technology shows, traditional CP-ABE solutions in actual medical collaboration scenarios adopt a single-authorization institution model, which not only has single-point trust and key escrow risks, but also cannot adapt to the needs of large attribute domain expression and cross-institutional attribute key management. At the same time, the access policy is stored in plaintext, which is extremely easy to leak patients' medical conditions and medical privacy. Existing policy hiding solutions generally suffer from high computational overhead and cannot resist access pattern analysis attacks. In addition, the solutions generally lack a data ownership verification mechanism before decryption, making it difficult to ensure the authenticity and compliance of the encrypted source. Even if attempts are made to combine it with zero-knowledge proof, a feasible solution that is deeply integrated with CP-ABE has not yet been formed. As a result, existing medical data sharing solutions cannot simultaneously meet the core requirements of multi-institutional collaboration trust, full access policy hiding, and ownership confirmation before decryption, and are difficult to adapt to the high security and high privacy application requirements of medical scenarios.

[0038] Specifically, please refer to Figures 1-3 The preferred embodiment of the present invention, a strategy for fully hiding multi-attribute authorization of CP-ABE medical data and secure sharing of ownership, includes the following steps: S1. Obtain security parameters, generate bilinear pairs, cyclic groups, and generators based on these parameters; implement identity mapping and compatibility with large attribute domains by defining a hash function, and finally output globally public parameters.

[0039] Specifically, step S1 includes the following steps: Obtain security parameters Generate non-degenerate bilinear pairs: Cyclic group and The order is a prime number Generator ; Hash functions are of two types: , ; in, Used for mapping identity identifiers to circular groups. Used to map cross-institutional medical attribute strings to To achieve compatibility with large attribute domains; The output of globally public parameters is as follows: .

[0040] In this step, by constructing bilinear pairings and two types of dedicated hash functions, the standardized generation of basic cryptographic components is completed, realizing a unified mapping between identity identifiers and cross-institutional medical attributes. At the same time, it is compatible with the expansion needs of large-scale and multi-type medical attributes, providing core cryptographic foundations and global parameter support for subsequent multi-authorized institution key generation, data encryption and attribute matching.

[0041] S2. Each attribute authorization agency randomly selects private parameters based on globally public parameters and generates its own public and private keys. These are then managed according to the type of medical attribute. For each medical attribute, a multi-agency association is implemented, the management authority of each associated agency is clearly defined, and a redundant backup mechanism is established.

[0042] Specifically, step S2 includes the following steps: Authorization agencies for various attributes ,exist Randomly select private parameters , Calculate the public and private keys: ; The scope of responsibility is divided according to the type of medical attribute, and each type of medical attribute is assigned to at least two individuals. Joint management is implemented to ensure the allocation of resources among multiple agencies; The management authority of each affiliated institution includes receiving user key applications related to this attribute, calculating key components based on its own private key, and participating in collaborative processes for authorization verification. The redundancy backup mechanism specifically means that when any In the event of a failure or unavailability, data users can contact other associated entities of that medical attribute. Initiate a request to ensure service continuity.

[0043] In this step, a decentralized key management architecture is constructed by collaboratively generating public-private key pairs through multi-attribute authorization institutions, classifying and managing medical attributes, and associating and distributing keys with multiple institutions. This eliminates single points of failure and key custody risks associated with a single authorization institution. At the same time, a redundant backup mechanism ensures the continuity of system services, providing reliable institutional support for cross-institutional attribute key distribution and authorization verification.

[0044] S3. Data users submit a key application containing an identity identifier and attribute set. The authorizing agency combines its own private key, globally public parameters, and user information to generate a unique attribute key bound to the user's identity.

[0045] Step S3 specifically includes the following steps: The key application submitted by the data user contains a unique identifier. and attribute set Each attribute authorization agency According to attributes Selecting random numbers from the generated data Calculate the key components: ; The key is concatenated to form a unique attribute key that is bound to the user's identity. .

[0046] In this step, a unique attribute key bound to the identity of the data user is generated, which realizes a strong association between the key and the user's identity and medical attributes, and prevents key misuse and unauthorized authorization. At the same time, the key components are calculated collaboratively by multiple authorized institutions to meet the key generation requirements of cross-institutional medical attributes, and to provide exclusive key support for subsequent data decryption and identity verification.

[0047] S4. The data owner associates the original medical data with the ownership beacon, constructs a linear secret sharing scheme access strategy, selects parameters based on globally public parameters to encrypt the data, and generates complete ciphertext.

[0048] Step S4 specifically includes the following steps: The data owner records the original shared medical data as The ownership beacon is marked as ,in Includes the owner's identity information, data Description information.

[0049] Develop access policies , for A linear secret sharing matrix of dimension 1. The number of rows in the matrix. The number of columns in the matrix; A mapping function between matrix rows and medical attributes. Random selection ; Let vector , ,calculate and ,in yes The OK, Is s relative to the first Line sharing, It is 0 relative to the first Line sharing; for each line The data owner selects the encrypted random factor. Calculate the ciphertext components. Calculate the core encrypted components of the data: The ownership-bound ciphertext component is calculated, and the original data, ownership beacon, and master key are fused and bound together to ensure traceability of data ownership. ; Calculate the ciphertext component for multi-authorized agency collaborative verification, and fuse the master key shared value with the private key parameters of the authorized agencies to achieve multi-agency collaborative encryption verification: Calculate the inverse ciphertext components of the random factor: ciphertext components for verifying the legitimacy of the computing organization and shared values: Calculate attribute matching to verify ciphertext components: ; Finally, the ciphertext is output: .

[0050] In this step, the binding encryption of raw medical data and ownership beacons is achieved through LSSS access policy construction and multi-component ciphertext generation. This supports fine-grained access control for complex cross-institutional medical attributes and integrates parameters from multiple authorized institutions to complete collaborative encryption. This provides a structurally complete, secure, and controllable ciphertext foundation for subsequent ownership verification, attribute matching, and data decryption.

[0051] S5. Based on the access strategy, extract each attribute and its corresponding identifier information, perform hash operation and randomization partitioning, determine the storage location through a configurable hash function family, use a multi-table expansion mechanism to handle conflicts, and generate an attribute cuckoo filter. Step S5 specifically includes the following steps: Define the target access strategy and input the corresponding LSSS matrix parameters. Initialize the cuckoo attribute filter to an empty state; Based on the input matrix parameters Extract all attributes from the access policy. , ..., At the same time, associate the matrix row numbers corresponding to each attribute. , serving as a unique identifier for the attribute; For each attribute And its corresponding identifier row number i, construct the combined element Perform a hash operation on the core attributes of the element to obtain a unique hash value. ; The hash value is processed using the XOR partitioning algorithm. Perform randomization to generate Independent random partitions ; Calling configurable hash function family Each random shard is assigned an independent candidate bucket location, so that shards with the same attribute are distributed and mapped to different storage buckets, thereby achieving attribute privacy hiding; If a bucket position conflict occurs during the insertion of shards into a storage bucket, the remaining shards that could not be inserted normally are stored by creating a new empty filter table through a multi-table expansion method. Configure independent hash seeds for each newly created extended filter table to make the mapping rules between the filter tables independent of each other, reduce the probability of bucket collisions and prevent access pattern association attacks. After completing all attribute shard insertions and conflict resolution, the final attribute cuckoo filter is generated. Finally, the data owner will encrypt the text. Upload it along with the completed attribute cuckoo filter and store it on the shared cloud service platform.

[0052] In summary, unlike traditional CF, the attribute cuckoo filter (ACF) of this invention does not directly insert the entire element, but instead performs multiple randomized partitions and distributed storage of attribute information. The system first represents the access structure as an LSSS matrix. Each row corresponds to one attribute. The line number is represented as ACF for elements The attribute part calculates the hash value. And generated by XOR partitioning random portions Each of these corresponds to an independent candidate bucket position, as shown in Table 1. Table 1- algorithm The location of each bucket is determined by a configurable family of hash functions. This decision ensures that copies with the same attribute are distributed and mapped to different buckets, achieving attribute-level randomization and hiding. If a bucket conflict occurs during insertion, such as... Figure 3 As shown, ACF no longer uses the traditional cuckoo filter's eviction mechanism. Instead, it expands by creating new empty filter tables to store the remaining copies that cannot be inserted. This multi-table expansion method ensures the integrity and security of the original copies, avoiding data corruption and policy leakage caused by eviction operations. Simultaneously, different filter tables use independent hash seeds, ensuring independent mapping between tables, thereby further reducing the probability of bucket collisions and preventing access pattern associations.

[0053] In this step, an attribute cuckoo filter is generated through hashing, random sharding, and multi-table expansion mechanisms to achieve fully hidden storage of LSSS access policies, avoiding the leakage of medical privacy in plaintext, while reducing the probability of bucket collisions and resisting access pattern attacks. Under the premise of ensuring attribute matching efficiency, it provides core privacy protection components for subsequent hidden policy verification.

[0054] S6. The data owner generates a zero-knowledge proof based on their own identity, attribute set, and exclusive attribute key. The data user calls globally public parameters, ownership beacons, and attribute cuckoo filters to verify the matching of the zero-knowledge proof and user attributes with the hidden access policy. After passing the verification, the user decrypts the ciphertext with their exclusive key and obtains the original medical data.

[0055] In step S6, the zero-knowledge proof generation, blockchain storage and verification process is as follows: Without disclosing the original medical data and master key, the data owner randomly selects two sets of random parameters and calculates the commitment value, challenge value and two sets of response values ​​through bilinear pairing and hash operations to generate a zero-knowledge proof. The data owner stores the ownership-binding ciphertext component, zero-knowledge proof, and ownership beacon together in the complete ciphertext on the blockchain; In the above steps, the data owner, in order to avoid disclosing data m and Under the premise of proving to data users that the ciphertext to be decrypted contains the data owner's ownership beacon. And the ownership beacon With on-chain evidence Consistent, its random selection Calculate commitment ,challenge ,response and .

[0056] Based on the system's bilinear pairing operation rules, the data owner calculates the commitment value. Its purpose is to mask the actual medical data and master key, ensuring that the verifier cannot deduce the sum through the proof parameters, thus achieving the zero-knowledge property. The formula is as follows: The data owner invokes the system's collision-resistant hash function, concatenates the encrypted ownership binding component with the commitment value, and then performs a hash operation to obtain the challenge value, as shown in the following formula: The data owner combines temporary random numbers with the actual core parameters to calculate two sets of response values, as shown in the following formula: The response value deeply binds the random number, challenge value, and core privacy parameters. Verifiers can use the response value to complete the legitimacy verification, but cannot reverse the process to obtain m and s, thus strictly protecting the confidentiality of medical data and keys.

[0057] Output zero-knowledge proof: .

[0058] At the same time, the data owner will encrypt the text In as well as , Store them together on the blockchain.

[0059] As the data user acting as the verifier, the user requests the complete ciphertext and attribute cuckoo filter from the shared cloud service platform. The user queries and reads the evidence information corresponding to the ciphertext component bound to the ownership from the blockchain. After confirming that the shared object pointed to by the ownership beacon is itself, the user recalculates the challenge value through hash operation and verifies that the complete ciphertext contains a legitimate ownership beacon that is consistent with the on-chain evidence. If the verification is successful, the ownership beacon is determined to be genuine and valid.

[0060] In the above steps, the data user requests encrypted data from the cloud service. And ACF, and determine from the chain whether it exists with If the stored evidence is equal, then read the information contained in the stored evidence. and Then check the ownership beacon. If the identity information recorded in the database is an object of data sharing, then perform a zero-knowledge proof challenge. Verify the equation Is it valid? If it is valid, then the ciphertext is valid. It does indeed contain ownership beacons. .

[0061] In step S6, the process of attribute matching, data decryption, and final ownership verification is as follows: Data users use the attribute matching algorithm of the attribute cuckoo filter to verify whether their own medical attributes meet the access strategy of the linear secret sharing scheme. If the attributes do not match, an invalid result is returned. If the attributes match, the coefficient parameters that meet the conditions for linear secret sharing matrix operation are selected. Data users perform bilinear pairing integration operations on each component of the complete ciphertext based on their own exclusive attribute key to restore the master key encryption parameters, and then decrypt the data by performing inverse operations on the core ciphertext components and the master key encryption parameters. Data users first verify the consistency of the ownership binding ciphertext component with the original medical data, ownership beacon, and master key. If the verification is successful, the ownership of the original medical data is confirmed to be legal and valid, and the original medical data is finally obtained.

[0062] In the above steps, the data user first uses the algorithm in Table 2 to determine the attribute key set { } corresponding attributes To determine if the data access structure is correct, the algorithm can verify whether the query attribute exists in the filter, based on attribute characteristics. As input, through a hash function Calculate candidate bucket index Extract the corresponding fragments from the filter table. and perform XOR The process is restored, ultimately completing the attribute matching verification and allowing the access strategy to be reconstructed. If it does not meet the requirements, return ⊥; otherwise, calculate. satisfy . , ,in , Then calculate Finally, the data source is output. .

[0063] Data users further verify Whether the equation holds true or not, if it does, further confirms that the ownership of the ciphertext m indeed belongs to the data owner.

[0064] Table 2- algorithm In this step, ownership verification is achieved before decryption through zero-knowledge proof and blockchain notarization. The attribute cuckoo filter is used to complete the hiding strategy matching. The encrypted text is decrypted by combining the exclusive attribute key. Without disclosing any privacy information, a secure closed loop of ownership verification, attribute matching and data decryption is achieved, ensuring the compliance and security of medical data sharing.

[0065] This invention effectively solves the problems of centralized permissions, policy leakage, and untrusted ownership verification in traditional medical data sharing schemes by combining a multi-attribute authorization agency architecture, an improved attribute cuckoo filter, zero-knowledge proofs, and blockchain notarization. It achieves decentralized fine-grained access control, fully hidden access policies, and trusted zero-knowledge ownership verification for cross-institutional medical data. While ensuring the privacy and security of medical data, it completes efficient, secure, and reliable cross-institutional data sharing, and has good practical value and application prospects.

[0066] It should be noted that the method of this disclosure embodiment can be executed by a single device, such as a computer or server. The method of this embodiment can also be applied to a distributed scenario, where multiple devices cooperate to complete the task. In such a distributed scenario, one of these devices may execute only one or more steps of the method of this disclosure embodiment, and the multiple devices will interact with each other to complete the method described.

[0067] It should be noted that the above description describes some embodiments of this disclosure. Other embodiments are within the scope of the appended claims. In some cases, it should be understood that the sequence number of each step in the above embodiments does not imply the order of execution; the execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of the present invention. The actions or steps recorded in the claims can be performed in a different order than that in the above embodiments and can still achieve the desired result. In addition, the processes depicted in the drawings do not necessarily require a specific or sequential order to achieve the desired result. In some embodiments, multitasking and parallel processing are also possible or may be advantageous.

[0068] Example 2 Based on this, please refer to Figure 4 The present invention also provides a strategy-based, fully hidden, multi-attribute authorized CP-ABE medical data and ownership security sharing system, which is used to implement the method in the above preferred embodiment; The system includes multi-attribute authorization agencies, data owner terminals, cloud services, blockchain, and data user terminals; A multi-attribute authorization authority is used to initialize and generate public-private key pairs, and to generate exclusive attribute keys based on the data user's identity and attribute set; On the data owner side, the system combines access policies, raw medical data, and ownership beacons to encrypt and generate complete ciphertext, generate attribute cuckoo filters, generate zero-knowledge proofs, and upload the ownership binding components, zero-knowledge proofs, and ownership beacons in the ciphertext to the blockchain. Finally, the complete ciphertext and attribute cuckoo filters are stored in the cloud service. Cloud services are used to store the complete encrypted data and attributed data uploaded by the data owner, making it available to data users. Blockchain is used to store zero-knowledge proofs, ownership beacons, and encrypted evidence uploaded by data owners, providing trusted on-chain verification evidence. On the data user side, it is used to obtain the complete encrypted text and attribute cuckoo filter from the cloud service, read the evidence information from the blockchain and verify the matching of zero-knowledge proof, ownership beacon and its own attributes with the access policy. After the verification is successful, the encrypted text is decrypted using the exclusive attribute key to obtain the original medical data.

[0069] In general, the working logic of this invention is as follows: The system first completes the global cryptographic parameter initialization, generates two types of hash functions: bilinear pairs, cyclic groups, generators, and adaptive identity mappings and large attribute domains, and outputs unified global public parameters to provide standardized cryptographic support for the entire process of key generation, data encryption, and verification operations; multi-attribute authorization institutions generate their own public-private key pairs based on the global public parameters, divide the management scope according to the medical attribute type, implement multi-institutional association allocation for each medical attribute and establish a redundancy backup mechanism, and then generate exclusive attribute keys strongly bound to the user's identity based on the identity identifier and attribute set submitted by the data user, thereby realizing decentralized cross-institutional attribute key distribution and management.

[0070] The data owner binds the original medical data with ownership beacons, constructs a refined access strategy based on a linear secret sharing scheme, and uses globally public parameters to select random parameters to encrypt the data, generating a complete ciphertext containing multiple components, including core data ciphertext, ownership binding ciphertext, and ciphertext for collaborative verification by multiple authorized institutions. Simultaneously, attribute and identification information is extracted for the access strategy, hashed, XORed, and randomly partitioned, then mapped to storage locations using a configurable hash function family. A multi-table expansion mechanism is used to handle bucket collisions, generating an attribute cuckoo filter to achieve complete concealment of the access strategy. Without disclosing the original data and master key, the data owner generates a zero-knowledge proof, stores the ownership binding ciphertext component, the zero-knowledge proof, and the ownership beacon on the blockchain for trusted storage, and then uploads the complete ciphertext and the attribute cuckoo filter to a cloud service platform for hosting.

[0071] Data users request the complete encrypted data and attribute cuckoo filter from the cloud service platform. They read the ownership and zero-knowledge proof notarization information from the blockchain to complete the zero-knowledge proof verification and ownership beacon authenticity verification. Then, through the matching algorithm of the attribute cuckoo filter, they verify whether their own attributes conform to the hidden linear secret sharing access strategy. After attribute matching, they select compliance coefficient parameters and use a dedicated attribute key to perform bilinear pairing integration operation on each component of the encrypted data to restore the encryption parameters, complete the data decryption and verify the legality of ownership. Finally, they securely obtain the original medical data and realize the privacy, compliance and trustworthiness sharing of cross-institutional medical data.

[0072] This arrangement allows the invention to address the vulnerabilities of centralized permissions, single points of failure, and key escrow issues inherent in traditional single-authorization institutions, thanks to multi-attribute authorization collaboration and redundant backup mechanisms. The attribute-based "cuckoo filter" ensures complete concealment of access policies, preventing the leakage of patient privacy through plaintext policies. Furthermore, the combination of zero-knowledge proofs and blockchain-based evidence storage for pre-decryption ownership verification overcomes the shortcomings of traditional solutions, such as the inability to verify the authenticity of encrypted sources and the vulnerability of data to forgery and tampering. Simultaneously, it meets the management needs of large attribute domains and cross-institutional medical attributes, ensuring secure and reliable key distribution, policy matching, ownership verification, and data decryption for cross-institutional sharing of medical data.

[0073] The system described in the above embodiments is used to implement the corresponding strategy of fully hiding multi-attribute authorization CP-ABE medical data and ownership security sharing method in any of the foregoing embodiments, and has the beneficial effects of the corresponding method embodiments, which will not be repeated here.

[0074] It should be noted that the above-mentioned strategy of fully hiding multi-attribute authorization in the CP-ABE medical data and ownership security sharing system is embodied in the form of functional units. The term "module" here can be implemented in software and / or hardware, without specific limitations.

[0075] For example, a "module" can be a software program, a hardware circuit, or a combination of both that implements the above functions. The hardware circuit may include an application-specific integrated circuit (ASIC), electronic circuitry, a processor (e.g., a shared processor, a proprietary processor, or a group processor) and memory for executing one or more software or firmware programs, integrated logic circuitry, and / or other suitable components that support the described functions.

[0076] Example 3 Based on the same inventive concept, this embodiment provides a strategy-fully hidden multi-attribute authorized CP-ABE medical data and ownership security sharing system. Please refer to [link / reference]. Figures 5-10 .

[0077] Specifically, all experiments in this embodiment were conducted on a computer running Ubuntu 18.04 with an AMD Ryzen / 9-7945HX processor and 16GB of RAM. The experimental model was built using the Python programming language. The experimental data were obtained by averaging the results of 100 repeated experiments under identical conditions.

[0078] First, to verify the construction efficiency of the attribute cuckoo filter ACF proposed in this invention, this paper tests its attribute insertion time under a fully hidden access strategy, thereby determining its performance in the system initialization and dynamic update stages. Figure 6The test results are presented. As shown in the figure, under different numbers of shards r and buckets, the attribute insertion time remains in the sub-millisecond range. Moreover, as the number of shards r and the structural complexity of buckets increase, the time increase is also slow. For example, when the number of shards r increases from 1 to 5, the single attribute insertion time increases from approximately 0.0054 μs to 0.0071–0.0072 μs, an increase of less than 0.002 μs. This indicates that the additional hash and bucket location computation costs brought by multi-shard mapping are low and do not significantly affect the system's real-time construction capability. In addition, from the perspective of insertion scale, when the number of buckets is 2, when the total number of attributes N increases from 3000 to 10000, the insertion time only fluctuates within the range of 5.8–6.3 μs, without obvious performance degradation. This shows that ACF has good load-bearing capacity during data scale growth, and the bucket capacity has a very limited impact on insertion performance.

[0079] Secondly, this paper tests the query performance of ACF to evaluate the matching performance before data decryption under fully hidden attributes. Figure 6 The test results are presented. As shown in the figure, since the matching operation mainly involves candidate bucket access and hash existence determination, its time complexity is nearly linearly related to the number of shards. Experimental results show that as the number of shards r increases, the single-attribute matching time steadily increases, but the overall fluctuation is small. Even under the high configuration conditions of r=8, 2 buckets, and a total number of attributes N=10000, the matching time is still controlled within the range of about 9.5μs, maintaining microsecond-level response capability. When the total number of attributes expands from 3000 to 10000, the matching time only shows a marginal increase. For example, under the condition of r=1, it increases from about 5.723μs to about 5.732μs, indicating that the query path length of ACF does not significantly expand with the data scale, and the structure search process remains stable. In addition, the bucket capacity parameter has a relatively limited impact on matching performance, and the time difference under different capacity settings is usually no more than 0.1μs.

[0080] Furthermore, the pre-decryption ownership confirmation in this paper is mainly achieved through zero-knowledge proofs. The zero-knowledge proof process mainly includes proof generation and verification, and the efficiency of both is primarily determined by the size of the data and the ownership beacon. Therefore, this paper tests the time overhead of proof generation and verification under different message lengths. Figure 7 This demonstrates the relationship between proof generation time and message length. Figure 8 This demonstrates the relationship between verification time and message length.

[0081] exist Figure 7In the graph, the horizontal axis represents the number of consecutive proofs generated in a single round of experiments, characterizing the average time intensity of proof generation under sustained load conditions. As can be seen from the graph, with the same amount of data, the proof generation time does not show a significant amplification effect as the number of consecutive proofs generated increases. Furthermore, it can be observed that even when the amount of data changes, the proof generation time does not change significantly. Figure 8 The tests also demonstrated the stability of the verification time. Under different execution counts and data volumes, the verification time of zero-knowledge proofs showed small fluctuations and strong overall consistency. The experiments indicated that the time for proof generation and verification is insensitive to changes in input size, and the algorithm complexity is primarily dominated by fixed-structure group and exponential operations, with low correlation to message bit length.

[0082] Finally, this paper tests the time cost of the proposed CP-ABE scheme under different data volumes and attribute conditions. Figure 9 As shown, changes in attribute size significantly impact the time overhead of the encryption phase. Specifically, encryption time generally increases with the increase in attribute size. This phenomenon indicates that the main computational overhead of the encryption process comes from exponential operations related to the number of attributes and the generation of ciphertext components, and its computational complexity is primarily driven by the size of the attribute set. In contrast, under a fixed attribute size, changes in data volume do not significantly affect encryption time, exhibiting strong overall stability. This suggests that the computational complexity of the encryption phase is mainly determined by operations related to accessing the structure, and there is no significant correlation between it and the plaintext length. Figure 10 As shown, compared to the encryption phase, the decryption process responds more smoothly to the increase in attribute size. Overall, the decryption time only shows a slow trend with the increase in attribute size, without a significant performance increase. This phenomenon indicates that although the expansion of attribute size introduces some computational overhead, the complexity increase in the decryption phase is relatively limited. The main reason is that the core computation of the decryption process is concentrated in bilinear pairing operations and a small number of exponential operations. The number of these operations is mainly determined by the access policy structure and attribute matching relationships, and does not expand linearly with the attribute size. Therefore, under large-scale attribute conditions, the system can still maintain stable decryption performance.

[0083] Example 4 Based on the same inventive concept, corresponding to the methods of any of the above embodiments, this disclosure also provides a non-transitory computer-readable storage medium storing computer instructions, which are used to cause the computer to execute the strategy-fully hidden multi-attribute authorized CP-ABE medical data and ownership security sharing method as described in any of the above embodiments.

[0084] The computer-readable medium of this embodiment includes permanent and non-permanent, removable and non-removable media, and information storage can be implemented by any method or technology. 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, CD-ROM, digital versatile optical disc (DVD) or other optical storage, magnetic tape, magnetic magnetic disk storage or other magnetic storage devices, or any other non-transfer medium that can be used to store information accessible by a computing device.

[0085] The computer instructions stored in the storage medium of the above embodiments are used to cause the computer to execute the strategy of fully hiding multi-attribute authorization CP-ABE medical data and ownership security sharing method as described in any of the above embodiments, and have the beneficial effects of the corresponding method embodiments, which will not be repeated here.

[0086] Those skilled in the art should understand that the discussion of any of the above embodiments is merely exemplary and is not intended to imply that the scope of this disclosure (including the claims) is limited to these examples; within the framework of this disclosure, the technical features of the above embodiments or different embodiments can also be combined, the steps can be implemented in any order, and there are many other variations of different aspects of the embodiments of this disclosure as described above, which are not provided in detail for the sake of brevity.

[0087] Additionally, to simplify the description and discussion, and to avoid obscuring the embodiments of this disclosure, the provided drawings may or may not show well-known power / ground connections to integrated circuit (IC) chips and other components. Furthermore, the apparatus may be shown in block diagram form to avoid obscuring the embodiments of this disclosure, and this also takes into account the fact that the details of implementation of these block diagram apparatuses are highly dependent on the platform on which the embodiments of this disclosure will be implemented (i.e., these details should be fully understood by those skilled in the art). While specific details (e.g., circuitry) have been set forth to describe exemplary embodiments of this disclosure, it will be apparent to those skilled in the art that the embodiments of this disclosure may be implemented without these specific details or with variations thereof. Therefore, these descriptions should be considered illustrative rather than restrictive.

[0088] Although this disclosure has been described in conjunction with specific embodiments thereof, many substitutions, modifications, and variations of these embodiments will be apparent to those skilled in the art from the foregoing description. For example, other memory architectures (e.g., dynamic RAM (DRAM)) may be used with the embodiments discussed.

[0089] Therefore, the units of the various examples described in the embodiments of this application can be implemented in electronic hardware, or a combination of computer software and electronic hardware. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

[0090] This disclosure is intended to cover all such substitutions, modifications, and variations that fall within the broad scope of the appended claims. Therefore, any omissions, modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this disclosure should be included within the scope of protection of this disclosure.

Claims

1. A method for securely sharing CP-ABE medical data and ownership with full strategy concealment and multi-attribute authorization, characterized in that: The method includes the following steps: S1. Obtain security parameters, generate bilinear pairs, cyclic groups, and generators based on these parameters; implement identity mapping and compatibility with large attribute domains by defining a hash function, and finally output globally public parameters. S2. Based on the globally public parameters, each attribute authorization agency randomly selects private parameters and generates its own public and private keys. These are then managed according to the medical attribute type. For each medical attribute, a multi-agency association is implemented, the management authority of each associated agency is clarified, and a redundant backup mechanism is established. S3. Data users submit a key application containing identity identifiers and attribute sets. Authorizing institutions combine their own private keys, globally public parameters, and user information to generate exclusive attribute keys that are bound to the user's identity. S4. The data owner associates the original medical data with the ownership beacon, constructs a linear secret sharing scheme access strategy, selects parameters to encrypt data based on globally public parameters, and generates complete ciphertext. S5. For the access strategy, extract each attribute and its corresponding identifier information, perform hash operation and randomization, determine the storage location through a configurable hash function family, use a multi-table expansion mechanism to handle conflicts, and generate an attribute cuckoo filter. S6. The data owner generates a zero-knowledge proof based on their own identity, attribute set, and exclusive attribute key. The data user calls the globally public parameters, ownership beacon, and the attribute cuckoo filter to verify the matching of the zero-knowledge proof and user attributes with the hidden access policy. After passing the verification, the user decrypts the ciphertext with the exclusive key and obtains the original medical data.

2. The method according to claim 1, characterized in that, Step S1 specifically includes the following steps: Obtain security parameters Generate non-degenerate bilinear pairs Cyclic group and The order is a prime number Generator ; The hash functions are of two types: 、 ； Among them, Used for mapping identity identifiers to circular groups. Used to map cross-institutional medical attribute strings to To achieve compatibility with large attribute domains; The output of globally public parameters is as follows: 。 3. The method according to claim 1, characterized in that, Step S2 specifically includes the following steps: Authorization agencies for various attributes ,exist Randomly select private parameters , Calculate the public and private keys: ； The scope of responsibility is divided according to the type of medical attribute, and each type of medical attribute is assigned to at least two individuals. Joint management is implemented to ensure the allocation of resources among multiple agencies; The management authority of each affiliated institution includes receiving user key applications related to this attribute, calculating key components based on its own private key, and participating in collaborative processes for authorization verification. The redundancy backup mechanism specifically means that when any In the event of a failure or unavailability, data users can contact other associated entities of that medical attribute. Initiate a request to ensure service continuity.

4. The method according to claim 1, characterized in that, Step S3 specifically includes the following steps: The key application submitted by the data user contains a unique identifier. and attribute set Each attribute authorization agency According to attributes Selecting random numbers from the generated data Calculate the key components: ； The key is concatenated to form a unique attribute key that is bound to the user's identity. 。 5. The method according to claim 1, characterized in that, Step S4 specifically includes the following steps: The data owner records the original shared medical data as The ownership beacon is marked as ,in Includes the owner's identity information, data Description information; Develop access policies , for A linear secret sharing matrix of dimension 1. The number of rows in the matrix. The number of columns in the matrix; This is a mapping function between matrix rows and medical attributes; Random selection ; Let vector , ,calculate and ,in yes The OK, Is s relative to the first Line sharing, It is 0 relative to the first Line sharing; for each line The data owner selects the encrypted random factor. Calculate the ciphertext components. Calculate the core encrypted components of the data: The ownership-bound ciphertext component is calculated, and the original data, ownership beacon, and master key are fused and bound together to ensure traceability of data ownership. ; Calculate the ciphertext component for multi-authorized agency collaborative verification, and fuse the master key shared value with the private key parameters of the authorized agencies to achieve multi-agency collaborative encryption verification: Calculate the inverse ciphertext components of the random factor: ciphertext components for verifying the legitimacy of the computing organization and shared values: Calculate attribute matching to verify ciphertext components: ; Finally, the ciphertext is output: 。 6. The method according to claim 1, characterized in that, Step S5 specifically includes the following steps: Define the target access strategy and input the corresponding LSSS matrix parameters. Initialize the cuckoo attribute filter to an empty state; Based on the input matrix parameters Extract all attributes from the access policy. , ..., At the same time, associate the matrix row numbers corresponding to each attribute. , serving as a unique identifier for the attribute; For each attribute And its corresponding identifier row number i, construct the combined element Perform a hash operation on the core attributes of the element to obtain a unique hash value. ; The hash value is processed using the XOR partitioning algorithm. Perform randomization to generate Independent random partitions ; Calling configurable hash function family Each random shard is assigned an independent candidate bucket location, so that shards with the same attribute are distributed and mapped to different storage buckets, thereby achieving attribute privacy hiding; If a bucket position conflict occurs during the insertion of shards into a storage bucket, the remaining shards that could not be inserted normally are stored by creating a new empty filter table through a multi-table expansion method. Configure independent hash seeds for each newly created extended filter table to make the mapping rules between the filter tables independent of each other, reduce the probability of bucket collisions and prevent access pattern association attacks. After completing all attribute shard insertions and conflict resolution, the final attribute cuckoo filter is generated. Finally, the data owner will encrypt the text. Upload it along with the completed attribute cuckoo filter and store it on the shared cloud service platform.

7. The method according to claim 1, characterized in that, In step S6, the zero-knowledge proof generation, blockchain storage and verification process is as follows: Without disclosing the original medical data and master key, the data owner randomly selects two sets of random parameters and calculates the commitment value, challenge value and two sets of response values ​​through bilinear pairing and hash operations to generate a zero-knowledge proof. The data owner stores the ownership-binding ciphertext component, zero-knowledge proof, and ownership beacon together in the complete ciphertext on the blockchain; As the data user acting as the verifier, the user requests the complete ciphertext and attribute cuckoo filter from the shared cloud service platform. The user queries and reads the evidence information corresponding to the ciphertext component bound to the ownership from the blockchain. After confirming that the shared object pointed to by the ownership beacon is itself, the user recalculates the challenge value through hash operation and verifies that the complete ciphertext contains a legitimate ownership beacon that is consistent with the on-chain evidence. If the verification is successful, the ownership beacon is determined to be genuine and valid.

8. The method according to claim 7, characterized in that, In step S6, the process of attribute matching, data decryption, and final ownership verification is as follows: Data users use the attribute matching algorithm of the attribute cuckoo filter to verify whether their own medical attributes meet the access strategy of the linear secret sharing scheme. If the attributes do not match, an invalid result is returned. If the attributes match, the coefficient parameters that meet the conditions for linear secret sharing matrix operation are selected. Data users perform bilinear pairing integration operations on each component of the complete ciphertext based on their own exclusive attribute key to restore the master key encryption parameters, and then decrypt the data by performing inverse operations on the core ciphertext components and the master key encryption parameters. Data users first verify the consistency of the ownership binding ciphertext component with the original medical data, ownership beacon, and master key. If the verification is successful, the ownership of the original medical data is confirmed to be legal and valid, and the original medical data is finally obtained.

9. The CP-ABE medical data and ownership security sharing system with fully hidden multi-attribute authorization is characterized by: It is used to implement the method according to any one of claims 1 to 8; The system includes a multi-attribute authorization agency, a data owner's end, cloud services, blockchain, and a data user's end; The multi-attribute authorization authority is used to initialize and generate public-private key pairs, and generate exclusive attribute keys based on the data user's identity and attribute set; The data owner's end is used to combine access policies, original medical data and ownership beacons to encrypt and generate complete ciphertext, generate attribute cuckoo filters, generate zero-knowledge proofs, and upload the ownership binding component, zero-knowledge proof and ownership beacon in the ciphertext to the blockchain, and then store the complete ciphertext and attribute cuckoo filters in the cloud service. The cloud service is used to store the complete encrypted data and attribute cuckoo filter uploaded by the data owner, for data users to access; The blockchain is used to store zero-knowledge proofs, ownership beacons, and encrypted evidence uploaded by data owners, providing on-chain trusted verification evidence; The data user terminal is used to obtain the complete encrypted text and attribute cuckoo filter from the cloud service, read the evidence information from the blockchain and verify the matching of zero-knowledge proof, ownership beacon and its own attributes with the access policy. After the verification is successful, the encrypted text is decrypted using the exclusive attribute key to obtain the original medical data.

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program that, when executed, performs the method described in any one of claims 1 to 8.

Images