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 proxy re-encryption algorithm, the proxy re-encryption algorithm disclosed by the invention solves the problems that the existing proxy re-encryption algorithm cannot solve the problems of certificate management and key escrow, and cannot cope with the characteristic that a demander of queue data has dynamic access to a block chain; a CPRE algorithm suitable for cross-chain data sharing is defined, the problems of certificate management and key escrow existing in other proxy re-encryption algorithms are solved, and high safety is achieved in a data sharing application scene; 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 field of data sharing technology, and in particular to a cross-chain data dynamic sharing solution and a formal proof method. Background Art

[0002] Medical data plays a vital role in modern medical research. However, since medical data is usually managed independently by various hospitals, the sharing of medical data faces many challenges. Blockchain can enhance trust between 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, as people continue to deepen their research on the causes of complex diseases, the demand for cohort data continues to rise, and there is an urgent need for a safe and reliable data sharing solution to share data between different cohorts. However, the existing data sharing solutions based on cloud servers have problems of data leakage or single point failure, and the data sharing solutions based on blockchain have problems of complex certificate management or key escrow, and cannot solve the characteristics of dynamic entry and exit of the blockchain by demanders of cohort data.

[0003] Cohort data is widely used in disease association studies, which can reveal the causes of diseases and thus improve the level of disease prevention and treatment. Currently, major hospitals around the world have established their own cohort databases. As people continue to deepen their research on the causes of complex diseases, the demand for cohort data has gradually evolved from a single cohort to a more complex multi-cohort, and the same cohort data is often needed by multiple users. However, due to the inability to guarantee the privacy of cohort data and the security of the data sharing process, data cannot be shared among different cohorts.

[0004] Cloud computing is often used as a trusted third party in medical data sharing solutions because of its sufficient storage and computing power. There are many existing solutions that 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 the use of the public key of the data demander to encrypt the data, and only the private key of the data demander can decrypt the data. This one-to-one data sharing solution is very inefficient. Attribute encryption (ABE) is considered to be 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 technicians first proposed the concept of ABE. It is further proposed to protect the integrity of electronic medical records stored in the public cloud by using blockchain and distributed database technology to avoid misdiagnosis caused by incorrect electronic health records tampered by malicious users or internal institutions. A cloud-assisted medical Internet of Things (MIoT) fine-grained data sharing solution is also designed, which can achieve efficient and fine-grained access control and ciphertext keyword search, and allow malicious data users to be revoked. However, the computational overhead of ABE-based data sharing schemes increases linearly with the increase of attributes, and is not suitable for cross-queue data sharing scenarios with multiple requirements. Proxy re-encryption (PRE) came into being, which allows the proxy to convert the ciphertext encrypted by the data owner with his own public key into the ciphertext that the data demander can decrypt with his own private key. The proxy is not fully trusted and cannot obtain the private keys of the communicating parties. Later, a new verifiable and fair attribute-based proxy re-encryption (VF-ABPRE) scheme was proposed to support verifiability and fairness. Verifiability enables the sharing user to verify whether the re-encrypted ciphertext returned by the server is correct. Another scheme applies searchable proxy re-encryption, allowing medical service providers to implement remote PHR monitoring and research securely and efficiently. In this scheme, only authorized doctors or research institutions can use PHR, and proxy re-encryption can be used to implement permission delegation. However, such schemes all use cloud servers as trusted third parties. Once the cloud server is attacked, it may cause data leakage or single point failure problems.

[0005] Blockchain technology has the characteristics of openness, transparency, decentralization and auditability, which can effectively solve the security problems in data sharing schemes with cloud servers as trusted third parties. For the attribute-based encryption MedSBA scheme, the 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 to trade data, which can realize the instant revocation of access rights. Part of the computing load is outsourced to fog nodes, and a multi-access 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 of resource-constrained IoT devices, a proxy re-encryption method is proposed to protect data sharing in the cloud. Data owners can outsource their encrypted data to the cloud using identity-based encryption, and the proxy re-encryption construction will allow legitimate users to access the data, and the edge device acts as a proxy server to handle intensive computing. Secure sharing of medical data between 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 of the research institution, and then uses proxy re-encryption technology to ensure that the research institution decrypts the intermediate ciphertext. However, such schemes are based on PKI passwords or identity-based cryptographic systems, which have complex certificate management or key escrow issues. At the same time, the demanders of queue data have the characteristics of dynamic entry and exit of the blockchain, and the existing scheme cannot solve this problem well.

