A method for cross-chain data sharing between different cryptographic systems

Abstract

The present invention discloses a method for realizing cross-chain data sharing between different cryptographic systems, and relates to the field of blockchain cross-chain technology. Compared with the previous PHR cross-chain sharing scheme, the present invention solves the problem that the existing method for ensuring the security of the PHR cross-chain sharing scheme is not suitable for medical Internet of Things devices with low storage and computing overhead, and does not consider the problem of internal attacks that are prone to occur when sharing data; the proxy re-encryption algorithm is improved, and the PHR ciphertext can be converted and decrypted between the IBE and CLC cryptographic systems, and a cross-chain sharing scheme for PHR is constructed based on this. The problem of limited storage and computing resources of medical Internet of Things terminal devices is solved, and medical data is shared between the IBE and CLC cryptographic systems. At the same time, the security of the scheme is improved by verifying the correctness, security and performance testing methods.

Description

Technical Field

[0001] The present invention relates to the field of cross-chain blockchain technology, and in particular to a method for realizing cross-chain data sharing between different cryptographic systems. Background Art

[0002] With the popularization of medical information technology, many personal health records of great value have been generated. At the same time, the emergence of blockchain has enhanced the security of medical institutions, but currently medical institutions are data islands and fail to bring into play the value of personal health records. As the demand for data sharing among medical institutions in different blockchains continues to increase, it is urgent to solve the problem of cross-chain data sharing. When sharing PHR across chains, it is difficult to store a large amount of medical data and process complex calculations due to the limited storage and computing performance of medical IoT devices. In addition, different blockchain cryptographic systems and the risk of internal attacks make cross-chain sharing of PHR complicated. Moreover, many solutions study the problem of data sharing within the same blockchain, without considering the situation where different medical institutions are in different blockchains.

[0003] In the process of using the existing PHR cross-chain sharing scheme, the cryptographic mechanisms between different blockchains are often different, which will cause the data encrypted by the data owner to be unable to be decrypted by the data user. In addition, due to the limited storage performance of medical IoT devices, PHR is often encrypted and stored in IPFS, and complex operations are required when PHR needs to be shared; secondly, due to its limited computing performance, it is difficult to perform complex calculations. In the process of realizing data sharing, it is not only faced with external attacks, but also faced with internal attackers who may leak secret information from the algorithm through penetration attacks. There are three mainstream encryption algorithms that can ensure the security of PHR sharing. Attribute encryption (ABE) technology can realize one-to-many data sharing and improve the efficiency of the scheme. However, it requires attribute allocation based on attribute centers and is not suitable for cross-chain data sharing scenarios. Searchable encryption (SE) technology can obtain ciphertexts in IPFS safely and efficiently according to the index of ciphertexts, but it can only encrypt data indexes, not data. At present, the proxy re-encryption (PRE) algorithm is widely used in existing data sharing schemes. Its advantage is that a semi-trusted agent can convert the ciphertext generated by the data owner into ciphertext that the data user can decrypt using his own private key. This method simplifies the data sharing process by eliminating the need for complex steps such as data downloading, decryption, and re-encryption. However, the cryptographic systems of different medical institutions may be very different today, and the encryption algorithms of the above schemes are all based on the assumption of the same cryptographic mechanism, which is not suitable for real medical scenarios. Secondly, the above schemes are not suitable for medical IoT devices with low storage and computing overhead, and do not consider the problem of internal attacks that are prone to occur when sharing data.

[0004] In order to solve the above problems, the present invention proposes a method for realizing cross-chain data sharing between different cryptographic systems. Summary of the invention

[0005] The purpose of the present invention is to propose a method for realizing cross-chain data sharing between different cryptographic systems to solve the problems raised in the background technology:

[0006] Existing methods to ensure the security of PHR cross-chain sharing solutions are not suitable for medical IoT devices with low storage and computing overhead, and do not consider the problem of internal attacks that are prone to occur when data is shared.

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

[0008] A method for realizing cross-chain data sharing between different cryptographic systems comprises the following steps:

[0009] S1:Hosptial A and Hospital B Authenticate and register with the relay chain through the cross-chain gateway;

