Medical cloud data sharing method based on blockchain and privacy security traceable and revocable multi-attribute authoritative CP-ABE

Abstract

The invention discloses a medical cloud data sharing method based on a block chain and privacy security traceable and revocable multi-attribute authoritative CP-ABE. The method comprises the steps of multi-attribute authoritative mechanism collaboration, zero-knowledge proof identity authentication, hidden attribute value access strategy, accumulator encryption uplink and outsourcing decryption integrity verification. According to the invention, privacy protection and safe sharing of cross-institution medical data are realized.

Description

Technical Field

[0001] The present invention belongs to the field of medical data sharing, and in particular relates to a medical cloud data sharing method based on blockchain and privacy-safe, traceable and revocable multi-attribute authority CP-ABE. Background Art

[0002] With the development of medical informatization, cloud-based electronic health record (EHR) sharing has become an important means of improving healthcare service efficiency. Currently, medical data sharing systems primarily utilize centralized management architectures, with data access controlled by medical institutions or cloud service providers. This poses a single point of failure and the risk of internal data misuse. To enhance data security, researchers have proposed schemes based on attribute-based encryption (ABE), specifically ciphertext-policy attribute-based encryption (CP-ABE), which embeds access policies into ciphertext to achieve fine-grained access control. Furthermore, blockchain technology, due to its decentralized and tamper-proof properties, has been introduced into the medical data sharing field for recording access logs and policy identification to enhance transparency and cross-institutional trust. Existing schemes, such as multi-authorization authority CP-ABE and blockchain fusion technology, while achieving some functional progress, still have numerous limitations, such as key escrow issues with a single authorization authority, privacy risks associated with access policies, and inefficient decryption.

[0003] While existing technologies have addressed the security and flexibility issues of medical data sharing to some extent, they still have the following shortcomings: First, most CP-ABE schemes rely on a single attribute authority, resulting in single points of failure and key escrow risks. Furthermore, in scenarios with multiple authorities, a user's global identity (GID) may be jointly inferred by different authorities, leading to privacy leaks. Second, existing schemes often publicly store access policies along with ciphertext, exposing sensitive attribute information contained in the policies and posing privacy risks. Furthermore, the decryption process is computationally intensive. While some studies have introduced outsourced decryption mechanisms, these lack validation of the decryption results, potentially resulting in users receiving expired or erroneous medical data. Finally, existing schemes lack the capabilities for identity traceability and dynamic revocation, making them difficult to address the rights management requirements in complex medical environments. These issues limit the security, privacy, and practicality of medical data sharing systems. Summary of the Invention

[0004] To solve the above technical problems, the present invention proposes a medical cloud data sharing method based on blockchain and privacy-safe, traceable and revocable multi-attribute authority CP-ABE to solve the problems of "privacy leakage, insufficient access control flexibility and weak cross-institutional interoperability in medical cloud data sharing" in the above-mentioned existing technologies.

[0005] To achieve the above objectives, in a first aspect, the present invention provides a medical cloud data sharing method based on blockchain and privacy-safe, traceable, and revocable multi-attribute authority CP-ABE, comprising:

[0006] Generate medical public parameters through the identity authentication center and store them on the chain;

[0007] Based on the medical public parameters, multiple attribute authorities generate their own private and public keys, and upload the public keys to the chain;

[0008] The data user applies for a legal identity from the identity authentication center, and generates a private identity and zero-knowledge proof based on the legal identity;

[0009] The data user generates a user decryption key based on the private identity and submits a zero-knowledge proof to multiple attribute authorities to obtain the outsourced decryption key;

[0010] The data owner encrypts the medical data based on the access policy and on-chain parameters, where the attribute names are public but the attribute values ​​are hidden. The data owner generates ciphertext and stores it in the cloud service, while also uploading the data hash value to the chain.

[0011] The data user submits a zero-knowledge proof to the cloud service and requests outsourced decryption. The cloud service verifies the proof and performs a decryption test, returning a partial decryption result.

[0012] The data user uses the user decryption key to perform the final decryption of the partial decryption result and verifies the data integrity through the on-chain hash value;

[0013] When user permissions need to be revoked, the accumulator parameters are updated and broadcast through the identity authentication center, and the data owner re-encrypts the data based on the updated parameters.

[0014] Preferably, the steps of generating medical public parameters through the identity authentication center and storing them on the chain include:

[0015] Select the generator of the bilinear group through the identity authentication center and define the hash function;

[0016] Generate accumulator parameters through the identity authentication center, including accumulator value and verification parameters;

[0017] The system public parameters and accumulator parameters are stored on the chain through the identity authentication center.

[0018] Preferably, the steps of generating a private identity and a zero-knowledge proof include:

[0019] The data user obtains the legal identity ID and accumulator member parameters from the identity authentication center;

[0020] Construct private identity and zero-knowledge proof based on legal identity ID and accumulator member parameters.

[0021] Preferably, the step of obtaining the outsourced decryption key includes:

[0022] Data users submit their privacy identities and zero-knowledge proofs to attribute authorities;

[0023] The attribute authority verifies the validity of the zero-knowledge proof through an on-chain smart contract;

[0024] After verification, the attribute authority generates an outsourced decryption key based on the data user's attribute set and accumulator parameters.

[0025] Preferably, the step of encrypting the medical data includes:

[0026] The data owner obtains the public key of the medical public parameter and attribute authority from the blockchain;

[0027] The data owner constructs an access policy that contains only the attribute name and hides the attribute value;

[0028] Encrypt the data based on the access policy and the hash value of the accumulator parameter to generate ciphertext;

[0029] The data owner calculates the hash value of the data and stores it on the chain, and submits the ciphertext and on-chain hash address to the cloud service.

[0030] Preferably, the steps of performing the decryption test by the cloud service include:

[0031] The cloud service receives the data user's outsourced decryption request and zero-knowledge proof;

[0032] The cloud service verifies the validity of the zero-knowledge proof through the on-chain smart contract;

[0033] After verification, the cloud service performs a decryption test based on the outsourced decryption key and ciphertext to determine whether the attributes of the data user meet the access policy.

[0034] Preferably, the step of the cloud service returning a partial decryption result includes:

[0035] If the decryption test is successful, the cloud service calculates the partial decryption results;

[0036] The cloud service returns the partial decryption result to the data user.

[0037] Preferably, the step of performing final decryption on the partial decryption results includes:

[0038] The data user uses the user decryption key to finally decrypt the partial decryption result and obtain the plaintext data;

[0039] Calculate the hash value of the plaintext data and compare it with the original hash value stored on the chain to verify the data integrity.

[0040] Preferably, the step of revoking user rights includes:

[0041] Tracking real identities through data users based on private identities;

[0042] The accumulator parameters are updated by the data user and broadcast to the blockchain;

[0043] The data owner re-encrypts the data based on the updated accumulator parameters, making it impossible for the revoked user to decrypt the new ciphertext.

[0044] Preferably, the outsourced decryption key and the user decryption key are separated, wherein the outsourced decryption key is generated by the attribute authority and used for cloud service partial decryption; the user decryption key is independently generated by the data user and used for the final decryption partial decryption result.

[0045] Compared with the prior art, the present invention has the following advantages and technical effects:

[0046] This paper addresses key issues in medical cloud data sharing, such as privacy leakage, insufficient access control flexibility, and weak cross-institutional interoperability. It proposes a medical cloud data sharing solution that integrates blockchain with a secure, privacy-revocable, and multi-attribute authority (CP-ABE). By introducing dynamic cryptographic accumulators and zero-knowledge proofs, and separating attribute names from attribute values ​​in access policies, with only the attribute names being publicly disclosed, CP-ABE ensures identity anonymity while partially hiding access control policies, making user identities and attributes traceable and revocable, and enabling fine-grained dynamic management of decryption permissions.

[0047] To reduce the computational burden on terminal devices, the present invention further designs a secure and efficient outsourced decryption mechanism with decryption testing capabilities within the CP-ABE scheme. This mechanism also uses blockchain-based verification to ensure the validity and security of the final decryption result. Furthermore, by putting system public parameters and private identity authentication on the blockchain, the present invention achieves transparency, auditability, and cross-institutional trust and collaboration in the medical data sharing process. BRIEF DESCRIPTION OF THE DRAWINGS

[0048] The accompanying drawings, which constitute part of this application, are intended to provide a further understanding of this application. The exemplary embodiments and descriptions of this application are intended to explain this application and do not constitute an improper limitation on this application. In the accompanying drawings:

[0049] Figure 1 A schematic diagram of a system according to an embodiment of the present invention;

[0050] Figure 2This is a schematic diagram of on-chain expenses. DETAILED DESCRIPTION

[0051] It should be noted that, in the absence of conflict, the embodiments and features of the embodiments in this application can be combined with each other. The present application will be described in detail below with reference to the accompanying drawings and in combination with the embodiments.

[0052] It should be noted that the steps shown in the flowcharts of the accompanying drawings can be executed in a computer system such as a set of computer-executable instructions, and that, although a logical order is shown in the flowcharts, in some cases, the steps shown or described can be executed in an order different from that shown here.

[0053] First, the technical terms involved in the following embodiments are explained.

[0054] (1) Access structure (AC);

[0055] Definition 1: Access structure. Let {P1,P2,…,P n} is a set consisting of n attributes. is called monotonic if and only if: for any B and C, if and So An access structure (or monotone access structure) is a structure consisting of {P1, P2, ..., P n}, that is, The subset of set A is called the authorized set, and the set not in A is called the unauthorized set.

[0056] (2) Linear Secret Sharing Scheme (LSSS);

[0057] Definition 2: Linear Secret Sharing. Let p be a prime number. If the following conditions are met, the secret sharing scheme Π on the attribute set P is called in Z p It is linear.

[0058] (2.1) Each attribute with respect to the secret s∈Z p The shared value of Z p A vector on .

[0059] (2.2) For every access structure on P There exists a matrix And the function ρ:[l]→P. ρ maps the row number i∈[l] of the matrix A to the attribute ρ(i). Let v=(s,r2,…,r n ) T ,r2,…,rn ∈Z p is a random element. Then s is a vector of l shares of π Secret sharing share (λ) i =(Av) i Assigned to attribute ρ(i).