[0006] In order to solve the above problems, the present invention proposes a cross-chain data dynamic sharing solution and a formal proof method. Summary of the invention

[0007] The purpose of this 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] The existing proxy re-encryption algorithm cannot solve the problems of certificate management and key custody, and cannot cope with the fact that queue data demanders dynamically enter and exit the blockchain.

[0009] In order to achieve the above object, the present invention adopts the following technical solutions:

[0010] A cross-chain data dynamic sharing solution 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 in the alliance chain generates system parameters and uses the key generation algorithm to distribute public and private keys to A or B in the chain; A generates an access control policy, and B's node ECN B Verify the identity of B who joins the node and grant 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: Send a cross-chain access request: When B needs to obtain data, it sends a cross-chain access request to A;

[0015] S5: Verify cross-chain access request: After receiving the request, A verifies B’s identity and sends the response parameters to A’s ECN node after successful verification. A ;

[0016] S6: Obtaining data ciphertext and generating re-encryption keys: Obtaining ECN A Search the index of relevant data according to B's authority; retrieve the data ciphertext from A's database according to the data index, generate a re-encryption key, and send the ciphertext and re-encryption key to DCN;

[0017] S7: Ciphertext re-encryption: DCN uses the re-encryption key to convert the ciphertext and then sends the converted ciphertext to B;

[0018] S8: Decrypt the ciphertext: B uses his own private key to decrypt and obtain the data.

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

[0020] S3.1: The authority sets the algorithm based on the system initialization, inputs the security parameter θ, and generates the system public parameter pa and the master key msk;

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

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

[0023] S3.4: In the encryption algorithm, the public parameters pa and public key pk are used.A and message m as input, and output a ciphertext CT1;

[0024] S3.5: In the re-encryption key generation algorithm, A's private key sk A and B's public key pk B As input, output re-encryption key Re A→B ;

[0025] S3.6: The re-encryption key Re is used in the re-encryption algorithm A→B and ciphertext CT1 as input, and output the re-encrypted ciphertext CT2;

[0026] S3.7: In the decryption algorithm, the re-encrypted ciphertext CT2 and B's private key sk B As input, output plaintext m.

[0027] Preferably, in the cross-chain data dynamic sharing solution, dynamic sharing of cross-queue data is achieved based on the CPRE algorithm, as follows:

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

[0029] Key generation: Randomly select the blockchain where data holder A is located As the master key, SK A = α, and calculate the public key

[0030] The blockchain where data user B is located is randomly selected As the master key, SK B =β, and calculate the public key

[0031] A to the node ECN A Send key application request; ECN A Calculate A's private key sk A =H1(ID A )α, where ID∈{0,1} * ; and calculate the public key The same as A generates the key, any data user B i Calculate your own private key Public Key Finally, publish your own public key pk A ,

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

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

[0034] Among them, attrs is the identity and context information of the current operator, data index It is the resource identifier returned after the file resource is encrypted and uploaded. init It is a combination of subject strategy and contextual information strategy;

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

[0036] A also calls the UpdataPolicy(·) function to update the access policy of the file resource:

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

[0038] Among them, 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] Registered user identity: Before B accesses A, the access policy and permissions used by the data in A’s blockchain are instantiated and sent to B’s consortium chain; when B prepares A, ECN B Verify B's identity and determine B's attrs;

[0040] Data encryption: A random selection Encrypt the data m to form a 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 Stored in blockchain;

[0041] Send cross-chain access request: B i When preparing to obtain data from a queue, a request message is sent to A to obtain data. The 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;

[0042] 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;

[0043] 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;

[0044] 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 ), where CT 21 =CT 11 , CT 23 =Rk2,CT 24 =Rk3; finally return CT2 to B i ;

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

[0046]

[0047] Proof of correctness of the solution: Calculation Will CT 24 =Rk3=g λ ,get Next, calculate Will CT 21 =CT 11 =m·g t Substituting in, we get:

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

[0049] Step A: Mode definition: define the data interacting in the scheme and the roles performing data interaction using a standardized form of description language, i.e., the basic unit mode of the z language, and define the type of data designed in each mode: also define each operation in the cross-chain data dynamic sharing scheme;

[0050] Step B: z-regulation: For each of the above operation definitions, z-language uses z-regulation to describe the process of each operation in detail;