[0010] S2: When the data owner DO collects relevant medical data, he uses his own private key to encrypt the data and stores it in IPFS;

[0011] S3: When the data user DU needs to access the medical data of DO, it sends a cross-chain access request to DO;

[0012] S4: After receiving the request message, DO verifies it. After verification, DO calculates the re-encryption key and sends the ciphertext identifier and the re-encryption key to Hostial. A ;

[0013] S5: Hospital A According to the ciphertext identifier in IPFS A The data ciphertext is obtained from the ciphertext, and the data ciphertext and the re-encryption key are sent to the relay chain;

[0014] S6: The relay chain re-encrypts the ciphertext using the re-encryption key to generate a re-encrypted ciphertext that can be decrypted by the DU, and sends it to the DU through the cross-domain gateway;

[0015] S7: DU uses its own private key to decrypt the re-encrypted ciphertext to obtain relevant medical data.

[0016] Preferably, in S1, the alliance chain A where the data owner DO is located is selected, and a Hostial A , using IBE as the cryptographic system, the data user DU is located in the alliance chain B, and a Hospital is set up in the alliance chain BB , using CLC as the cryptographic system, alliance chain A and alliance chain B use relay links to connect with the cross-chain gateway.

[0017] Preferably, in S1, an encryption system is established, and the alliance chain A and the alliance chain B are registered respectively to generate system parameters, as follows:

[0018] Given a security parameter k, KGC selects two multiplicative groups G1 and G2 with prime number q as order, a linear pair e→G1×G1, and two hash functions H1={0,1} * →G1 and H2:G2→G1;

[0019] Hospital in Alliance Chain A A Random Selection As the master key, calculate the system public key h1 = g s , where g is the generator of G1; A Send the parameter par = {G1, G2, e, g, h1', H1, H2} to its encrypted reverse firewall CRF A ;

[0020] CRF A Random Selection As the master key, calculate Set the parameter par1'={G1,G2,e,g,h1',H1,H2} as the system parameter and make it public;

[0021] Hospital in Alliance Chain B B Random Selection As the master key, calculate the system public key h2 = g y ,Hosptial B Random Selection As the master key, calculate Set the parameter par2'={G1,G2,e,g,h'2,H1,H2} as the system parameter and make it public;

[0022] After the system is generated, consortium chain A and consortium chain B generate keys for users in their respective chains. The specific process is as follows:

[0023] User key generation in consortium chain A:

[0024] The identity ID of the given DO DO ∈{0,1} * ,Hosptial A Generate user public key pk DO =H1(ID DO ) and private key And sk DOSend to CRF A ;

[0025] CRF A Received sk DO Then, use the master key a to generate a randomized user's private key And sk' DO Occurs to DO;

[0026] User key generation in alliance chain B:

[0027] The identity ID of a given DU DU ∈{0,1} * , KGC generates user private key D DU =H1(ID DU ) y ,Hosptial B D DU Send to CRF B ;

[0028] CRF B Received D DU Then, use the master key b to generate a randomized user private key And D' DU Occurrence to DU;

[0029] DU random selection Calculate the private key sk DU =(D' DU ) r =H1(ID DU ) ybr , public key pk DU =(H1(ID DU ),(h'2) r ), where the public key is pk DU1 =H1(ID DU ), public key 2 pk DU2 =(h'2) r .

[0030] Preferably, in S2, the data owner DO encrypts the collected relevant medical data and uploads it to IPFS A Storage, as follows:

[0031] DO selects a shared message M, given par1', pk DO , randomly selected Finally, the ciphertext C is generated DO , and C DO Send to CRF A ;

[0032] C DO=(c1,c2)

[0033] c1=g α

[0034] c2=M·e(h1',pk DO )α

[0035] Among them, c1, c2 are ciphertext sequences;

[0036] CRF A Receive C DO Then, randomly select Generate randomized ciphertext C' DO , and C' DO and its identifier Data1 are sent to IPFS A Storage, while Hospital A In the access list Lis1, the ciphertext identifier Data1 and the machine address Add1 are saved;

[0037] C' DO =(c1',c'2,c'3)

[0038] c1'=c1·g β =g α+β

[0039] c'2=c2·e(h1',pk DO ) β =M·e(g sa ,pk DO )α +β