[0060] The above secret sharing scheme satisfies the linear reconstruction property: Assume that S is An authorization collection in Then there exists a polynomial time algorithm to calculate the equation ∑ i∈I c i λ i =(s,0,...,0) constant {c i ∈Z p Here (A,ρ) is called access policy.

[0061] In this embodiment, the attribute (ρ(i), V ρ(i) )∈P includes attribute name ρ(i) and attribute value V ρ(i) , and the attribute value V ρ(i) Sensitive information is usually recorded in , and the access policy is usually stored together with the ciphertext. Therefore, in order to protect the privacy of sensitive information, the access policy of this embodiment is only composed of the attribute name ρ(i).

[0062] (3) Bilinear groups and the hard problem hypothesis;

[0063] Let p be a prime number, G1, G2, G T There are three cyclic multiplicative groups of order p, where g1 is a generator of G1 and g2 is a generator of G2. Mapping e:G1×G2→G T is a bilinear pairing. It is called an asymmetric bilinear pairing if the following conditions are met:

[0064] 1. Bilinear

[0065] 2. Non-degenerate:

[0066] 3. Computability: Can be computed efficiently in polynomial time.

[0067] When all the above conditions are met, it is called (G1, G2, G T ,e) is a prime order asymmetric bilinear group system.

[0068] Definition 3: Asymmetric q-DBPBDHE2 assumption;

[0069] Let a,s,b,b1,…,b q ∈Z p , and define the following collection: Given the above parameters, the challenger gives:

[0070]

[0071] The challenge is to distinguish between: and a random element R∈G T If there is a polynomial time algorithm with negligible probability satisfy:

[0072]

[0073] Then it is called The advantage on the asymmetric q-DBPBDHE2 problem is ∈.

[0074] If for all polynomial time algorithms The advantages ∈ are all negligible, so it is called asymmetric q-DBPBDHE2 hypothesis in (G1, G2, G T ) is established.

[0075] (4) Zero-knowledge proof (ZKP);

[0076] Zero-knowledge proof is a cryptographic privacy protection technology that usually involves two roles: a prover and a verifier. Through zero-knowledge proof technology, the prover can prove to the verifier that he knows a specific secret without revealing any secret information. Zero-knowledge proof includes interactive zero-knowledge proof and non-interactive zero-knowledge proof. Non-interactive zero-knowledge proof does not require multiple interactive authentications and has high execution efficiency and has been widely used. Technologies for implementing non-interactive zero-knowledge proof include Zksnarks technology and Fiat-Shamir transform-based non-interactive zero-knowledge proof FSZKP (Fiat-Shamir Zero-Knowledge Proof). The specific scheme of FSZKP is as follows:

[0077] Initialization phase. Generate system parameters Params = {p, g, G p ,H}, where p is a large prime number, G p is a group of prime order p, g is a generator, and H is a hash function;

[0078] Proof generation phase. The prover takes the system parameters Params and the secret v as input and generates a zero-knowledge proof zkp of v. First, the prover calculates y = g v , and randomly select r∈Zp , calculate t = g r Next, the prover calculates c = H(t) and s = cv + r. Finally, the prover sends y and zkp = (t, s) to the verifier to prove that it is the holder of v in y without revealing v, where zkp = (t, s) is the zero-knowledge proof of v.

[0079] Verification phase. The verifier uses the system parameters Params,y=g v ,zkp=(t,s) is the input to verify that the user is the holder of v. First, the verifier calculates c=H(t). Second, the verifier calculates g s =y c Whether t holds true, if so, it indicates that the prover is the holder of v.

[0080] The above FSZKP has the three properties of zero-knowledge proof algorithm, namely zero knowledge, completeness, and robustness.

[0081] (5) Dynamic accumulator;

[0082] Dynamic accumulators can be used to prove a variable ID j Is it included in the set {ID1, ID2,…, ID n}, if not included, you can use ID j Dynamically add to the collection, if included, you can add the ID j Dynamically delete from the set. There are many ways to implement dynamic accumulators. This embodiment builds a private identity and its revocation algorithm based on a dynamic accumulator based on bilinear pairing. The steps of the dynamic accumulator based on bilinear pairing are as follows:

[0083] Initialization phase. Generate system parameters Params = {p, G1, G2, G T ,e,g1,g2}, where p is a large prime number, G1,G2 are multiplicative cyclic groups of prime order p, g1,g2 are generators of G1,G2 respectively, e:G1×G2→G T It is a two-line pairing;

[0084] Accumulator parameter generation phase. The verifier uses Params as input variable to generate accumulator parameter AccumParam,ID j ,w j First, the verifier randomly selects y∈Z p ,calculate And based on the set {ID1,ID2,…,ID n},calculate Where g∈G1. Next, the verifier chooses ID j ∈{ID1,ID2,…,ID n}, and calculate Finally, the validator adds the accumulator parameters Δ,ID j ,w j Sent to the prover.

[0085] The accumulator contains the relation verification phase. The prover takes the accumulator parameter Δ,ID j ,w j Submit to the verifier to verify the ID j Is it a member of the accumulator? The verifier verifies the equality Is it established? If established, it proves ID j Is the accumulator member.

[0086] The accumulator contains the relationship revocation phase. When a member ID is to be revoked j When , the verifier updates Δ to And use Δ new Replace Δ. At this time, holding ID j ,w j The prover will not be able to verify the equation

[0087] In this embodiment, ID j As the user's legal identity, and ID j and Δ are embedded in the attribute key and ciphertext to achieve effective revocation management of identity and attributes. In addition, in order to ensure that the attribute authority cannot use the legitimate ID j Obtain the complete attribute set of the user. This embodiment will combine FSZKP to construct ID j Zero-knowledge proof of verification of the accumulator allows users to prove that their legal identity is contained in the accumulator without revealing their legal identity, and to revoke private identities and attributes when necessary.

[0088] Example 1

[0089] The system model proposed in this embodiment is as follows Figure 1 As shown, there are mainly five entity roles:

[0090] Certification Authority (CA): CA is the legal identity issuer for system users. CA creates a legal identity ID for system users and builds a cryptographic accumulator based on the legal identity ID. Members can dynamically join and revoke the cryptographic accumulator. At the same time, the cryptographic accumulator parameter Δ is put on the chain. The hash value of Δ It will be embedded in the data ciphertext and attribute key to ensure that the revoked user cannot continue to decrypt the ciphertext.

[0091] Data Owner (DO): DO is the owner of the EHR. DO reads the accumulator parameter Δ and calculates the hash value of Δ Then, the EHR is encrypted using the attribute-hiding access policy (A, ρ) (for example, if DO's full access policy is {hospital: A regional tertiary hospital; department: cardiology; physician: chief physician; title: professor at medical university B}, then the attribute-hiding access policy is {hospital; department; physician; title}). The EHR's hash value is then stored on-chain and the address of the on-chain hash value is obtained. Finally, DO stores the EHR's ciphertext, access policy, and on-chain hash value address in the cloud service.

[0092] Data User (DU): DU is the user who needs EHR. DU needs to request a valid identity from CA (accumulator member parameter (ID j ,w j )) and generate their zero-knowledge proof ZKP. The decryption key is divided into two parts, one is the user decryption key held by DU itself, and the other is the outsourced decryption key (attribute key). DU first generates the user decryption key, and then proves to AAs that it is the owner of the legal identity through ZKP, and based on the hidden ID j Obtain the outsourced decryption key. Furthermore, the DU will request the outsourced decryption result of the data ciphertext from the cloud service through a zero-knowledge proof. The DU will then further decrypt the partial decryption result using the user decryption key to obtain the final plaintext. Finally, the DU will compare the hash value of the plaintext with its corresponding on-chain hash value to confirm the security and trustworthiness of the EHR.

[0093] Attribute Authorities (AAs): AAs are the management agencies of different attributes of users. AAs manages the legal identity ID of DU j The corresponding attributes of different privacy identities are obtained, and outsourced decryption keys are generated for DUs with legitimate identities. AAs can only obtain the privacy identity corresponding to the legitimate identity of the DU, and different privacy identities correspond to different attributes. Therefore, AAs cannot collude to obtain the complete attribute set of the DU.

[0094] Cloud Service Provider (CSP): The CSP is responsible for storing the ciphertext, access policy, and on-chain hash address uploaded by the DO. Furthermore, the CSP receives the DU's legitimate identity ZKP and outsourced decryption request. After verifying the validity of the ZKP on-chain, the CSP provides outsourced decryption for the DU. During the outsourced decryption process, since the access policy is attribute-value-hidden, the CSP also performs a decryption test before decryption to improve ciphertext matching efficiency.

[0095] Blockchain (BC): BC primarily stores system public parameters and EHR hash values, facilitating interoperability between system roles and DU validation of decrypted ciphertext. Furthermore, ZKP validation of DUs' legitimate identities by AAs and cloud services will be performed on the blockchain, providing cross-platform trusted identity verification and interoperability. These operations further enhance cross-institutional collaboration, security, and transparency in EHR sharing.

[0096] This embodiment provides a medical data sharing method based on blockchain and revocable multi-attribute authority CP-ABE, which specifically includes:

[0097] S1. Generate medical public parameters through the identity authentication center and store them on the chain;

[0098] Furthermore, the steps of generating medical public parameters through the identity authentication center and storing them on the chain include:

[0099] Select the generator of the bilinear group through the identity authentication center and define the hash function;

[0100] Generate accumulator parameters through the identity authentication center, including accumulator value and verification parameters;

[0101] The system public parameters and accumulator parameters are stored on the chain through the identity authentication center.

[0102] S2. Based on the medical public parameters, generate respective private and public keys through multiple attribute authorities, and upload the public keys to the blockchain;

[0103] S3. The data user applies for a legal identity from the identity authentication center and generates a private identity and zero-knowledge proof based on the legal identity.

[0104] Furthermore, the steps of generating a private identity and zero-knowledge proof include:

[0105] The data user obtains the legal identity ID and accumulator member parameters from the identity authentication center;

[0106] Construct private identity and zero-knowledge proof based on legal identity ID and accumulator member parameters.

[0107] S4. The data user generates a user decryption key based on the private identity and submits a zero-knowledge proof to multiple attribute authorities to obtain the outsourced decryption key;

[0108] Furthermore, the step of obtaining the outsourced decryption key includes:

[0109] Data users submit their privacy identities and zero-knowledge proofs to attribute authorities;

[0110] The attribute authority verifies the validity of the zero-knowledge proof through an on-chain smart contract;

[0111] After verification, the attribute authority generates an outsourced decryption key based on the data user's attribute set and accumulator parameters.

[0112] S5. The data owner encrypts the medical data based on the access policy and on-chain parameters, generates ciphertext, stores it in the cloud service, and uploads the data hash value to the chain.

[0113] Furthermore, the steps of encrypting medical data include:

[0114] The data owner obtains the public key of the medical public parameter and attribute authority from the blockchain;

[0115] The data owner constructs an access policy that contains only the attribute name and hides the attribute value;

[0116] Encrypt the data based on the access policy and the hash value of the accumulator parameter to generate ciphertext;

[0117] The data owner calculates the hash value of the data and stores it on the chain, and submits the ciphertext and on-chain hash address to the cloud service.

[0118] S6. The data user submits a zero-knowledge proof to the cloud service, requesting outsourced decryption. The cloud service verifies the proof, performs a decryption test, and returns a partial decryption result.

[0119] Furthermore, the steps of performing the decryption test by the cloud service include:

[0120] The cloud service receives the data user's outsourced decryption request and zero-knowledge proof;

[0121] The cloud service verifies the validity of the zero-knowledge proof through the on-chain smart contract;

[0122] After verification, the cloud service performs a decryption test based on the outsourced decryption key and ciphertext to determine whether the attributes of the data user meet the access policy.

[0123] Furthermore, the step of returning the partial decryption result by the cloud service includes:

[0124] If the decryption test is successful, the cloud service calculates the partial decryption results;

[0125] The cloud service returns the partial decryption result to the data user.

[0126] S7. The data user uses the user decryption key to finally decrypt the partial decryption result and verify the data integrity through the on-chain hash value;

[0127] Furthermore, the steps of performing final decryption on the partial decryption results include:

[0128] The data user uses the user decryption key to finally decrypt the partial decryption result and obtain the plaintext data;

[0129] Calculate the hash value of the plaintext data and compare it with the original hash value stored on the chain to verify the data integrity.

[0130] S8. When the user authority needs to be revoked, the accumulator parameters are updated and broadcast through the identity authentication center, and the data owner re-encrypts the data according to the updated parameters.

[0131] Furthermore, the steps of revoking user permissions include:

[0132] Tracking real identities through data users based on private identities;

[0133] The accumulator parameters are updated by the data user and broadcast to the blockchain;

[0134] The data owner re-encrypts the data based on the updated accumulator parameters, making it impossible for the revoked user to decrypt the new ciphertext.

[0135] In this embodiment, the outsourced decryption key and the user decryption key are separated, wherein the outsourced decryption key is generated by the attribute authority and used for cloud service partial decryption; the user decryption key is independently generated by the data user and used for the final decryption partial decryption result.

[0136] In the structure of this embodiment, U is the attribute domain, U θ is the attribute authority domain. For a specific attribute authority θ∈U θ , let the attribute it manages be i∈U, T: U→U θ is a public computation function that maps attribute i to a specific attribute authority θ. Let A be an l×n access structure, ρ is a mapping that maps each row x in A to a corresponding attribute, and δ(.)=T(ρ(.)) is a mapping that maps each row x in A to a corresponding attribute authority θ. Let G1 and G2 be bilinear groups with prime number p as order, e:G1×G2→G T is a bilinear map.

[0137] The sharing solution of this embodiment includes the following core steps:

[0138] (1) CA Setup (λ) → GP. The authentication center CA inputs the security parameter λ, outputs the accumulator and the system’s public parameter GP, and stores them in the blockchain.

[0139] Specifically, the identity authentication center CA first selects the generators g1 and g2 of G1 and G2. Secondly, CA selects two hash mapping functions and F:U→G2, are used to map the attribute names in the identity and attribute to G2 respectively. In addition, the two hash functions will be regarded as random oracles in the security proof of this embodiment. Through the hash function, any attribute string can be mapped to a group element to participate in the system operation, thereby realizing a large attribute domain. Again, CA selects n random numbers to form the data user group identity set ID = {ID1, ID2, ..., ID j ,……ID n}, 1≤j≤n, each data user in the group CA randomly selects y Δ ∈Z p ,calculate Choose g∈G1, calculate Get the accumulator parameters ( ,Δ). Finally, CA releases system parameters to the blockchain.

[0140] (2)AuthoritySetup(GP,θ)→{Sk θ ,Pk θ The attribute authority θ generates the private key Sk using the public parameters θ and public key PK θ , and put the public key on the chain.

[0141] Specifically, each attribute authority θ∈U θ Read GP from the blockchain, randomly selected calculate and Get the private key Sk θ =(α θ ,y θ ) and public key And the public key Pk θ Published to the blockchain.

[0142] (3) The data user obtains the legal identity ID corresponding to the accumulator member parameter from the identity authentication center CA j , generate the relevant zero-knowledge proof ZKP, where k j Legal identity ID j The corresponding privacy identity.

[0143] The specific steps include:

[0144] First, the data user requests an identity from the identity authentication center (CA) and obtains an identity ID from the CA. j ∈ID={ID1,ID2,……,ID n}, 1≤j≤n, and obtain from CA Data users can use (ID j ,w j ) proves its identity is contained in the accumulator.

[0145] Second, the data user ID j Has attribute set S j , each element in the attribute set is (i,V i )∈S j , where i is the attribute name, V i For the attribute value. In order not to disclose (ID j ,w j ) in the case of j ∈ID is the legal identity issued by CA. Data users need to generate zero-knowledge proof ZKP , that is, you need to pass Proof ZKP , without disclosing (ID j ,w j ), the accumulator equation can be made First, the data user selects r w ∈G1, calculate k j =r w ID j , and put them into the equation get Secondly, the data user randomly selects ρ1,ρ2,ρ3,ρ4∈Z q ,calculate s j1 =ρ1+c j r w ,s j2 =ρ2+c j k j ,s j3 =ρ3+c j ID j ,

[0146] Finally, data users obtain zero-knowledge proof of their private identity.

[0147] (4) Data users are based on the public parameters and private identity k on the chain j , generate user decryption keys, including private keys and public key And put the public key on the chain.

[0148] Specifically, the data user ID j Random selection And based on ID j The private identity k j , calculate the user's public key and will Keep it secret as the user's decryption private key.

[0149] (5) Data users request attribute keys from attribute authorities based on zero-knowledge proof of legal identity After the attribute authority verifies the validity of the zero-knowledge proof on the blockchain, it generates a hash value embedded with the accumulator parameter Δ of

[0150] Specifically, given the global parameter GP, the privacy identity of data owner j is {a j ,b j ,k j ,q j ,Proof ZKP}, attribute set S of data owner j j , where for each attribute (i,V i )∈S j , and its corresponding attribute authority is T(i) = θ. In order to generate the outsourced decryption key, the data user first submits the attribute authority θ∈U θ submit To prove its private identity k j =r w ID j Belongs to the identity set ID = {ID1, ID2, ..., ID j ,……ID n}, 1≤j≤n. Attribute authority θ∈U θ Submit proof to the smart contract on the chain, and the smart contract calculates And judge the following equation Is it true? If it is true, the attribute authority θ is k j =r w ID j As the privacy identity of the data user, take the accumulator parameter Δ from GP and calculate its hash value Randomly select t∈Z p , calculate the outsourced key Data users obtain outsourced decryption keys

[0151] (6)OwnerEncrypt(GP,{Pk θ},M,(A,ρ))→CT. The EHR data owner uses the access control policy (A,ρ) based on the attribute value hiding and the hash value of Δ on the chain. The HER data M is encrypted using public parameters such as ciphertext and CT. At the same time, the data owner obtains the hash value of M and uploads it to the chain to obtain the on-chain address. The ciphertext CT, access policy, and the address of the on-chain hash value are then stored in the cloud service.

[0152] Specifically, the EHR data owner first obtains GP from the blockchain, the public key {Pk θ}, take out the accumulator parameter Δ from GP and calculate its hash value The data owner represents the EHR to be shared without M and gives a set of access control policies (A,ρ) consisting only of attribute names. The data owner first selects s, y1, y2, ..., y n ,z2,z3,……,z n ∈Z p , let the vector calculate and Among them A x is the xth row of A, λ x is the share of s relative to row x, ω x is the share of 0 relative to row x. For each row x∈{1,2,……,l} of A, the data owner chooses r x ∈Z p , calculate the ciphertext:

[0153] C0=Me(g1,g2) s ;

[0154]

[0155]

[0156] The data owner obtains the ciphertext CT=(C0,{C 1,x ,C 2,x ,C 3,x ,C 4,x} x∈[l] ). In addition, the data owner obtains the hash value of M and will Store evidence on the chain, and finally CT, The chain address is submitted to the cloud service provider. It should be noted that during the calculation of the ciphertext, It can be calculated in advance to reduce computational overhead.

[0157] (7) The data user requests the cloud service to partially outsource decryption of CT based on the zero-knowledge proof of legal identity. After the cloud service verifies the validity of the zero-knowledge proof on the blockchain, it obtains the outsourced decryption key. Based on the ciphertext CT and the public parameters on the chain, a decryption test is first performed. If the decryption test is successful, partial decryption is performed to obtain the partially decrypted ciphertext CT. P .

[0158] Specifically, data users submit zero-knowledge proofs to cloud service providers and outsource decryption keys. Request to obtain the partial decryption result of the accurate ciphertext. The cloud service provider first determines the validity of the zero-knowledge proof through the on-chain smart contract to determine whether the data user is a legitimate user. If so, it continues to provide outsourced decryption. Since the access policy (A, ρ) only contains the attribute name i, and the ciphertext is the attribute name and attribute value (i, V i ) encrypted result, so the cloud service provider does not know The matching relationship between CT and the decryption test needs to be performed first. The cloud service provider first performs a decryption test, i.e., determines the equation Is it true? If not, output ⊥. Otherwise, calculate {c x ∈Z p} makes ∑ x∈I c x A x =(1,0,…0), where A x is a subset of A, and is calculated from this:

[0159]

[0160] Finally, the cloud server will partially decrypt the ciphertext CT P =(C0,C 1,k ,C 2,k ,C 3,k ) is returned to the data user.

[0161] (8) Data users use the user's decryption private key Decrypted ciphertext CT for the cloud service part P Decryption is performed to obtain the final plaintext M, and the hash value of the final plaintext is calculated to compare with the hash on the chain to verify the security and integrity of the shared data.

[0162] Specifically, data users are based on CT P =(C0,C 1,k ,C 2,k ,C 3,k ) and the user's decryption private key calculate Finally restore the ciphertext Furthermore, after obtaining the ciphertext M, the data user obtains the hash value of M and compares it with the hash value on the chain to confirm the security and integrity of the shared EHR.

[0163] (9)UserRevoke(k j ,ID)→Δ new If the data user exits the system or commits other illegal acts, the attribute authority can request the identity authentication center CA to track and revoke the privacy identity k j The identity authentication center CA uses the private identity k j Extract the real identity ID j , cancel the accumulator member parameter ID j , generate a new accumulator parameter Δ new , and replaces Δ on the chain. Finally, the identity authentication center CA sends a revocation broadcast through the blockchain to notify other members that the accumulator parameters have changed.

[0164] Specifically, if the data user exits the system or commits other illegal acts, the attribute authority can submit k j and q j , request to revoke the privacy identity k j CA from ID = {ID1, ID2, ..., ID j ,……ID n}, select ID from 1≤j≤n j , judge the equation Is it true? If it is true, the identity authentication center CA extracts the private identity k j Real ID in j ,calculate And update Δ on the chain to Δ new , broadcast the accumulator update message to other participants in the system through the blockchain.

[0165] (10)OwnerUpdateCrpt(GP,{Pk θ},M,(A,ρ),Δ new )→CT new The data owner receives k j The message is revoked, and the ciphertext data on the cloud is updated to CT new , ensuring that the revoked user cannot decrypt CT new .

[0166] Specifically, after the data owner receives the accumulator parameter update message, it calculates Δ new Hash value And recalculate the ciphertext CT new :

[0167] C0=Me(g1,g2) s ;

[0168]

[0169] Since the new accumulator parameter Δ new Embedded in the ciphertext CT new In the case of revoked data users, they will not be able to use the outsourced decryption key embedded in the original accumulator parameters. For the updated ciphertext CT new Decrypt.

[0170] The static security model of the CP-ABE solution in this embodiment is the adversary and challengers Similar to the Rousselakis-Waters (RW) scheme, the adversary Immediately after seeing the global parameters, Send all queries. This embodiment also allows the adversary Select and corrupt several attribute authorities to launch malicious attacks. In the security model of this embodiment, one attribute authority can manage multiple attributes, and each attribute can only be controlled by one attribute authority. θ is the set of attribute authorities, U is the attribute domain, and the function T is defined as: U→U θ , which maps each attribute to the attribute authority that controls it. The formal security challenge game is as follows:

[0171] (1) Setup phase:

[0172] Challenger Execute the global initialization algorithm of CP-ABE of this embodiment and send the generated global parameter GP to the adversary.

[0173] (2) Rival Query phase:

[0174] adversary Perform the following steps:

[0175] (a) Choose a corrupt set of attribute authorities And send the public keys of these corrupted authorities to the adversary

[0176] (b) Select a set of uncorrupted attribute authorities and request the public keys of the authorities for these attributes;

[0177] (c) Sequence of attribute-identity pairs Initiate a key query, where k j It is a private identity identifier. is a set of attributes. This embodiment requires that these identities are different from each other and the requested key does not involve attributes controlled by the corrupt attribute authority, that is, T(S j )∩C θ =φ;

[0178] (d) Specify two plaintext messages M0, M1 of equal length and an access structure (A, ρ) to request the challenge ciphertext. This embodiment requires that for each identity k j , the access structure (A,ρ) does not satisfy in Represents the set of all properties controlled by the Corrupted Property Authority.

[0179] (3) Challenger's response phase:

[0180] Challenger C throws a random bit β∈{0,1} and returns the following:

[0181] (a) The set of uncorrupted attribute authorities Corresponding public key

[0182] (b) Each query pair (S j ,k j )'s private key

[0183] (c) Challenge ciphertext CT'←Encrypt(GP,{PK θ},M β ,(A,ρ)).

[0184] (4) Guessing stage:

[0185] adversary Output the guess value β′ for β;

[0186] adversary The advantage to win this game is defined as:

[0187] If there is no polynomial-time adversary If the game can be won with a non-negligible advantage, the CP-ABE scheme of this embodiment is said to be statically secure.

[0188] Static security proof of the constructed CP-ABE:

[0189] Based on the q-DPBDHE2 assumption, the static security of the CP-ABE scheme of this embodiment will be proved. Before that, the following lemma is first proved.

[0190] Lemma 1: Assuming that the Rousselakis-Waters (RW) scheme is a statically secure CP-ABE scheme, then the CP-ABE scheme of this embodiment is also statically secure.

[0191] Proof: Assume there is a polynomial-time adversary In the security challenge game, the CP-ABE scheme of this embodiment can be broken with advantage ∈. This embodiment will show how to construct a simulator It can defeat the Rousselakis-Waters (RW) scheme with the same advantage ∈. Let A challenger to the RW solution.

[0192] (1) Setup Phase: Challenger Set global parameters Send to simulator ,Then Pass the global parameter GP to the adversary

[0193] (2) Adversary query phase: Adversary Select the corrupted attribute authority set And create their corresponding public keys in the RW scheme For every corrupt authority adversary Their public keys in the CP-ABE scheme of this embodiment are set to Then, the opponent To the simulator Send the following:

[0194] (a) Corrupt authorization set and their public keys

[0195] (b) Normal, uncorrupted attribute authority set

[0196] (c) The attributes and privacy identity set of the user decryption key and cloud service key to be requested Among them, k j For different privacy identities, S j is the attribute set corresponding to the privacy identity, which includes attribute name and attribute value (i, V i ), that is, (i,V i )∈S j ,and T(Sj )∩C θ =φ.

[0197] (d) The challenge access structure (A,ρ) and two messages of equal length M0 and M1. Let is the set of attributes controlled by the corrupt authority, requiring Member j∈[m] in the set The access policy (A,ρ) is not satisfied.

[0198] (3) Challenger's response phase: simulator The above-mentioned enemy Sent C θ , M0,M1,(A,ρ) are passed to the challenger of the RW scheme In order to request the public key, private key and challenge ciphertext of the RW scheme. Then the challenger To the simulator Return response: public key Private Key Challenge ciphertext CT'=(C0=M b e(g1,g2) s , Among them, M b Next, the simulator Generate the data owner's decryption public and private keys, the authority's public key, the outsourced decryption key, and the challenge ciphertext in this embodiment:

[0199] (a) For each j∈[m], the simulator Random selection Calculate the data owner's public key and private key

[0200] (b) For each normal authority θ∈N θ , simulator Constructing the attribute authority public key

[0201] (c) For each attribute name and attribute value (i, V i )∈S j , simulator set up in is the hash value of Δ, and calculates the outsourced decryption key Outsource decryption key

[0202] (d) For each x∈{1,2,…,l}, the simulator Computational Challenge Ciphertext

[0203] (e) Finally, the simulator Send the above data owner's decryption public key and private key, the authority's public key, outsourced decryption key, and challenge ciphertext to the adversary

[0204] (4) Guessing stage: Finally, the opponent Output guess β′∈{0,1}, then the simulator Output the same β′.

[0205] The above is the simulation process. If the adversary Can crack our solution with advantage∈, then the simulator The RW scheme can also be cracked with the same probability. However, the following lemma has been proven:

[0206] Lemma 2: If the q-DPBDHE2 assumption holds, then the RW scheme is statically secure in the random oracle model.

[0207] Theorem 1: If the q-DPBDHE2 assumption holds, then the CP-ABE scheme proposed in this embodiment is statically secure in the random oracle model.

[0208] In summary, the security conclusion can be directly derived from Lemma 1 and Lemma 2.

[0209] Security analysis of this embodiment:

[0210] (1) The user's identity privacy and the attributes of multi-attribute authorities cannot be linked;

[0211] In this embodiment, the member parameter ID of the cryptographic accumulator j As the user's real identity, the user's private identity k j =r w ID j Generated by the user, and can be changed by changing the random number r w Change the correlation between private identities to avoid different attribute authorities from using the same real identity ID j Perform association analysis on the complete attributes of the user. In addition, this embodiment constructs a cryptographic accumulator-based privacy identity authentication zero-knowledge proof to ensure the privacy identity k j =r w ID j The legitimacy and unforgeability of the private identity must be a legitimate identity ID issued by the identity authentication center CAj Otherwise, it cannot pass the zero-knowledge proof authentication.

[0212] (2) Traceability of private identities and revocability of identities and their associated attributes;

[0213] The privacy identity k in this embodiment j =r w ID j The random number r is chosen by the user w , and based on the legal identity ID issued by the identity authentication center CA j Generated by the private identity k j , multi-attribute authority cannot obtain the real legal identity ID j , but the identity authentication center passes the equation Can trace k j Corresponding ID j , and by modifying the accumulator parameters To revoke the user's legal identity, so that it cannot pass the accumulator verification again. new The hash value is embedded in the attribute key and Δ in the ciphertext CT new After updating, the ciphertext will be updated CT new , the original attribute key The ciphertext will not be decrypted, thus achieving the simultaneous revocation of identity and attributes.

[0214] (3) Outsourcing decryption security;

[0215] In this embodiment, the complete decryption key can be divided into two parts: user decryption key It is independently generated by the user and the decryption key is outsourced It is calculated by a multi-attribute authority based on the user's attributes and the user's decryption public key. Therefore, even if an attacker obtains the user's outsourced decryption key, they can only decrypt part of the ciphertext and cannot obtain the final plaintext, because to obtain the final plaintext, they need to know the user's decryption key.

[0216] (4) Blockchain-based evidence storage and verifiable security of original plaintext data, as well as cross-platform authentication of privacy.

[0217] First, the data and behaviors such as the release of public parameters and the revocation and update of private identities in this embodiment are all stored on the chain. This not only ensures the security, reliability and traceability of data and behaviors, but also effectively improves parameter transmission and security issues in the cross-platform data sharing process. In addition, this embodiment uses the hash value of the original data before sharing on the blockchain, and after sharing and decryption, the hash value of the original data on the chain is used to verify the correctness and integrity of the decrypted data. This can effectively prevent the problem of inconsistency between the final decrypted data and the expected original encrypted data. On the other hand, the legitimacy of the user's private identity in this embodiment needs to be authenticated by the attribute authority and the cloud service. Traditional authentication has problems such as transparency, centralization, and duplicate construction of authentication systems. This embodiment constructs a zero-knowledge proof authentication algorithm for private identity through an on-chain smart contract. The attribute authority and the cloud service can complete cross-platform security and reliability verification by calling the on-chain interface.

[0218] Calculation of blockchain's on-chain expenses:

[0219] This example introduces a blockchain and performs on-chain storage and access of public parameters and decrypted plaintext data hash values, message broadcasting of accumulator parameter updates, and private identity authentication based on accumulator zero-knowledge proofs. These functions are implemented through two smart contracts: Contract 1 primarily implements storage, access, and broadcasting, while Contract 2 primarily implements private identity authentication based on accumulator zero-knowledge proofs. This example uses Python + Web3.Py to build a DAPP that interacts with the blockchain, and uses Remix + Solidity to build two smart contracts. Message broadcasting is implemented through smart contract events, and the construction of the private identity authentication contract based on accumulator zero-knowledge proofs utilizes precompiled Ethereum elliptic curve contracts EIP196 and EIP197. Finally, the two contracts were deployed to Ganache for on-chain overhead testing. The main tests for smart contract overhead are deployment overhead and transaction overhead. Figure 2 The bar chart shows the deployment and transaction costs of the two contracts. The values ​​on each bar chart (such as 0.00323ETH, 0.00039ETH, 0.00007ETH, 0.0105342ETH, 0.0034025ETH) are the results of converting the corresponding gas consumption into Ether (the conversion formula is ETH consumption = Gas consumption × Gas price, where the gas price is calculated based on the average gas price of the Ethereum public chain on June 23, 2025, which is 6.393Gwei). Since the deployment cost is no longer consumed on the chain after the contract is deployed, Figure 2 As can be seen from the consumption diagram, the on-chain overhead of this embodiment is not large.

[0220] Beneficial effects of this embodiment:

[0221] This example addresses key issues in medical cloud data sharing, such as privacy leakage, insufficient access control flexibility, and weak cross-institutional interoperability. It proposes a medical cloud data sharing solution that integrates blockchain with a secure, privacy-sensitive, and revocable multi-attribute authority (CP-ABE). CP-ABE in this solution introduces dynamic cryptographic accumulators and zero-knowledge proofs, separates attribute names from attribute values ​​in access policies, and hides attribute values. While ensuring identity anonymity, it also enables partial hiding of access control policies, traceability and revocability of user identities and attributes, and fine-grained dynamic management of decryption permissions.

[0222] To reduce the computational burden on terminal devices, this embodiment further designs a secure and efficient outsourced decryption mechanism with decryption testing capabilities within the CP-ABE scheme, and ensures the validity and security of the final decryption result through blockchain verification. Furthermore, by putting system public parameters, privacy identity authentication, and other operations on the blockchain, this embodiment achieves transparency, auditability, and cross-institutional trust collaboration in the medical data sharing process. Furthermore, this embodiment demonstrates the static security of the proposed CP-ABE scheme under a random oracle model. Combining theoretical analysis with experimental testing, this embodiment verifies the feasibility and advantages of the scheme from the perspectives of functional coverage, computational complexity, decryption efficiency, and on-chain overhead.

[0223] This embodiment achieves a systematic improvement in security and privacy, and provides ideas for building a scalable, interoperable, and trustworthy medical data sharing architecture.

[0224] This embodiment proposes an EHR sharing solution that integrates blockchain and secure, private, revocable multi-attribute authority CP-ABE, providing a new approach to addressing the dual needs of privacy protection and collaborative efficiency in medical data sharing. This embodiment uses a dynamic cryptographic accumulator based on bilinear pairing to construct a private identity GID, and combines it with zero-knowledge proof to achieve anonymous authentication, tracking, and revocation of the private identity. By dividing the access policy into a "publicly available attribute name + non-publicly available hidden attribute value" structure, the privacy protection of the policy is achieved. The user decryption key is separated from the cloud service decryption key to achieve outsourced decryption and decryption testing, and the summary of the data to be encrypted is recorded based on the blockchain for decryption verification after full decryption. In addition, the access strategy of the scheme supports large attribute domains and arbitrary monotonic access structures, and the static security of the scheme is proved under the random oracle model.

[0225] This implementation leverages the transparency and immutability of blockchain to synchronize system public parameters, encrypted data summaries, and key operational information, achieving cross-platform trust and interoperability among system participants. Furthermore, private identity authentication using accumulator zero-knowledge proofs based on on-chain smart contracts ensures the privacy, reliability, and cross-platform nature of user authentication, safeguarding the construction of an open, collaborative, and secure medical cloud sharing environment.

[0226] The above are merely preferred embodiments of the present application, but the scope of protection of the present application is not limited thereto. Any changes or substitutions that can be easily conceived by a person skilled in the art within the technical scope disclosed in this application should be included in the scope of protection of the present application. Therefore, the scope of protection of the present application should be based on the scope of protection of the claims.

Claims

1. A medical cloud data sharing method based on blockchain and privacy-safe, traceable and revocable multi-attribute authority CP-ABE, characterized by: The following steps are involved: Generate medical public parameters through the identity authentication center and store them on the chain; Based on the medical public parameters, multiple attribute authorities generate their own private and public keys, and upload the public keys to the chain; The data user applies for a legal identity from the identity authentication center, and generates a private identity and zero-knowledge proof based on the legal identity; The data user generates a user decryption key based on the private identity and submits a zero-knowledge proof to multiple attribute authorities to obtain the outsourced decryption key; The data owner encrypts the medical data based on the access policy and on-chain parameters, where the attribute names are public but the attribute values ​​are hidden. The data owner generates ciphertext and stores it in the cloud service, while also uploading the data hash value to the chain. The data user submits a zero-knowledge proof to the cloud service and requests outsourced decryption. The cloud service verifies the proof and performs a decryption test, returning a partial decryption result. The data user uses the user decryption key to perform the final decryption of the partial decryption result and verifies the data integrity through the on-chain hash value; When user permissions need to be revoked, the accumulator parameters are updated and broadcast through the identity authentication center, and the data owner re-encrypts the data based on the updated parameters.

2. The method according to claim 1, characterized in that The steps for generating medical public parameters through the identity authentication center and storing them on the chain include: Select the generator of the bilinear group through the identity authentication center and define the hash function; Generate accumulator parameters through the identity authentication center, including accumulator value and verification parameters; The system public parameters and accumulator parameters are stored on the chain through the identity authentication center.

3. The method according to claim 1, characterized in that The steps to generate a private identity and zero-knowledge proof include: The data user obtains the legal identity ID and accumulator member parameters from the identity authentication center; Construct private identity and zero-knowledge proof based on legal identity ID and accumulator member parameters.

4. The method according to claim 1, wherein The steps to obtain the outsourced decryption key include: Data users submit their privacy identities and zero-knowledge proofs to attribute authorities; The attribute authority verifies the validity of the zero-knowledge proof through an on-chain smart contract; After verification, the attribute authority generates an outsourced decryption key based on the data user's attribute set and accumulator parameters.

5. The method according to claim 1, wherein The steps to encrypt medical data include: The data owner obtains the public key of the medical public parameter and attribute authority from the blockchain; The data owner constructs an access policy that contains only the attribute name and hides the attribute value; Encrypt the data based on the access policy and the hash value of the accumulator parameter to generate ciphertext; The data owner calculates the hash value of the data and stores it on the chain, and submits the ciphertext and on-chain hash address to the cloud service.

6. The method according to claim 1, characterized in that The steps for the cloud service to perform decryption testing include: The cloud service receives the data user's outsourced decryption request and zero-knowledge proof; The cloud service verifies the validity of the zero-knowledge proof through the on-chain smart contract; After verification, the cloud service performs a decryption test based on the outsourced decryption key and ciphertext to determine whether the attributes of the data user meet the access policy.

7. The method according to claim 1, characterized in that The step of returning a partial decryption result by the cloud service includes: If the decryption test is successful, the cloud service calculates the partial decryption results; The cloud service returns the partial decryption result to the data user.

8. The method according to claim 1, characterized in that The steps for final decryption of the partial decryption results include: The data user uses the user decryption key to finally decrypt the partial decryption result and obtain the plaintext data; Calculate the hash value of the plaintext data and compare it with the original hash value stored on the chain to verify the data integrity.

9. The method according to claim 1, characterized in that The steps to revoke user permissions include: Tracking real identities through data users based on private identities; The accumulator parameters are updated by the data user and broadcast to the blockchain; The data owner re-encrypts the data based on the updated accumulator parameters, making it impossible for the revoked user to decrypt the new ciphertext.

10. The method according to claim 1, characterized in that The outsourced decryption key and the user decryption key are separated, wherein the outsourced decryption key is generated by the attribute authority and is used for cloud service partial decryption; the user decryption key is independently generated by the data user and is used for the final decryption of the partial decryption result.

Images