[0051] Step C: System status: Define the status of the program in progress according to the cross-chain data dynamic sharing program process. Constrain the state transition process through the z-regulation. Each operation stage corresponds to the corresponding system state. After the state ends, the system presents the corresponding result.

[0052] Step D: Security attribute specification: Confidentiality verification, integrity verification and authentication verification are performed on the cross-chain data dynamic sharing scheme respectively.

[0053] Preferably, 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-encryption ciphertext mode, and permission token mode.

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

[0055] Compared with the prior art, the present invention provides a cross-chain data dynamic sharing solution and a formal proof method, which has the following beneficial effects:

[0056] This invention defines a certificateless proxy re-encryption (CPRE) algorithm suitable for cross-chain data sharing, which solves the problems of certificate management and key escrow in other proxy re-encryption algorithms, and has high security in data sharing application scenarios; it describes in detail a cross-chain data dynamic sharing scheme based on CPRE, which realizes efficient fine-grained data sharing, while ensuring that the data owner has full control over his data. It also uses the Z language for formal definition and description to ensure the correctness of the scheme. The present invention can realize one-to-many data sharing by data owners offline, and has the characteristics of data demanders dynamically entering and exiting the blockchain. BRIEF DESCRIPTION OF THE DRAWINGS

[0057] Figure 1 This is a schematic diagram of a model of a dynamic cross-queue data sharing solution mentioned in Embodiment 1 of the present invention;

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

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

[0060] Figure 4 This is an example diagram of queue data encryption mentioned in Example 1 of the present invention;

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

[0062] Figure 6 This is an example diagram of ciphertext re-encryption mentioned in Example 1 of the present invention;

[0063] Figure 7 This is an example diagram of the decrypted ciphertext mentioned in Example 1 of the present invention;

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

[0065] Fig. 9 This is a schematic diagram of the verification result of the protocol of Example 1 by Scyther mentioned in Example 2 of the present invention;

[0066] Fig.10 This is a schematic diagram of the calculation time of data encryption mentioned in Example 2 of the present invention;

[0067] Fig.11 This is a schematic diagram of the calculation time of the re-encryption mentioned in Embodiment 2 of the present invention;

[0068] Fig.12 This is a schematic diagram of the calculation time for data decryption mentioned in Example 2 of the present invention;

[0069] Fig.13 This is a schematic diagram of the average calculation time for adding data and making permission decisions mentioned in Example 2 of the present invention. DETAILED DESCRIPTION

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

[0071] This invention defines a certificateless proxy re-encryption (CPRE) algorithm suitable for cross-chain data sharing, which solves the problems of certificate management and key escrow in other proxy re-encryption algorithms, and has high security in data sharing application scenarios; it describes in detail a cross-chain data dynamic sharing scheme based on CPRE, which realizes efficient fine-grained data sharing, while ensuring that the data owner has full control over his data. It also uses the Z language for formal definition and description to ensure the correctness of the scheme. The present invention can realize one-to-many data sharing by data owners offline, and has the characteristics of data demanders dynamically entering and exiting the blockchain. Specifically includes the following contents.

[0072] Embodiment 1:

[0073] See also Figure 1-8 The present invention provides a cross-chain data dynamic sharing scheme and a formal proof method. The cross-chain data dynamic sharing scheme includes the following steps:

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

[0075] S2: System initialization: The ECN in the alliance chain generates system parameters and uses the key generation algorithm to distribute public and private keys to A or B in the chain; A generates an access control policy, and B's node ECN B Verify the identity of B who joins the node and grant B corresponding attributes;

[0076] 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;

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

[0078] S5: Verify cross-chain access request: After receiving the request, A verifies B’s identity and sends the response parameters to A’s ECN node after successful verification. A ;

[0079] S6: Obtaining data ciphertext and generating re-encryption keys: Obtaining ECN A Search the index of relevant data according to B's authority; retrieve the data ciphertext from A's database according to the data index, generate a re-encryption key, and send the ciphertext and re-encryption key to DCN;

[0080] S7: Ciphertext re-encryption: DCN uses the re-encryption key to convert the ciphertext and then sends the converted ciphertext to B;

[0081] S8: Decrypt the ciphertext: B uses his own private key to decrypt and obtain the data.

[0082] Based on the above steps, taking the medical scenario as an example, assume that there are two alliance chains that rely on the relay chain as a trust entity for data transmission, and there are four entities: hospitals, medical research institutions, edge computing nodes, and data conversion nodes. The solution model is as follows: Figure 1 The specific functions of each entity are as follows:

[0083] Hospital (A): The data owner stores medical data in a local database and stores the data index in the blockchain. They can share their data conditionally and gain benefits in the process.

[0084] Medical research institutions (B): data users who need to securely access hospital data.

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

[0086] Data Conversion Node (DCN): A non-fully trusted node in the relay chain that completes the ciphertext conversion as required, but is curious about the content of the converted ciphertext.

[0087] In the process of data sharing, confidentiality, integrity and availability are taken as security goals, 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.

[0088] Integrity: Data is not tampered with, damaged, or modified during transmission and storage, and the original state of the data is maintained.

[0089] Availability: Data availability refers to whether data can be accessed and used by legitimate users or systems in a timely and reliable manner when needed.

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

[0091] (1) Setup (θ→pa, msk): The authority inputs the security parameter θ according to the system initialization setup algorithm and generates the system public parameter pa and the master key msk;

[0092] (2) Part-KeyGen(msk→part A ,pk A ): The authority takes the master key msk as input and outputs the partial private key part of user A A and public key pk A , user B generates a partial private key part in the same way B , public key pk B ;

[0093] (3)KeyGen(part A ,r1→sk A ): The user takes part of the private key sk1 and the random number r1 as input, and outputs the user's private key sk A , user B generates a private key sk in the same way B ;

[0094] (4)Encrypt(pk A ,m→CT1): In the encryption algorithm, the public parameter pa and the public key pk A and message m as input, and output a ciphertext CT1;

[0095] (5)Re-KeyGen(pk B ,sk A →Re A→B ): In the re-encryption key generation algorithm, user A’s private key sk A and user B's public key pk B As input, output re-encryption key Re A→B ;

[0096] (6) Re-Encrypt A→B ,CT1→CT2): In the re-encryption algorithm, the re-encryption key Re A→B and ciphertext CT1 as input, and output the re-encrypted ciphertext CT2;

[0097] (7)Decrypt(CT2,sk B →CT2): In the decryption algorithm, the re-encrypted ciphertext CT2 and user B’s private key sk B As input, output plaintext m.

[0098] Based on the above CPRE algorithm, dynamic sharing of cross-queue data is achieved as follows:

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

[0100] Key generation: Blockchain A randomly selected As the master key, SK A = α, and calculate the public key

[0101] Blockchain B is randomly selected As the master key, SK B =β, and calculate the public key

[0102] Hospital A to its ECN node A Send key application request; ECN A Calculate A's private key sk A =H1(ID A )α, where ID∈{0,1} * ; and calculate the public key Medical research institution B generates the same key as A. i Calculate your own private key Public Key Finally, publish your own public key pk A ,

[0103] Access control policy generation: The access control policy is automatically generated by Hospital A by calling the InitPolicyCreate(·) function: InitPolicyCreate(attrs,data index )→policy init , to ensure the accessibility of each data. Among them, attrs is the identity and context information of the current operator, data index It is the resource identifier returned after the file resource is encrypted and uploaded. init It is a combination of subject strategy and contextual information strategy;

[0104] Only when B satisfies the above policies at the same time can it correctly access A's file resources;

[0105] A can update the access policy of the file resource by calling the UpdataPolicy(·) function: id ,attrs')→policy new , can dynamically update and delete access policies, and implement access authorization and revocation operations. 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;

[0106] Registered user identity: Before medical research institution B accesses hospital A, the access policy and permissions for data usage on blockchain A are instantiated and sent to consortium chain B; when B wants to access data holder A, ECN B It will verify B's identity and determine B's attrs;

[0107] Data encryption: Hospital A randomly selected Encrypt the data m to form a 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 Stored in blockchain;

[0108] Send cross-chain access request: This technology is based on medical research institution B i For example, the process of other medical research institutions joining and obtaining data is similar to that of B i Medical Research Institution B i When preparing to obtain a queue of data, it will send a request message to the data holder A, where the request is based on B i The specific data structure generated by the request sent includes B i attribute information, context information of the current operation and requested file resource information;

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

[0110] 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 the local database of Hospital A; 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;

[0111] 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 ), where CT 21 =CT 11 , CT 23 =Rk2,CT 24 =Rk3; finally, CT2 is returned to the medical research institution B i ;

[0112] Decrypted ciphertext: Medical Research Institution B i Receive the ciphertext CT2; when given B i Key B i Get the queue data through the following decryption steps:

[0113]

[0114] Proof of correctness of the solution: Calculation Will CT 24 =Rk3=g λ ,get Next, calculate Will CT 21 =CT 11 =m·g t Substituting in, we get:

[0115] The above steps describe the specific details of the cross-queue data dynamic sharing scheme based on the CPRE algorithm. In terms of security, in order to ensure the integrity and confidentiality of the data in the scheme, the above scheme is formally defined using a standardized formal description language, namely, the z language. Through the specification of the z language, the confidentiality and integrity of the data in the scheme can be guaranteed and the authentication of the scheme and data authorization can be verified, as follows:

[0116] Solution Definition:

[0117] 1. Mode definition: define the interactive data and roles in the scheme using the basic unit mode of the z language and define the type of data designed in each mode:

[0118] (1) Blockchain mode: schema Blockchain::=

【SK BC :Int,PK BC :Int], the blockchain contains two pieces of information: the master key of the blockchain and the public key of the blockchain;

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

[0120] (3) Medical research institution model: The medical research institution in the scheme includes the institution’s ID number, partial and complete private keys, and public keys;

[0121] (4) Edge conversion node mode: schema ECN::=[ID:String]

[0122] (5) Data conversion node mode: schema DCN::=

ID:String

[0123] (6) Encrypted data mode: schema EncryptedData::[CT 11 :Int,CT 12 :Int], the queue data that needs to be encrypted in the system is encrypted as CT1=(CT 11 ,CT 12 );

[0124] (7) Re-encryption key mode: The re-encryption key is Re1 is composed of;

[0125] (8) Re-encryption ciphertext mode: Re-encrypt the ciphertext using the re-encryption key;

[0126] (9) Permission token mode: schema PermissionToken: == [token: Bool]

[0127] 2. Definition of program operation

[0128] (1) Key generation: refer to Figure 2 ,In the key generation phase, define operations such as generateMainKey, requestPartialPrivatekey, calculateCompletePrivateKey, etc. to generate the keys required by each participant in the system;

[0129] (2) Authorization: Refer to Figure 3 ,There are two operations defined in the permission granting phase: ,the research institution generates permission requests and verifies ,the generated requests and sends the corresponding permission tokens;

[0130] (3) Queue data encryption: refer to Figure 4 ,In this stage, three operations are defined. First, the data in the queue is encrypted to generate ,ciphertext data. Then, the ciphertext data is stored in the database and the ,corresponding index is stored in the blockchain.

[0131] (4) Re-key generation: refer to Figure 5 According to the scheme steps, four operations are defined. First, the hospital randomly selects numbers to calculate and generate a re-key. Secondly, when DCN receives an access request, it must first perform token authentication to check whether it has access rights. If the authentication is successful, it will match the file support index. Finally, the re-encryption key is formed based on the identity information.

[0132] (5) Ciphertext re-encryption: refer to Figure 6 After obtaining the re-encryption key, first define the operation of retrieving the ciphertext, and retrieve the corresponding ciphertext locally in the hospital according to the index; secondly, use the generated re-encryption key to re-encrypt the ciphertext to obtain the re-encrypted ciphertext data; finally, return the obtained ciphertext data to the research institution.

[0133] (6) Decrypted ciphertext: refer to Figure 7 ,Finally, the operation is defined in the decryption ciphertext phase, and the ,research institute decrypts the data after receiving the re-encrypted ciphertext.

[0134] z Regulations:

[0135] For each of the above operation definitions, the z language uses z conventions to describe the process of each operation in detail, and fully reflects the solution process through preconditions and subsequent operations. For details, please refer to the following process:

[0136]

[0137]

[0138]

[0139] System Status:

[0140] 1. Status definition:

[0141] According to the program process, several states of the program are defined, as follows:

[0142] SystemInit: The system is initializing and ready to start.

[0143] KeyGeneration: The system is generating keys.

[0144] HospitalKeyGeneration: The hospital is generating keys.

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

[0146] PermissionGranting: The system is granting permissions.

[0147] QueueDataEncryption: The system is encrypting queue data.

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

[0149] DataRetrieval: The system is retrieving data.

[0150] DataDecryption: The system is decrypting data.

[0151] 2. State Transition

[0152] Reference Figure 8 At the same time, the state transition of the system also needs to be constrained by the z specification. Each operation stage corresponds to the corresponding system state, and the system presents the corresponding result after the state ends. Please refer to the following example:

[0153]

[0154]

[0155] 4 Security attribute specifications:

[0156] 1. Confidentiality verification: Please refer to the following example:

[0157]

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

[0159] 2. Integrity verification: Please refer to the following example:

[0160]

[0161]

[0162] The protocol in 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 process.

[0163] 3. Authentication verification: Please refer to the following example:

[0164]

[0165] The above example ensures that the parties in the system are properly authenticated, meaning that all hospitals and medical research institutions are able to successfully generate their own key pairs.

[0166] Embodiment 2:

[0167] Taking the medical scenario as an example, suppose there are two consortium chains that rely on the relay chain as a trust entity for data transmission, and there are four entities: hospitals, medical research institutions, edge computing nodes, and data conversion nodes. The solution model is as follows: Figure 1 The protocol of Example 1 was verified based on scyther, and the verification results can be found in Fig. 9 As can be seen from the figure, the protocols of Example 1 have all passed the verification. The calculation time of the data encryption phase of Example 1 is also counted. The specific results can be referred to Fig.10 , Fig.10The calculation time during the data encryption phase is shown. 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 the calculation time of the three schemes increases steadily with the increase in the number of users. This is because each encryption operation is performed on a single user. When the number of users increases exponentially, the encryption calculation time also increases exponentially. The reason why the calculation time of line segment 2 is generally longer is that both encryption and decryption time are related to the complexity of the access policy.

[0168] The calculation time of the data re-encryption phase of Example 1 is also counted. The specific results can be found in Fig.11 , Fig.11 The calculation time during the re-encryption phase is shown. As with the encryption phase, the calculation time of the re-encryption phase increases exponentially when the number of users increases exponentially.

[0169] Reference Fig.12 The calculation time of data decryption is statistically analyzed. It can be seen from the figure that, like the encryption stage, when the number of users increases exponentially, the calculation time of data decryption also increases exponentially.

[0170] Two organizations were established in Hyperledger Fabric to simulate dynamic data sharing in a cross-queue environment. In each experiment, the two organizations represented the hospital and the medical research institution respectively to simulate the dynamic data sharing process. The two organizations joined the same channel together and used the raft consensus. The calculation time for adding data and making permission decisions were tested respectively. The experimental data was obtained by repeating the experiment 10 times and taking the average value. Among them, adding data includes the common time of data uploading and automatically generating access policies according to the template, while the permission decision is the time from the user sending the request to the completion of the permission decision by the solution in Example 1. The experiment carried out 100-1.00E+11 data uploads and data requests, and increased by 10 times each time, and measured the data upload consumption time and permission decision time of the solution in Example 1 at this level. For specific measurement results, please refer to Fig.13 As can be seen from the figure, with the increase of data upload and data request times, the average data upload consumption time and authority decision time of the scheme in Example 1 change more steadily, and the time consumption is shorter, which proves that the scheme in Example 1 has higher stability and efficiency.

[0171] The above description is only a preferred specific implementation manner of the present invention, but the protection scope of the present invention is not limited thereto. Any technician familiar with the technical field can make equivalent replacements or changes according to the technical scheme and inventive concept of the present invention within the technical scope disclosed by the present invention, which should be covered by the protection scope of the present invention.

Claims

1. A cross-chain data dynamic sharing solution, characterized in that: The steps include: S1: Define data transmission entities: define data owner A, data user B, edge computing node ECN and data conversion node DCN respectively; S2: System initialization: The ECN in the alliance chain generates system parameters and uses the key generation algorithm to distribute public and private keys to A or B in the chain; A generates an access control policy, and B's node ECN B Verify the identity of B who joins the node and grant 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 cross-chain access request: After receiving the request, A verifies B’s identity and sends the response parameters to A’s ECN node after successful verification. A ; S6: Obtaining data ciphertext and generating re-encryption keys: Obtaining ECN A Search the index of relevant data according to B's authority; retrieve the data ciphertext from A's database according to the data index, generate a re-encryption key, and send the ciphertext and re-encryption key to 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 his own private key to decrypt and obtain the data.