[0040]

[0041] Among them, c1', c'2, c'3 are randomized ciphertext sequences;

[0042] Data sharing: In this stage, DU initiates a cross-chain access request to DO, and DO shares data with DU after successfully verifying the request message.

[0043] Preferably, in S3, when DU needs to obtain the shared file of DO, it first sends a cross-chain access request message to DO. Among them, request1 is the DU cross-chain access identifier, T1 is the timestamp, and N1 is the parameter for maintaining session freshness; message M1 is forwarded to DO through the cross-domain gateway.

[0044] Preferably, in S4, after receiving the request, DO verifies the validity of the message and the correctness of the DU identity; if the verification is successful, DO randomly selects λ and X, and uses its own private key sk' DO and DU's public key pkDU , generate the re-encryption key rk DO , and rk DO Send to CRF A ;

[0045] rk DO =(rk1,rk2,rk3)

[0046]

[0047] rk2=g λ

[0048] rk3=X·e(pk DU1 ,pk DU2 ) λ

[0049] Among them, rk1, rk2, rk3 are the re-encryption key sequences;

[0050] CRF A Received DO After that, generate a randomized re-encryption key rk' DO :

[0051] rk' DO =(rk1',rk'2,rk3')

[0052]

[0053] rk'2=rk2·g λ =g λ+β

[0054] rk3'=rk3·e(pk DU1 ,pk DU2 ) β =X·e(pk DU1 ,pk DU2 ) λ+β

[0055] Among them, rk1', rk'2, rk3' are randomized re-encryption key sequences;

[0056] Then DO sends the ciphertext identifier Data1 and the cross-domain data sharing permission message M2 = {request2, pk DO ,pk DU ,rk' DO ,T2,N2} sent to Hostial A , request2 is the DO cross-chain access identifier.

[0057] Preferably, in S5, Hospital ASchedule smart contract algorithm Algorithm1, and finally send message M2 and ciphertext C' DO Send to the relay chain.

[0058] Preferably, in S6, after receiving the permission information, the relay link authenticates the validity of the request through the coordination node; if the request is authenticated, the relay link authenticates the validity of the request according to the given C' DO and rk' DO Generate re-encrypted ciphertext C DU Finally, the relay chain sends the response message M3={respond1,C DU ,T3,N3} is sent to DU, respond1 is the response identifier;

[0059] C DU =(C1,C2,C3,C4)

[0060] C1=c1'

[0061] C2=c'2·e(C1,rk1',c'3)

[0062] C3=rk'2

[0063] C4=rk3'

[0064] Among them, C1, C2, C3, and C4 are re-encrypted ciphertext sequences.

[0065] Preferably, in S7, after receiving the response message M3, DU first verifies the validity of the message, and after successful verification, uses its own private key sk DU calculate Recalculate Get the message M.

[0066] Compared with the prior art, the present invention provides a method for realizing cross-chain data sharing between different cryptographic systems, which has the following beneficial effects:

[0067] This invention improves the proxy re-encryption algorithm, realizes that PHR ciphertext can be converted and decrypted between IBE and CLC cryptographic systems, and builds a cross-chain sharing solution for PHR based on this. It solves the problem of limited storage and computing resources of medical Internet of Things terminal devices, realizes the sharing of medical data between IBE and CLC cryptographic systems, and improves the security of the solution by verifying correctness, security and performance testing methods. BRIEF DESCRIPTION OF THE DRAWINGS

[0068] Figure 1 This is a schematic diagram of the cross-chain data sharing solution model mentioned in Example 1 of the present invention;

[0069] Figure 2This is a schematic diagram of the cross-chain data sharing solution process mentioned in Example 1 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] The present invention improves the proxy re-encryption algorithm, realizes that PHR ciphertext can be converted and decrypted between IBE and CLC cryptographic systems, and builds a cross-chain sharing solution for PHR based on this. It solves the problem of limited storage and computing resources of medical Internet of Things terminal devices, realizes the sharing of medical data between IBE and CLC cryptographic systems, and improves the security of the solution by verifying correctness, security and performance testing methods. Specifically includes the following content.

