Cross-chain data dynamic sharing scheme and formalized proving method

Abstract

The invention discloses a cross-chain data dynamic sharing scheme and a formalized proving method, and relates to the technical field of data sharing. Compared with a previous data sharing scheme, the method solves the problems that an existing proxy re-encryption algorithm cannot solve the problems of certificate management and key escrow, and cannot cope with the characteristic that a data demander has dynamic access to a block chain at the same time; a CPRE algorithm suitable for cross-chain data sharing is defined, and high safety is achieved in an application scene of cross-chain data sharing. A cross-chain data dynamic sharing scheme based on CPRE is described in detail, and efficient fine-grained data sharing is achieved. And formalized definition and description are carried out by utilizing a Z language, so that the correctness of the scheme is ensured. The method can realize offline one-to-many data sharing of the data owner, and has the characteristic that the data demander dynamically enters and exits the block chain.

Description

Technical Field

[0001] The present invention relates to the technical field of data sharing, and in particular, to a cross-chain data dynamic sharing scheme and a formal proof method. Background Art

[0002] Medical data plays a crucial role in modern medical research. However, since medical data is usually independently managed by each hospital, the sharing of medical data faces many challenges. Blockchain can enhance trust among different institutions, but current research mainly focuses on data sharing within a single blockchain. In actual operation, different medical institutions may adopt different blockchain systems, which leads to the complexity of cross-chain data sharing. At the same time, with the continuous in-depth study of the causes of complex diseases, the demand for data is increasing, and there is an urgent need for a safe and reliable data sharing scheme to enable data sharing between different chains. Existing data sharing schemes based on cloud servers have problems of data leakage or single point of failure, and data sharing schemes based on blockchain have problems of complex certificate management or key escrow, and at the same time cannot solve the characteristics of dynamic entry and exit of data requesters in the blockchain.

[0003] Blockchain data is widely used in the research on disease relevance, which can reveal the causes of diseases and thus improve the prevention and treatment level of diseases. Currently, major hospitals around the world have established their own databases. With the continuous in-depth study of the causes of complex diseases, the data demand gradually develops from a single chain to a more complex multi-chain, and the data on the same chain is often needed by multiple users. However, due to the inability to guarantee the privacy of data and the security of the data sharing process, the data cannot be shared among different chains.

[0004] Cloud computing, with its sufficient storage and computing capabilities, is often used as a trusted third party in medical data sharing solutions. Many existing solutions combine cloud computing with encryption algorithms to achieve cross-domain data sharing while protecting user privacy and data security. In traditional data sharing solutions, data sharing requires encrypting data using the public key of the data requester, and only the private key of the data requester can decrypt the data. The efficiency of this one-to-one data sharing solution is very low. Attribute-based encryption (ABE) is considered an effective solution for achieving privacy protection and data security in data sharing because it can achieve one-to-many data sharing. In 2005, relevant technical personnel first proposed the concept of ABE. It was further proposed to use blockchain and distributed database technologies to protect the integrity of electronic medical records stored in the public cloud to avoid misdiagnosis caused by incorrect electronic health records tampered with by malicious users or internal institutions. A cloud-assisted medical Internet of Things (MIoT) fine-grained data sharing scheme was also designed, which can achieve efficient, fine-grained access control and ciphertext keyword search and allows revocation of malicious data users. However, the computational overhead of ABE-based data sharing schemes increases linearly with the increase of attributes and cannot be applied to the application scenarios of cross-chain data sharing with multiple requirements. Proxy re-encryption (PRE) emerged as the times require. It allows the proxy to convert the ciphertext encrypted by the data owner with their own public key into a ciphertext that the data requester can decrypt with their own private key. The proxy is not fully trusted, and the proxy cannot obtain the private keys of both communication parties. Subsequently, a new verifiable and fair attribute-based proxy re-encryption (VF-ABPRE) scheme was proposed to support verifiability and fairness. Verifiability enables shared users to verify whether the re-encrypted ciphertext returned by the server is correct. Another solution applies searchable proxy re-encryption, allowing medical service providers to securely and efficiently implement remote PHR monitoring and research. In this solution, only authorized doctors or research institutions can use the PHR, and permission delegation can be achieved using proxy re-encryption. However, all such solutions use the cloud server as a trusted third party. Once the cloud server is attacked, it may cause data leakage or single-point failure problems.

[0005] Blockchain technology has the characteristics of being publicly transparent, decentralized, and auditable, and can effectively solve the security problems in the data sharing solution with a cloud server as a trusted third party. For the MedSBA scheme based on attribute-based encryption, this scheme uses KP-ABE and CP-ABE to encrypt different subjects respectively to achieve fine-grained access control. At the same time, medical data consumers apply smart contracts for data transactions, and instant revocation of access rights can be achieved. By outsourcing part of the computing load to fog nodes, a multi-access control scheme is formed by integrating smart contracts and ABE to share more fine-grained electronic medical records. The main contribution of this scheme is to reduce the computing load of mobile terminals, and it also supports user revocation and attribute revocation. For the scenario where Internet of Things devices have limited resources, a proxy re-encryption method is proposed to protect data sharing in the cloud. The data owner can outsource its encrypted data to the cloud using identity-based encryption, and the proxy re-encryption construction will allow legitimate users to access the data, with edge devices acting as proxy servers to handle intensive computing. Secure sharing of medical data among multiple entities involving patients, research institutions, and semi-trusted cloud servers is achieved. The scheme uses zero-knowledge proof to verify whether the patient's medical data meets the specific requirements proposed by the research institution, and then ensures that the research institution decrypts the intermediate ciphertext through proxy re-encryption technology. However, such schemes are all based on PKI cryptography or identity-based cryptosystems, and there are problems such as complex certificate management or key escrow. At the same time, data requesters have the characteristic of dynamically entering and exiting the blockchain, and existing schemes cannot solve this problem well.