2. A cross-chain data dynamic sharing solution according to claim 1, characterized in that: The encryption algorithm in S3 is based on the CPRE algorithm, and the CPRE algorithm is specifically as follows: S3.1: The authority sets the algorithm based on the system initialization, inputs the security parameter θ, and generates the system public parameter pa and the master key msk; S3.2: The authority takes the master key msk as input and outputs the partial private key part of the data owner A A and public key pk A , data user B also generates a partial private key part B and public key pk B ; S3.3: A takes the partial private key sk1 and the random number r1 as input and outputs the user's private key sk A , B also generates a private key sk B ; S3.4: In the encryption algorithm, the public parameters pa and public key pk are used. A and message m as input, and output a ciphertext CT1; S3.5: In the re-encryption key generation algorithm, A's private key sk A and B's public key pk B As input, output re-encryption key Re A→B ; S3.6: The re-encryption key Re is used in the re-encryption algorithm A→B and ciphertext CT1 as input, and output the re-encrypted ciphertext CT2; S3.7: In the decryption algorithm, the re-encrypted ciphertext CT2 and B's private key sk B As input, output plaintext m.

3. A cross-chain data dynamic sharing solution according to claim 2, characterized in that: In the cross-chain data dynamic sharing solution, dynamic sharing of cross-queue data is achieved based on the CPRE algorithm, as follows: System initialization: Given two multiplication cyclic groups G1 and G2 of order p, g is the generator of the cyclic group G1, randomly select g1, g2∈G1, construct a bilinear map e:G1×G1→G2; select two collision-resistant hash functions H1:G1←{0,1} * ;H1:G1←G2; Public system parameters pa={G1,G2,g,e,p,H1,H2}; Key generation: Randomly select the blockchain where data holder A is located As the master key, SK A = α, and calculate the public key The blockchain where data user B is located is randomly selected As the master key, SK B =β, and calculate the public key A to the node ECN A Send key application request; ECN A Calculate A's private key sk A =H1(ID A )α, where ID∈{0,1} * ; and calculate the public key The same as A generates the key, any data user B i Calculate your own private key Public Key Finally, publish your own public key pk A , Access control policy generation: The access control policy is automatically generated by A calling the InitPolicyCreate(·) function: InitPolicyCreate(attrs,data index )→policy init Among them, attrs is the identity and context information of the current operator, data index It is the resource identifier returned after the file resource is encrypted and uploaded. init It is a combination of subject strategy and contextual information strategy; When B satisfies the above policies at the same time, it has the authority to correctly access A's file resources; A also calls the UpdataPolicy(·) function to update the access policy of the file resource: UpdataPolicy(policy id ,attrs')→policy new Among them, 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; Registered user identity: Before B accesses A, the access policy and permissions used by the data in A’s blockchain are instantiated and sent to B’s consortium chain; when B prepares A, ECN B Verify B's identity and determine B's attrs; Data encryption: A random selection Encrypt the data m to form a 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 Stored in blockchain; Send cross-chain access request: B i When preparing to obtain data from a queue, a request message is sent to A to obtain data. The request is based on B i The specific data structure generated by the request sent includes B i attribute information, context information of the current operation and requested file resource information; 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; 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; 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 ), where CT 21 =CT 11 , CT 23 =Rk2,CT 24 =Rk3; finally return CT2 to B i ; Decrypted ciphertext: B i Receive the ciphertext CT2; when given B i Key B i Get the queue data through the following decryption steps: Proof of correctness of the solution: Calculation Will CT 24 =Rk3=g λ ,get Next, calculate Will CT 21 =CT 11 =m·g t Substituting in, we get:

4. A formal proof method for a cross-chain data dynamic sharing scheme as claimed in any one of claims 1 to 3, characterized in that: The steps include: Step A: Mode definition: define the data interacting in the scheme and the roles performing data interaction using a standardized form of description language, i.e., the basic unit mode of the z language, and define the type of data designed in each mode: also define each operation in the cross-chain data dynamic sharing scheme; Step B: z-regulation: For each of the above operation definitions, z-language uses z-regulation to describe the process of each operation in detail; Step C: System status: Define the status of the program in progress according to the cross-chain data dynamic sharing program process. Constrain the state transition process through the z-regulation. Each operation stage corresponds to the corresponding system state. After the state ends, the system presents the corresponding result. Step D: Security attribute specification: Confidentiality verification, integrity verification and authentication verification are performed on the cross-chain data dynamic sharing scheme respectively.

5. According to claim 4, a formal proof method for a cross-chain data dynamic sharing scheme is 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-encryption ciphertext mode, and permission token mode.

6. A 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, queue data encryption, re-key generation, ciphertext re-encryption, and ciphertext decryption.

Images