[0072] Embodiment 1:

[0073] See also Figure 1-2 The present invention provides a method for realizing cross-chain data sharing between different cryptographic systems, comprising the following steps:

[0074] S1:Hosptial A and Hospital B Authentication and registration with the relay chain is performed through the cross-chain gateway; the details are as follows:

[0075] Assume there is a Hospital in consortium chain A A , using IBE as the cryptographic system. There is a Hospital in the alliance chain B B , using CLC as the cryptographic system. Alliance chains A and B use relay chains to connect with the cross-chain gateway. This embodiment assumes that a data user in hospital B needs to use a certain medical data of the data owner in hospital A. The entities are mainly as follows:

[0076] 1. Hospital i ): A node on the blockchain that generates keys for users within the chain. It is the trusted entity with the highest level of authority within the node and manages transactions within the node.

[0077] 2. Data Owner (DO): DO is the hostial A A user in the network owns the data and can be any IoT terminal device with limited computing and storage resources.

[0078] 3. Data User (DU): Hospital BA user in the medical data system can be a patient, doctor, researcher or other person who needs to use medical data.

[0079] 4. Relay chain: nodes with different functions. Computing nodes provide computing power and are responsible for the calculation of re-encrypted ciphertext. Supervisory nodes and coordination nodes use blockchain smart contracts to authenticate and register blockchains connected to the relay chain, and confirm and audit transactions within the chain.

[0080] 5. Interplanetary File System (IPFS): is a semi-trusted distributed database responsible for storing data to reduce the storage resources of IoT terminal devices.

[0081] 6. Firewall (DRF i ): Deployed between the user's terminal device and the blockchain node. It can modify the messages sent by the user to the external network. If there is an attacker who intercepts the message from the backdoor, CRF can confuse the attacker and make it impossible for him to know the user's exact message.

[0082] First, establish an encryption system, register the alliance chain A and alliance chain B respectively, and generate system parameters, as follows:

[0083] Given a security parameter k, KGC selects two multiplicative groups G1 and G2 with prime number q as order, a linear pair e→G1×G1, and two hash functions H1={0,1} * →G1 and H2:G2→G1;