[0006] To solve the above problems, the present invention proposes a cross-chain data dynamic sharing scheme and a formal proof method. Summary of the Invention

[0007] The purpose of the present invention is to propose a cross-chain data dynamic sharing scheme and a formal proof method to solve the problems raised in the background technology:

[0008] Existing proxy re-encryption algorithms cannot solve the problems of certificate management and key escrow, and at the same time cannot cope with the characteristic that data requesters dynamically enter and exit the blockchain.

[0009] To achieve the above purpose, the present invention adopts the following technical solutions:

[0010] A cross-chain data dynamic sharing scheme includes the following steps:

[0011] S1: Define data transmission entities: Define data owner A, data user B, edge computing node ECN, and data conversion node DCN respectively;

[0012] S2: System Initialization: The ECN within the consortium blockchain generates system parameters, and uses a key generation algorithm to distribute partial private keys to A or B within the chain. A or B generates complete private keys and public keys; A generates an access control policy, and the ECN of the node to which B belongs B verifies the identity of B, the joining node, and grants B corresponding attributes;

[0013] S3: Data Encryption: A runs an encryption algorithm to encrypt the data to be shared and stores it in the local database, and stores the data index on the blockchain;

[0014] S4: Sending a Cross-chain Access Request: When B needs to obtain data, it sends a cross-chain access request to A;

[0015] S5: Verifying the Cross-chain Access Request: After receiving the request, A verifies the identity of B, and after successful verification, sends the response parameters to the ECN of the node to which A belongs A ;

[0016] S6: Obtaining the Data Ciphertext and Generating the Re-encryption Key: The ECN A searches for the index of relevant data according to B's permissions; and retrieves the data ciphertext from A's database according to the data index, and generates a re-encryption key, and sends the ciphertext and the re-encryption key to the DCN;

[0017] S7: Re-encrypting the Ciphertext: The DCN uses the re-encryption key to transform the ciphertext, and then sends the transformed ciphertext to B;

[0018] S8: Decrypting the Ciphertext: B uses its own private key to decrypt and thus obtains the data.

[0019] Preferably, the encryption algorithm in S3 is based on the CPRE algorithm, and the specific CPRE algorithm is as follows:

[0020] S3.1: The authoritative institution sets the algorithm according to system initialization, inputs the security parameter θ, and generates the system public parameter pa and the master key msk;

[0021] S3.2: The authoritative institution takes the master key msk as input and outputs the partial private key part of the data owner A A , and the data user B also generates the partial private key part B ;

[0022] S3.3: A takes the partial private key part A and the random number r1 as input, and outputs the user's complete private key sk A and the public key pk A , and B also generates the private key sk B and the public key pk B ;

[0023] S3.4: In the encryption algorithm, take the public parameter pa, the public key pk A and the message m as inputs, and output a ciphertext CT1;

[0024] S3.5: In the re-encryption key generation algorithm, take the private key sk of A A and the public key pk of B B as inputs, and output the re-encryption key Rk A→B ;

[0025] S3.6: In the re-encryption algorithm, take the re-encryption key Rk A→B and the ciphertext CT1 as inputs, and output the re-encrypted ciphertext CT2;

[0026] S3.7: In the decryption algorithm, take the re-encrypted ciphertext CT2 and the private key sk of B B as inputs, and output the plaintext m.

[0027] Preferably, in the cross-chain data dynamic sharing scheme, the dynamic sharing of cross-chain data is realized based on the CPRE algorithm, specifically as follows:

[0028] System initialization: Given two multiplicative cyclic groups G1, G2 of order p, g is the generator of the cyclic group G1, randomly select g1, g2 ∈ G1, and construct a bilinear mapping e: G1×G1 → G2; select two collision-resistant hash functions H1: G1 ← {0,1} * ; H1: G1 ← G2; the public system parameter pa = {G1, G2, g, e, p, H1, H2};

[0029] Key generation: The blockchain where the data holder A is located randomly selects as the master key, SK A = α, and calculate the public key PK A = g α ;

[0030] The blockchain where the data user B is located randomly selects as the master key, SK B = β, and calculate the public key PK B = g β ;

[0031] A sends a key application request to the affiliated node ECN A ; ECN A calculates the partial private key Part A of A = H1(ID A ) α and returns it to A, where ID ∈ {0,1} * ; A randomly selects and calculates its own complete private key sk A= r1H1(ID A ) α and the public key is the same as the key generated by A. For any data user B i After receiving the partial private key randomly selects to calculate its own private key public key Finally, its own public key is made public

[0032] Access control policy generation: The access control policy is automatically generated by A by calling the InitPolicyCreate(·) function:

[0033] InitPolicyCreate(attrs, data index ) → policy init

[0034] where attrs is the identity and context information of the current operator, and data index is the resource identifier returned after the file resource is encrypted and uploaded, and policy init is the combination of the subject policy and the context information policy;

[0035] When B meets the above policies at the same time, it has the right to correctly access A's file resources;

[0036] A also updates the access policy for the file resource by calling the UpdataPolicy(·) function:

[0037] UpdataPolicy(policy id , attrs') → policy new

[0038] where policy id is the original access policy index of the file resource, and attrs' is the new accessible attributes and context information set by A for the file resource;

[0039] Registration of user identity: Before B accesses A, the access policies and permissions for data usage in the blockchain where A is located are instantiated and sent to the consortium blockchain where B is located; When B is about to access A, ECN B verifies B's identity and determines B's attrs;

[0040] Data encryption: A randomly selects to encrypt the data m to form the ciphertext CT1 = (CT 11 , CT 12 ), where CT 11 = m·gt , The ciphertext is stored in the local database, and the ciphertext index data index is stored in the blockchain;

[0041] Send a cross-chain access request: B i When preparing to obtain data, send a data acquisition request message request to A. Among them, request is a specific data structure generated according to the request sent by B i and includes the attribute information of B i , the context information of the current operation, and the file resource information requested;

[0042] Verify the cross-chain access request: The two consortium chains connected by the relay chain synchronously deploy corresponding access policies; A judges the request request by calling the CheckAccess(·) function; if the request is successfully verified, A generates a token tk and randomly selects Generate Send request, tk, Rk1, together to ECN A ; if the verification fails, access is denied;

[0043] Obtain the data ciphertext and generate the re-encryption key: ECN A uses the search token tk as input and calls the Search(·) function to match with the file resource index data index ; after successful matching, retrieve the corresponding ciphertext CT1 from the local database of A; then ECN A randomly selects Calculate Rk3 = g λ to form the re-encryption key Finally, ECN A sends the ciphertext CT1 and the re-encryption key to DCN;

[0044] Re-encrypt the ciphertext: DCN re-encrypts the ciphertext CT1 using the re-encryption key to form the re-encrypted ciphertext CT2 = (CT 21 , CT 22 , CT 23 , CT 24 ), where CT 21 = CT 11 , CT 23 = Rk2, CT 24 = Rk3; finally, return CT2 to B i ;

[0045] Decrypt the ciphertext: B i Receive the ciphertext CT2; when given B i the key of B i obtain data through the following decryption steps:

[0046]

[0047] Proof of scheme correctness: First calculate Substitute

[0048] CT 24 = Rk3 = g λ into,

[0049] to get Next, calculate Substitute CT 21 = CT 11 = m·g t into, to get:

[0050] A formal proof method for a cross-chain data dynamic sharing scheme includes the following steps:

[0051] Step A: Pattern definition: Define the data exchanged in the scheme and the roles for data exchange using the normalized formal specification language, i.e., the basic unit pattern of the Z language, and define the types of the data involved in each pattern; also define each operation in the cross-chain data dynamic sharing scheme;

[0052] Step B: Z specification: For each of the above operation definitions, the Z language uses Z specifications to describe the processes of each operation in detail;

[0053] Step C: System state: Define the state during the process of the scheme according to the cross-chain data dynamic sharing scheme process, and be constrained by Z specifications during the state transition. Each operation stage corresponds to a corresponding system state, and the system presents corresponding results after the state ends;

[0054] Step D: Security property specification: Conduct confidentiality verification, integrity verification, and authentication verification on the cross-chain data dynamic sharing scheme respectively.

[0055] Preferably, the patterns in step A include: blockchain pattern, hospital pattern, edge conversion node pattern, data conversion node pattern, encrypted data pattern, re-encryption key pattern, re-encrypted ciphertext pattern, permission token pattern.

[0056] Preferably, the operations in step B include: key generation, permission granting, data encryption, re - key generation, ciphertext re - encryption, and ciphertext decryption.

[0057] Compared with the prior art, the present invention provides a cross - chain data dynamic sharing scheme and a formal verification method, having the following beneficial effects:

[0058] The present invention defines a certificateless proxy re - encryption (CPRE) algorithm suitable for cross - chain data sharing, solves the problems of certificate management and key escrow existing in other proxy re - encryption algorithms, and has high security in the application scenario of data sharing; details a cross - chain data dynamic sharing scheme based on CPRE, realizes efficient fine - grained data sharing, and at the same time ensures that the data owner has full control over its data. It also uses the Z language for formal definition and description to ensure the correctness of the scheme. The present invention can enable the data owner to perform one - to - many data sharing offline and has the characteristic that data requesters can dynamically enter and exit the blockchain. BRIEF DESCRIPTION OF THE DRAWINGS

[0059] Figure 1 It is a schematic diagram of the cross - chain data dynamic sharing scheme model mentioned in Embodiment 1 of the present invention;

[0060] Figure 2 It is an example diagram of key generation mentioned in Embodiment 1 of the present invention;

[0061] Figure 3 It is an example diagram of permission granting mentioned in Embodiment 1 of the present invention;

[0062] Figure 4 It is an example diagram of data encryption mentioned in Embodiment 1 of the present invention;

[0063] Figure 5 It is an example diagram of re - key generation mentioned in Embodiment 1 of the present invention;

[0064] Figure 6 It is an example diagram of ciphertext re - encryption mentioned in Embodiment 1 of the present invention;

[0065] Figure 7 It is an example diagram of ciphertext decryption mentioned in Embodiment 1 of the present invention;

[0066] Figure 8 It is an example diagram of state transition mentioned in Embodiment 1 of the present invention;

[0067] Figure 9 It is a schematic diagram of the verification result of the scyther on the protocol of Embodiment 1 mentioned in Embodiment 2 of the present invention;

[0068] Figure 10 It is a schematic diagram of the calculation time of data encryption mentioned in Embodiment 2 of the present invention;

[0069] Figure 11 It is a schematic diagram of the calculation time of re-encryption mentioned in Embodiment 2 of the present invention;

[0070] Figure 12 It is a schematic diagram of the calculation time of data decryption mentioned in Embodiment 2 of the present invention;

[0071] Figure 13 It is a schematic diagram of the average calculation time of adding data and permission judgment mentioned in Embodiment 2 of the present invention. Detailed implementation manners

[0072] Next, the technical solutions in the embodiments of the present invention will be clearly and completely described in conjunction with the accompanying drawings in the embodiments of the present invention. Obviously, the described embodiments are only a part of the embodiments of the present invention, rather than all the embodiments.

[0073] The present invention defines a certificate-free proxy re-encryption (CPRE) algorithm suitable for cross-chain data sharing, solves the problems of certificate management and key escrow existing in other proxy re-encryption algorithms, and has high security in the application scenario of data sharing; a cross-chain data dynamic sharing scheme based on CPRE is described in detail, realizing efficient fine-grained data sharing, and at the same time ensuring the complete control of the data owner over its data. It is also formally defined and described using the Z language to ensure the correctness of the scheme. The present invention can realize one-to-many data sharing by the data owner offline and has the characteristic that data requesters can dynamically enter and exit the blockchain. Specifically, it includes the following contents.

[0074] Embodiment 1:

[0075] Please refer to Figure 1-8 , a cross-chain data dynamic sharing scheme and a formal proof method of the present invention, and the cross-chain data dynamic sharing scheme includes the following steps:

[0076] S1: Define data transmission entities: Define the data owner A, the data user B, the edge computing node ECN, and the data conversion node DCN respectively;

[0077] S2: System initialization: The ECN in the consortium chain generates system parameters, uses the key generation algorithm to distribute partial private keys for A or B in the chain, and A or B generates complete private keys and public keys; A generates an access control policy, and the ECN of the node to which B belongs B verifies the identity of B joining the node and grants B corresponding attributes;

[0078] S3: Data encryption: A runs the encryption algorithm to encrypt the data to be shared and stores it in the local database, and stores the data index on the blockchain;

[0079] S4: Send a cross-chain access request: When B needs to obtain data, it sends a cross-chain access request to A.

[0080] S5: Verify the cross-chain access request: After receiving the request, A verifies B's identity. After successful verification, it sends the response parameters to A's affiliated node ECN A ;

[0081] S6: Obtain the data ciphertext and generate the re-encryption key: Obtain the ECN A Search for the index of relevant data according to B's permissions; retrieve the data ciphertext from A's database according to the data index, and generate a re-encryption key, and send the ciphertext and the re-encryption key to DCN;

[0082] S7: Re-encrypt the ciphertext: DCN uses the re-encryption key to convert the ciphertext, and then sends the converted ciphertext to B;

[0083] S8: Decrypt the ciphertext: B uses its own private key to decrypt and then obtains the data.

[0084] Based on the above steps, taking the medical scenario as an example, assume that there are two consortium chains relying on the relay chain as a trusted entity for data transmission, and there are four entities: a hospital, a medical research institution, an edge computing node, and a data conversion node. The scheme model is as Figure 1 shown. The specific functions of each entity are as follows:

[0085] Hospital (A): That is, the data owner, stores medical data in the local database, and stores the data index in the blockchain, and can share their data conditionally and obtain benefits in the process.

[0086] Medical research institution (B): That is, the data user, needs to securely obtain the data of the hospital.

[0087] Edge computing node (ECN): As a fully trusted entity within the consortium chain, it is responsible for generating the master key, system parameters, verifying the identity of users joining the node, and distributing public and private keys to users after successful verification, and granting users permissions.

[0088] Data conversion node (DCN): An incompletely trusted node within the relay chain. It will complete the ciphertext conversion as required, but it is curious about the content of the converted ciphertext.

[0089] During the data sharing process, taking confidentiality, integrity, and availability as security goals, specifically as follows: Confidentiality: It means that data can only be accessed by authorized users or systems, and unauthorized users cannot obtain the content of the data.

[0090] Integrity: Data is not tampered with, damaged, or modified during transmission and storage, maintaining its original state.

[0091] Availability: The availability of data means that the data can be accessed and used by legitimate users or systems in a timely and reliable manner when needed.

[0092] The CPRE algorithm effectively solves the certificate management problem and the key escrow problem. The CPRE algorithm consists of the following steps:

[0093] (1) Setup(θ → pa, msk): The authority generates the system public parameters pa and the master secret key msk according to the system initialization setup algorithm, inputting the security parameter θ.

[0094] (2) Part-KeyGen(msk → part A ): The authority takes the master secret key msk as input and outputs the partial private key part A of user A. Similarly, user B generates the partial private key part B ;

[0095] (3) KeyGen(part A , r1 → sk A , pk A ): The user takes the partial private key part A and the random number r1 as input and outputs the user's complete private key sk A and public key pk A . Similarly, user B generates the complete private key sk B and public key pk B ;

[0096] (4) Encrypt(pk A , m → CT1): In the encryption algorithm, the public parameters pa, the public key pk A and the message m are taken as input, and a ciphertext CT1 is output.

[0097] (5) Re-KeyGen(pk B , sk A → Rk A→B ): In the re-encryption key generation algorithm, the private key sk A of user A and the public key pk B of user B are taken as input, and the re-encryption key Rk A→B is output.

[0098] (6) Re-Encrypt(Rk A→B , CT1 → CT2): In the re-encryption algorithm, the re-encryption key RkA→B Take the ciphertext CT1 and the re-encryption key as inputs, and output the re-encrypted ciphertext CT2;

[0099] (7) Decrypt(CT2, sk B →CT2): In the decryption algorithm, take the re-encrypted ciphertext CT2 and the private key sk of user B B as inputs, and output the plaintext m.

[0100] Based on the above CPRE algorithm, the dynamic sharing of cross-chain data is realized as follows:

[0101] System initialization: Given two multiplicative cyclic groups G1 and G2 of order p, where g is the generator of cyclic group G1, randomly select g1, g2 ∈ G1, and construct a bilinear mapping e: G1 × G1 → G2; select two collision-resistant hash functions H1: G1 ← {0, 1} * ; H1: G1 ← G2; the public system parameters pa = {G1, G2, g, e, p, H1, H2};

[0102] Key generation: The blockchain where data holder A is located randomly selects as the master key, SK A = α, and calculate the public key PK A = g α ;

[0103] Data user B i in the blockchain where it is located randomly selects as the master key, SK B = β, and calculate the public key PK B = g β ;

[0104] A sends a key application request to its affiliated node ECN A ; ECN A calculates the partial private key Part A = H1(ID A ) α and returns it to A, where ID ∈ {0, 1} * ; A randomly selects and calculates its own complete private key sk A = r1H1(ID A ) α and the public key which is the same as the key generated by A. Any data user B i after receiving the partial private key randomly selects and calculates its own private key and public key Finally, publicly disclose its own public key pk A ,

[0105] Access control policy generation: The access control policy is automatically generated by A by calling the InitPolicyCreate(·) function:

[0106] InitPolicyCreate(attrs,data index )→policy init

[0107] where attrs is the identity and context information of the current operator, and data index is the resource identifier returned after the file resource is encrypted and uploaded, and policy init is the combination of the principal policy and the context information policy;

[0108] When B meets the above policies at the same time, it has the permission to correctly access the file resources of A;

[0109] A also updates the access policy for file resources by calling the UpdataPolicy(·) function:

[0110] UpdataPolicy(policy id ,attrs')→policy new

[0111] where policy id is the original access policy index of the file resource, and attrs' is the new accessible attributes and context information set by A for the file resource;

[0112] Registration of user identity: Before B accesses A, the access policies and permissions for data usage in the blockchain where A is located are instantiated and sent to the consortium blockchain where B is located; when B prepares to access A, ECN B verifies B's identity and determines B's attrs;

[0113] Data encryption: A randomly selects to encrypt the data m to form the ciphertext CT1=(CT 11 ,CT 12 ), where CT 11 =m·g t , the ciphertext is stored in the local database, and the ciphertext index data index is stored in the blockchain;

[0114] Sending a cross-chain access request: When B i is about to obtain a certain data, it sends a data acquisition request message request to A, where request is based on B iThe specific data structure generated by the request sent includes B i attribute information, context information of the current operation and requested file resource information;

[0115] Verify cross-chain access request: The two consortium chains connected by the relay chain synchronously deploy corresponding access policies; A judges the request by calling the CheckAccess(·) function; if the request is successfully verified, A generates a token tk and randomly selects generate request, tk, Rk1, Send to ECN together A ; If authentication fails, access is denied;

[0116] Data ciphertext acquisition and re-encryption key generation: ECN A Take the search token tk as input and call the Search(·) function to index the file resource data. index After the match is successful, the corresponding ciphertext CT1 is retrieved from A's local database; then ECN A Random Selection calculate Rk3=g λ , forming the re-encryption key Last ECN A The ciphertext CT1 and the re-encryption key Send to DCN;

[0117] Ciphertext re-encryption: DCN uses re-encryption keys The ciphertext CT1 is re-encrypted to form a re-encrypted ciphertext CT2 = (CT 21 ,CT 22 ,CT 23 ,CT 24 ),in CT 23 =Rk2,CT 24 =Rk3; finally return CT2 to B i ;

[0118] Decrypted ciphertext: B i Receive the ciphertext CT2; when given B i Key B i Get the data through the following decryption steps:

[0119]

[0120] Proof of correctness of the scheme: First calculate Will

[0121] CT 24 = Rk3 = g λ Substitute

[0122] to obtain Next, calculate Substitute CT 21 = CT 11 = m·g t Substitute to obtain:

[0123] The above steps describe the specific details of the cross-chain data dynamic sharing scheme based on the CPRE algorithm. In terms of security, to ensure the integrity and confidentiality of the data in the implementation scheme, the formal definition of the above scheme is carried out using the formal specification language, namely the Z language. Through the Z language specification, the confidentiality and integrity of the data in the scheme can be guaranteed, and the authentication and data authorization of the scheme can be verified, as follows:

[0124] Scheme definition:

[0125] 1. Schema definition: The data interacted in the scheme and the roles of data interaction are defined using the basic unit schema of the Z language, and the types of the data involved in each schema are defined:

[0126] (1) Blockchain schema: schema Blockchain ::= [SK BC : Int, PK BC : Int], which contains two pieces of information, the master key of the blockchain and the public key of the blockchain;

[0127] (2) Hospital schema: schema Hospital ::= [ID: String, part A : Int, sk A : Int, pk A : Int], where the hospital in the scheme contains the ID number of the hospital, partial private key, complete private key, and public key;

[0128] (3) Medical research institution schema: schema ResearchInstitution ::= [ID: String, part B : Int, sk B : Int, pk B : Int], where the medical research institution in the scheme contains the ID number of the institution, partial private key, complete private key, and public key;

[0129] (4) Edge Transformation Node Pattern: schema ECN::=[ID:String]

[0130] (5) Data Transformation Node Pattern: schema DCN::=[ID:String]

[0131] (6) Encrypted Data Pattern: schema EncryptedData::=[CT 11 :Int,CT 12 :Int], the data to be encrypted in the system is encrypted as CT1=(CT 11 ,CT 12 );

[0132] (7) Re - Encryption Key Pattern: schema ReEncryptionKey::=[Rk1:Int,Rk2:Int,Rk3:Int];

[0133] (8) Re - Encrypted Ciphertext Pattern: schema ReEncryptedData::=[CT 21 :Int,CT 22 :Int,CT 23 :Int,CT 24 :Int], and the ciphertext is re - encrypted using the re - encryption key;

[0134] (9) Permission Token Pattern: schema PermissionToken::=[token:Bool]

[0135] 2. Scheme Operation Definitions

[0136] (1) Key Generation: Refer to Figure 2 , in the key generation stage, define operations such as generateMainKey, requestPartialPrivatekey, calculateCompletePrivateKey to generate the keys required by each participant in the system.

[0137] (2) Permission Granting: Refer to Figure 3 , in the permission granting stage, two operations are defined in total. The research institution generates a permission request and verifies it according to the generated request, and sends the corresponding permission token.

[0138] (3) Data Encryption: Refer to Figure 4 , in this stage, three operations are defined. First, encrypt the data to generate ciphertext data, then store the ciphertext data in the database and store the corresponding index in the blockchain.

[0139] (4) Re - Key Generation: Refer toFigure 5 , according to the 4-step operations defined in the solution steps, first the hospital randomly selects numbers for calculation to generate a re-encryption key. Secondly, when the ECN receives an access request, it first performs token authentication. If the authentication is successful, it retrieves the corresponding ciphertext locally at the hospital according to the index. Secondly, it uses the token to call a function to match with the file resource index. Finally, it forms a re-encryption key based on the identity information.

[0140] (5) Ciphertext re-encryption: Refer to Figure 6 , after obtaining the re-encryption key, use the generated re-encryption key to re-encrypt the ciphertext to obtain re-encrypted ciphertext data; finally, return the obtained ciphertext data to the research institution.

[0141] (6) Decrypt the ciphertext: Refer to Figure 7 , finally, define the operation in the ciphertext decryption stage. After receiving the re-encrypted ciphertext data, the research institution decrypts it.

[0142] Z specification:

[0143] For each of the above operation definitions, the Z language uses Z specification to describe the process of each operation in detail, and fully reflects the solution process through preconditions and subsequent operations. The specific process can be referred to as follows:

[0144]

[0145]

[0146]

[0147] System status:

[0148] 1. Status definition:

[0149] Define several statuses during the execution of the solution according to the solution process, as follows:

[0150] SystemInit: The system is initializing and about to start.

[0151] KeyGeneration: The system is generating keys.

[0152] HospitalKeyGeneration: The hospital is generating keys.

[0153] ResearchInstitutionKeyGeneration: The medical research institution is generating keys.

[0154] PermissionGranting: The system is granting permissions.

[0155] QueueDataEncryption: The system is encrypting data.

[0156] ReEncryptionKeyGeneration: The system is generating a re-encryption key.

[0157] DataRetrieval: The system is retrieving data.

[0158] DataDecryption: The system is decrypting data.

[0159] 2. State Transition

[0160] Refer to Figure 8 , and at the same time, the state transition of the system also needs to be constrained by z specification. Each operation stage corresponds to a corresponding system state, and the system presents corresponding results after the state ends. The following example can be referred to:

[0161] # System Initialization

[0162] InitSystem == SystemInit == {InitialiseSystem}

[0163] # Key Generation

[0164] GenerateKeys == KeyGeneration == {HospitalKeyGenerationFinished, ResearchInstitutionKeyGenerationFinished}

[0165] # Hospital Key Generation

[0166] GenerateHospitalKeys == HospitalKeyGeneration == {HospitalKeyGenerationFinished}

[0167] # Medical Research Institution Key Generation

[0168] GenerateResearchInstitutionKeys == ResearchInstitutionKeyGeneration == {ResearchInstitutionKeyGenerationFinished}

[0169] # Permission Grant

[0170] GrantPermissions == PermissionGranting == {PermissionGrantingFinished}

[0171] # Data Encryption

[0172] EncryptData == QueueDataEncryption == {QueueDataEncryptionFinished}

[0173] # Re - encryption Key Generation

[0174] GenerateReEncryptionKey == ReEncryptionKeyGeneration == {ReEncryptionKeyGenerationFinished}

[0175] # Data Retrieval

[0176] RetrieveData == DataRetrieval == {DataRetrievalFinished}

[0177] # Data Decryption

[0178] DecryptData == DataDecryption

[0179] 4 Security Attribute Specification:

[0180] 1. Confidentiality Verification: The following example can be referred to:

[0181]

[0182] Among them, DataEncryptionCorrect ensures that all hospitals can encrypt the data and generate the encrypted data. DataDecryptionCorrect ensures that only authorized medical research institutions can decrypt the encrypted data, thus ensuring the confidentiality of the data.

[0183] 2. Integrity Verification: The following example can be referred to:

[0184]

[0185]

[0186] The specification of the above example verifies the integrity of the ciphertext stored in the hospital database, and the data will not be tampered with or damaged during the encryption and decryption processes.

[0187] 3. Authentication verification: The following example can be referred to:

[0188]

[0189] The above example ensures the correct authentication of the parties in the system, that is, all hospitals and medical research institutions can successfully generate their own key pairs.

[0190] Example 2:

[0191] Taking the medical scenario as an example, assume that there are two consortium chains relying on the relay chain as the trust entity for data transmission, and there are four entities: hospitals, medical research institutions, edge computing nodes, and data conversion nodes. The scheme model is as Figure 1 shown. Based on scyther, the protocol of Example 1 is verified. The verification results can be referred to Figure 9 . As can be seen from the figure, the protocols of Example 1 all pass the verification. The calculation time of the data encryption stage of Example 1 is also statistically analyzed. The specific results can be referred to Figure 10 , Figure 10 shows the calculation time in the data encryption stage. The size of the general attribute set is set to 1000, and the size of the access policy during the generation of the original ciphertext is 20. It can be found that for the three schemes, as the number of users increases, the calculation time increases steadily. This is because each encryption operation is performed for a single user, and when the number of users increases exponentially, the encryption calculation time also increases exponentially. The reason why the calculation time of the 2nd line segment is generally larger is that both the encryption and decryption times are related to the complexity of the access policy.

[0192] The calculation time of the data re-encryption stage of Example 1 is also statistically analyzed. The specific results can be referred to Figure 11 , Figure 11 shows the calculation time in the re-encryption stage. Similar to the encryption stage, when the number of users increases exponentially, the re-encryption calculation time also increases exponentially.

[0193] Refer to Figure 12 to statistically analyze the calculation time of data decryption. As can be seen from the figure, similar to the encryption stage, when the number of users increases exponentially, the data decryption calculation time also increases exponentially.

[0194] In Hyperledger Fabric, two organizations are established to simulate the dynamic sharing of data in a cross-chain environment. In each experiment, these two organizations represent a hospital and a medical research institution respectively to simulate the dynamic sharing process of data. The two organizations jointly join the same channel and use the Raft consensus. The computing times for adding data and making permission judgments are respectively tested. The experimental data is obtained by averaging the results of 10 repeated experiments. Among them, adding data includes the combined time of data upload and automatically generating access policies according to templates, while the permission judgment is the time from when the user sends a request to when the permission judgment of the solution in Example 1 is completed. The experiments are carried out for 100 - 1.00E+11 data uploads and data requests, with each increase being 10 times. The data upload consumption time and permission judgment time of the solution in Example 1 at this magnitude are respectively measured. The specific measurement results can be referred to Figure 13 , as can be seen from the figure, with the increase in the number of data uploads and data requests, the changes in the average data upload consumption time and permission judgment time of the solution in Example 1 are relatively stable, and the time consumption is short, proving that the solution in Example 1 has high stability and efficiency.

[0195] The above is only a preferred specific implementation manner of the present invention, but the protection scope of the present invention is not limited thereto. Any person skilled in the art within the technical scope disclosed by the present invention, according to the technical solution and inventive concept of the present invention, makes equivalent substitutions or changes, and should be covered by the protection scope of the present invention.

Claims

1. A cross-chain data dynamic sharing scheme, characterized in that, It includes the following steps: S1: Define data transfer entities: Define the data owner A, data user B, edge computing node ECN, and data conversion node DCN respectively; S2: System initialization: The ECN within the consortium blockchain generates system parameters, and uses a key generation algorithm to distribute partial private keys to A or B within the chain. A or B generates a complete private key and a public key; A generates an access control policy, and the ECN of the node to which B belongs B verifies the identity of B for the joining node and grants B corresponding attributes; S3: Data encryption: A runs an encryption algorithm to encrypt the data to be shared and stores it in the local database, and stores the data index on the blockchain; S4: Send a cross-chain access request: When B needs to obtain data, it sends a cross-chain access request to A; S5: Verify the cross-chain access request: After receiving the request, A verifies the identity of B. After successful verification, the response parameters are sent to the node ECN to which A belongs A ; S6: Obtaining Data Ciphertext and Generating Re-encryption Key: Obtain the ECN A Search for the indexes of relevant data according to B's permissions; retrieve the data ciphertext from A's database based on the data indexes, and generate a re-encryption key, then send the ciphertext and the re-encryption key to the DCN; S7: Ciphertext re-encryption: DCN uses the re-encryption key to convert the ciphertext and then sends the converted ciphertext to B; S8: Decrypt the ciphertext: B uses its own private key to decrypt and then obtains the data.

2. The cross-chain data dynamic sharing scheme according to claim 1, wherein The encryption algorithm described in S3 is based on the CPRE algorithm, and the specific CPRE algorithm is as follows: S3.1: The authoritative agency sets the algorithm according to the system initialization, inputs the security parameter θ, and generates the system public parameter pa and the master key msk; S3.2: The authoritative institution takes the master secret key msk as input and outputs the partial private key part of data owner A A , and data user B also generates the partial private key part B ; S3.3: A takes part of the private key part A and the random number r1 as inputs, and outputs the user's complete private key sk A and the public key pk A , and B also generates the private key sk B and the public key pk B ; S3.4: In the encryption algorithm, use the public parameters pa, the public key pk A and the message m as inputs, and output a ciphertext CT1; S3.5: In the re-encryption key generation algorithm, take the private key sk of A A and the public key pk of B B as inputs and output the re-encryption key PK A→B ; S3.6: In the re-encryption algorithm, use the re-encryption key PK A→B and the ciphertext CT1 as inputs, and output the re-encrypted ciphertext CT2; S3.7: In the decryption algorithm, use the re-encrypted ciphertext CT2 and the private key sk of B B as inputs and output the plaintext m.

3. The cross-chain data dynamic sharing scheme according to claim 2, characterized in that In the cross-chain data dynamic sharing scheme, the dynamic sharing of cross-chain data is realized based on the CPRE algorithm, specifically as follows: System initialization: Given two multiplicative cyclic groups \(G_1\) and \(G_2\) of order \(p\), \(g\) is the generator of cyclic group \(G_1\). Randomly select \(g_1, g_2\in G_1\) and construct a bilinear map \(e: G_1\times G_1\rightarrow G_2\); select two collision-resistant hash functions \(H_1: G_1\leftarrow\{0,1\}\) * ; \(H_1: G_1\leftarrow G_2\); public system parameters \(pa = \{G_1, G_2, g, e, p, H_1, H_2\}\); Key generation: Randomly select in the blockchain where data holder A is located as the master key, SK A = α, and calculate the public key PK A = g α ; Randomly select from the blockchain where data user B is located As the master key, SK B = β, and calculate the public key PK B = g β ; A sends a key application request to the affiliated node ECN A ; The ECN A calculates the partial private key Part of A A = H1(ID A ) α and returns it to A, where ID ∈ {0, 1} * ; A randomly selects and calculates its own complete private key sk A = r1H1(ID A ) α and public key pk A = g skA ; Similar to the key generation with A, the data user B i receives the partial private key Part Bi = H1(ID Bi ) β and then randomly selects to calculate its own private key and public key Finally, it publishes its own public key pk A , pk Bi ; Access control policy generation: The access control policy is automatically generated by A by calling the InitPolicyCreate(·) function: InitPolicyCreate(attrs,data index )→policy init Among them, attrs is the identity and context information of the current operator, and data index is the resource identifier returned after the file resource is encrypted and uploaded, and policy init is the combination of the main policy and the context information policy; When B meets the above policies at the same time, it has the right to correctly access A's file resources; A also updates the access policy for file resources by calling the UpdataPolicy(·) function: UpdataPolicy(policy id ,attrs')→policy new where policy id is the original access policy index of the file resource, and attrs' are the new accessible attributes and context information set by A for the file resource; Registered user identity: Before B accesses A, the access policies and permissions for the data usage in the blockchain where A is located are instantiated and sent to the consortium blockchain where B is located; when B is ready to access A, the ECN B verifies B's identity and determines B's attrs; Data Encryption: A randomly selects to encrypt the data m to form the ciphertext CT1 = (CT 11 , CT 12 ), where CT 11 = m·g t , The ciphertext is stored in the local database, and the ciphertext index data index is stored in the blockchain; Send a cross-chain access request: B i When preparing to obtain data, send a data acquisition request message request to A, where request is a specific data structure generated according to the request sent by B i and includes the attribute information of B i , the context information of the current operation, and the requested file resource information; Verify cross-chain access request: Two consortium blockchains connected by a relay chain synchronously deploy corresponding access policies; A judges the request request by calling the CheckAccess(·) function; If the request is successfully verified, A generates a token tk and randomly selects Generate Send request, tk, Rk1, To ECN together A ; If the verification fails, access is denied; Data ciphertext acquisition and re-encryption key generation: ECN A Take the search token tk as input and match it with the file resource index data by calling the Search(·) function index After successful matching, retrieve the corresponding ciphertext CT1 from the local database of A; then ECN A Randomly select Calculate Rk3 = g λ to form the re-encryption key Finally, ECN A Send the ciphertext CT1 and the re-encryption key to DCN; Ciphertext Re-encryption: DCN uses the re-encryption key to re-encrypt the ciphertext CT1 to form the re-encrypted ciphertext CT2 = (CT 21 , CT 22 , CT 23 , CT 24 ), where CT 23 = Rk2, CT 24 = Rk3; finally, return CT2 to B i ; Decrypt the ciphertext: B i Receive ciphertext CT2; when given B i key B i Obtain data through the following decryption steps: Proof of the correctness of the solution: First, calculate Put CT 24 = Rk3 = g λ Substitute Obtain Next, calculate Take CT 21 = CT 11 = m·g t Substitute to obtain:

4. A formal proof method for a cross-chain data dynamic sharing scheme according to any one of claims 1-3, characterized in that, It includes the following steps: Step A: Mode definition: Define the data interacted in the scheme and the roles for data interaction in a normalized formal specification language, that is, the basic unit mode of the z language, and define the types of the data involved in each mode: Also define each operation in the cross-chain data dynamic sharing scheme; Step B: z specification: For each of the above operation definitions, the z language uses z specifications to describe the processes of each operation in detail; Step C: System state: Define the state during the process of the scheme according to the cross-chain data dynamic sharing scheme process, and the state transition process is constrained by z specifications. Each operation stage corresponds to a corresponding system state, and the system presents corresponding results after the state ends; Step D: Security attribute specification: Conduct confidentiality verification, integrity verification, and authentication verification on the cross-chain data dynamic sharing scheme respectively.

5. The formal proof method for a cross-chain data dynamic sharing scheme according to claim 4, characterized in that, The modes in Step A include: blockchain mode, hospital mode, edge conversion node mode, data conversion node mode, encrypted data mode, re-encryption key mode, re-encrypted ciphertext mode, permission token mode.

6. The formal proof method for a cross-chain data dynamic sharing scheme according to claim 4, characterized in that The operations in Step B include: key generation, permission granting, data encryption, re-key generation, ciphertext re-encryption, ciphertext decryption.

Images