[0084] Hospital in Alliance Chain A A Random Selection As the master key, calculate the system public key h1 = g s , where g is the generator of G1; A Send the parameter par = {G1, G2, e, g, h1', H1, H2} to its encrypted reverse firewall CRF A ;

[0085] CRF A Random Selection As the master key, calculate h1'=h1 a =g sa , set the parameter par1'={G1,G2,e,g,h1',H1,H2} as the system parameter and make it public;

[0086] Hospital in Alliance Chain B B Random Selection As the master key, calculate the system public key h2 = g y ,Hosptial B Random Selection As the master key, calculate h'2 = h2 b =g yb , set the parameter par2'={G1,G2,e,g,h'2,H1,H2} as the system parameter and make it public;

[0087] After the system is generated, consortium chain A and consortium chain B generate keys for users in their respective chains. The specific process is as follows:

[0088] User key generation in consortium chain A:

[0089] The identity ID of the given DO DO ∈{0,1} * ,Hosptial A Generate user public key pk DO =H1(ID DO ) and private key And sk DO Send to CRF A ;

[0090] CRF A Received sk DO Then, use the master key a to generate a randomized user's private key And sk' DO Occurs to DO;

[0091] User key generation in alliance chain B:

[0092] The identity ID of a given DU DU ∈{0,1} * , KGC generates user private key D DU =H1(ID DU ) y ,Hosptial B D DU Send to CRF B ;

[0093] CRF B Received D DU Then, use the master key b to generate a randomized user private key And D' DU Occurrence to DU;

[0094] DU random selection Calculate the private key sk DU =(D' DU ) r =H1(ID DU ) ybr , public key pk DU =(H1(ID DU ),(h'2) r), where the public key is pk DU1 =H1(ID DU ), public key 2 pk DU2 =(h'2) r .

[0095] S2: When the data owner DO collects relevant medical data, he uses his own private key to encrypt the data and stores it in IPFS; the details are as follows:

[0096] DO selects a shared message M, given par1', pk DO , randomly selected Finally, the ciphertext C is generated DO , and C DO Send to CRF A ;

[0097] C DO =(c1,c2)

[0098] c1=g α

[0099] c2=M·e(h1',pk DO )α

[0100] Among them, c1, c2 are ciphertext sequences;

[0101] CRF A Receive C DO Then, randomly select Generate randomized ciphertext C' DO , and C' DO and its identifier Data1 are sent to IPFS A Storage, while Hospital A In the access list Lis1, the ciphertext identifier Data1 and the machine address Add1 are saved;

[0102] C' DO =(c1',c'2,c'3)

[0103] c1'=c1·g β =g α+β

[0104] c'2=c2·e(h1',pk DO ) β =M·e(g sa ,pk DO )α +β

[0105]

[0106] Among them, c1', c'2, c'3 are randomized ciphertext sequences;

[0107] Data sharing: In this stage, DU initiates a cross-chain access request to DO, and DO shares data with DU after successfully verifying the request message.

[0108] S3: When the data user DU needs to access the medical data of DO, it sends a cross-chain access request to DO; the details are as follows:

[0109] When DU needs to obtain DO's shared files, it first sends a cross-chain access request message to DO. Among them, request1 is the DU cross-chain access identifier, T1 is the timestamp, and N1 is the parameter for maintaining session freshness; message M1 is forwarded to DO through the cross-domain gateway.

[0110] S4: After receiving the request message, DO verifies it. After verification, DO calculates the re-encryption key and sends the ciphertext identifier and the re-encryption key to Hostial. A ; The details are as follows:

[0111] When DO receives the request, it verifies the validity of the message and the correctness of the DU identity. If the verification is successful, DO randomly selects λ and X and uses its own private key sk' DO and DU's public key pk DU , generate the re-encryption key rk DO , and rk DO Send to CRF A ;

[0112] rk DO =(rk1,rk2,rk3)

[0113]

[0114] rk2=g λ

[0115] rk3=X·e(pk DU1 ,pk DU2 ) λ

[0116] Among them, rk1, rk2, rk3 are the re-encryption key sequences;

[0117] CRF A Received DO After that, generate a randomized re-encryption key rk' DO :

[0118] rk' DO =(rk1',rk'2,rk3')

[0119]

[0120] rk'2=rk2·g λ =g λ+β

[0121] rk3'=rk3·e(pk DU1 ,pk DU2 ) β =X·e(pk DU1 ,pk DU2 ) λ +β

[0122] Among them, rk1', rk'2, rk3' are randomized re-encryption key sequences;

[0123] Then DO sends the ciphertext identifier Data1 and the cross-domain data sharing permission message M2 = {request2, pk DO ,pk DU ,rk' DO ,T2,N2} sent to Hostial A , request2 is the DO cross-chain access identifier.

[0124] S5: Hospital A According to the ciphertext identifier in IPFS A The data ciphertext is obtained from the ciphertext, and the data ciphertext and the re-encryption key are sent to the relay chain; the details are as follows:

[0125] Hospital A Schedule smart contract algorithm Algorithm1, and finally send message M2 and ciphertext C' DO Send to the relay chain.

[0126] S6: The relay chain re-encrypts the ciphertext using the re-encryption key to generate a re-encrypted ciphertext that the DU can decrypt, and sends it to the DU through the cross-domain gateway; the details are as follows:

[0127] After receiving the permission information, the relay link verifies the validity of the request through the coordination node. If the request is authenticated, the relay chain will DO and rk' DO Generate re-encrypted ciphertext C DU Finally, the relay chain sends the response message M3={respond1,C DU ,T3,N3} is sent to DU, respond1 is the response identifier;

[0128] C DU =(C1,C2,C3,C4)

[0129] C1=c1'

[0130] C2=c'2·e(C1,rk1',c'3)

[0131] C3=rk'2

[0132] C4=rk3'

[0133] Among them, C1, C2, C3, and C4 are re-encrypted ciphertext sequences.

[0134] S7: DU uses its own private key to decrypt the re-encrypted ciphertext to obtain relevant medical data.

[0135] The details are as follows:

[0136] After receiving the response message M3, DU first verifies the validity of the message. After successful verification, it uses its own private key sk DU calculate Recalculate Get the message M.

[0137] In this embodiment, the PHR generated in real time is encrypted and stored in IPFS. When data sharing is required, IoT terminal devices with limited storage and computing performance can share PHR simply by mobilizing smart contracts. At the same time, the encryption reverse firewall (CRF) and blockchain audit mechanism are added to ensure that the solution is not attacked internally and prevent information leakage. In order to determine whether cross-chain sharing of PHR can be achieved, first, the correctness of the improved proxy re-encryption algorithm is verified by verifying whether the data user can correctly decrypt the re-encrypted ciphertext. Secondly, ban logic and CPA security analysis are used to prove whether the solution meets the confidentiality and integrity of the data and is not attacked internally or externally. Finally, theoretical analysis is used to calculate the computational overhead and communication overhead of this embodiment and other related solutions, and the solution is deployed on a cross-chain system to test the system throughput and latency.

[0138] 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 method for realizing cross-chain data sharing between different cryptographic systems, characterized in that: The steps include: S1:Hosptial A and Hospital B Authenticate and register with the relay chain through the cross-chain gateway; S2: When the data owner DO collects relevant medical data, he uses his own private key to encrypt the data and stores it in IPFS; S3: When the data user DU needs to access the medical data of DO, it sends a cross-chain access request to DO; S4: After receiving the request message, DO verifies it. After verification, DO calculates the re-encryption key and sends the ciphertext identifier and the re-encryption key to Hostial. A ; S5: Hospital A According to the ciphertext identifier in IPFS A The data ciphertext is obtained from the ciphertext, and the data ciphertext and the re-encryption key are sent to the relay chain; S6: The relay chain re-encrypts the ciphertext using the re-encryption key to generate a re-encrypted ciphertext that can be decrypted by the DU, and sends it to the DU through the cross-domain gateway; S7: DU uses its own private key to decrypt the re-encrypted ciphertext to obtain relevant medical data.

2. A method for realizing cross-chain data sharing between different cryptographic systems according to claim 1, characterized in that: In S1, the alliance chain A where the data owner DO is located is selected, and a Hostial is set up in the alliance chain A. A , using IBE as the cryptographic system, the data user DU is located in the alliance chain B, and a Hospital is set up in the alliance chain B B , using CLC as the cryptographic system, alliance chain A and alliance chain B use relay links to connect with the cross-chain gateway.

3. A method for realizing cross-chain data sharing between different cryptographic systems according to claim 2, characterized in that: In S1, an encryption system is established, and the alliance chain A and alliance chain B are registered and system parameters are generated, as follows: Given a security parameter k, KGC selects two multiplicative groups G1 and G2 with prime number q as order, a linear pair e→G1×G1, and two hash functions H1={0,1} * →G1 and H2:G2→G1; Hospital in Alliance Chain A A Random Selection As the master key, calculate the system public key h1 = g s , where g is the generator of G1; A Send the parameter par = {G1, G2, e, g, h1', H1, H2} to its encrypted reverse firewall CRF A ; CRF A Random Selection As the master key, calculate h1'=h1 a =g sa , set the parameter par1'={G1,G2,e,g,h1',H1,H2} as the system parameter and make it public; Hospital in Alliance Chain B B Random Selection As the master key, calculate the system public key h2 = g y ,Hosptial B Random Selection As the master key, calculate Set the parameter par2'={G1,G2,e,g,h'2,H1,H2} as the system parameter and make it public; After the system is generated, consortium chain A and consortium chain B generate keys for users in their respective chains. The specific process is as follows: User key generation in alliance chain A: The identity ID of the given DO DO ∈{0,1} * ,Hosptial A Generate user public key pk DO =H1(ID DO ) and private key And sk DO Send to CRF A ; CRF A Received sk DO Then, use the master key a to generate a randomized user's private key And sk' DO Occurs to DO; User key generation in alliance chain B: The identity ID of a given DU DU ∈{0,1} * , KGC generates user private key D DU =H1(ID DU ) y ,Hosptial B D DU Send to CRF B ; CRF B Receive D DU Then, use the master key b to generate a randomized user private key And D' DU Occurrence to DU; DU random selection Calculate the private key sk DU =(D' DU ) r =H1(ID DU ) ybr , public key pk DU =(H1(ID DU ),(h'2) r ), where the public key is pk DU1 =H1(ID DU ), public key 2 pk DU2 =(h'2) r .

4. A method for realizing cross-chain data sharing between different cryptographic systems according to claim 3, characterized in that: In S2, the data owner DO encrypts the collected relevant medical data and uploads it to IPFS A Storage, as follows: DO selects a shared message M, given par1', pk DO , randomly selected Finally, the ciphertext C is generated DO , and C DO Send to CRF A ; C DO =(c1,c2) c1=g α c2=M·e(h1',pk DO )α Among them, c1, c2 are ciphertext sequences; CRF A Receive C DO Then, randomly select Generate randomized ciphertext C' DO , and C' DO and its identifier Data1 are sent to IPFS A Storage, while Hospital A In the access list Lis1, the ciphertext identifier Data1 and the machine address Add1 are saved; C' DO =(c1',c'2,c'3) c1'=c1·g β =g α+β c'2=c2·e(h1',pk DO ) β =M·e(g sa ,pk DO )α +β Among them, c1', c'2, c'3 are randomized ciphertext sequences; Data sharing: In this stage, DU initiates a cross-chain access request to DO, and DO shares data with DU after successfully verifying the request message.

5. A method for realizing cross-chain data sharing between different cryptographic systems according to claim 4, characterized in that: In S3, when DU needs to obtain DO's shared files, it first sends a cross-chain access request message to DO. Among them, request1 is the DU cross-chain access identifier, T1 is the timestamp, and N1 is the parameter for maintaining session freshness; message M1 is forwarded to DO through the cross-domain gateway.

6. A method for realizing cross-chain data sharing between different cryptographic systems according to claim 5, characterized in that: In S4, when DO receives the request, it verifies the validity of the message and the correctness of the DU identity; if the verification is successful, DO randomly selects λ and X, and uses its own private key sk' DO and DU's public key pk DU , generate the re-encryption key rk DO , and rk DO Send to CRF A ; rk DO =(rk1,rk2,rk3) rk2=g λ rk3=X·e(pk DU1 ,pk DU2 ) λ Among them, rk1, rk2, rk3 are the re-encryption key sequences; CRF A Received DO After that, generate a randomized re-encryption key rk' DO : rk' DO =(rk1',rk'2,rk3') rk'2=rk2·g λ =g λ+β rk3'=rk3·e(pk DU1 ,pk DU2 ) β =X·e(pk DU1 ,pk DU2 ) λ+β Among them, rk1', rk'2, rk3' are randomized re-encryption key sequences; Then DO sends the ciphertext identifier Data1 and the cross-domain data sharing permission message M2 = {request2, pk DO ,pk DU ,rk' DO ,T2,N2} sent to Hostial A , request2 is the DO cross-chain access identifier.

7. A method for realizing cross-chain data sharing between different cryptographic systems according to claim 6, characterized in that: In S5, Hospital A Schedule smart contract algorithm Algorithm1, and finally send message M2 and ciphertext C' DO Send to the relay chain.

8. A method for realizing cross-chain data sharing between different cryptographic systems according to claim 7, characterized in that: In S6, after receiving the permission information, the relay link authenticates the validity of the request through the coordination node; if the request is authenticated, the relay chain DO and rk' DO Generate re-encrypted ciphertext C DU Finally, the relay chain sends the response message M3={respond1,C DU ,T3,N3} is sent to DU, respond1 is the response identifier; C DU =(C1,C2,C3,C4) C1=c1' C2=c'2·e(C1,rk1',c'3) C3=rk'2 C4=rk3' Among them, C1, C2, C3, and C4 are re-encrypted ciphertext sequences.

9. A method for realizing cross-chain data sharing between different cryptographic systems according to claim 8, characterized in that: In S7, after receiving the response message M3, DU first verifies the validity of the message, and after successful verification, uses its own private key sk DU calculate Recalculate Get the message M.

Images