Data sharing method and related device

Abstract

The present application discloses a data sharing method and a related device. The method is applied to a data receiver. The method comprises: receiving encrypted target data sent by a data holder; uploading first identity information to a blockchain, the first identity information being used for proving that the data receiver is a permitted entity permitted by the data holder to acquire the target data, the blockchain storing second identity information uploaded by the data holder, and the second identity information being identity information of the permitted entity permitted by the data holder to acquire the target data; and, upon the blockchain generating a passed verification result, on the basis of the passed verification result, triggering an identity authentication module to decrypt the encrypted target data, the identity authentication module being used for decrypting the encrypted target data by using the passed verification result generated by the blockchain as a target data decryption trigger condition.

Description

Data sharing method and related device

[0001] Cross-reference to related applications

[0002] This application is based on and claims priority to Chinese Patent Application No. 202410864191.X, filed on June 30, 2024, the entire contents of which are incorporated herein by reference. TECHNICAL FIELD

[0003] The present application relates to the technical field of data security, and in particular to a data sharing method and related device. BACKGROUND

[0004] Data sharing is to enable users using different computers and different software in different places to read other people's data and perform various operations, calculations and analysis. Taking medical data sharing as an example, the sharing of medical data between medical workers and medical institutions is of great significance for the treatment and analysis of diseases.

[0005] At present, how to reduce the data abuse risk faced in the data sharing process is a problem to be solved.

[0006] Among them, data abuse, also known as data misuse, refers to improper or illegal use, access, processing or sharing of personal data or institutional data without authorization or explicit permission. SUMMARY

[0007] Embodiments of the present application provide a data sharing method, device, electronic equipment, computer readable storage medium and computer program product.

[0008] Embodiments of the present application adopt the following technical solutions:

[0009] In a first aspect, the embodiments of the present application provide a data sharing method applied to a data receiver, comprising:

[0010] receiving encrypted target data sent by a data holder;

[0011] uploading first identity information to a blockchain; the first identity information is used to prove that the data receiver is a licensed object permitted by the data holder to obtain the target data; the blockchain stores second identity information uploaded by the data holder; the second identity information is identity information of a licensed object permitted by the data holder to obtain the target data;

[0012] When the blockchain generates the verification pass result, based on the verification pass result, triggering the identity authentication module to decrypt the encrypted target data; the identity authentication module is configured to: take the verification pass result generated by the blockchain as a target data decryption trigger condition, and decrypt the encrypted target data;

[0013] The verification pass result represents that the first identity information and the second identity information are matched with each other through the smart contract verification of the blockchain.

[0014] In some optional embodiments, the first identity information includes: a first digital signature of the encrypted target data based on a digital signature private key of the data receiver; and the second identity information includes: a digital signature public key of the permitted object.

[0015] In some optional embodiments, the method further includes:

[0016] Signing the first digital signature based on the digital signature private key to obtain a second digital signature;

[0017] Uploading the second digital signature to the blockchain, so that the smart contract verifies whether the first identity information and the second identity information are matched with each other based on the digital signature public key of the permitted object verifying the second digital signature pass.

[0018] In a second aspect, the embodiments of the present application provide a data sharing method, applied to a data holder, and the method includes:

[0019] Sending the encrypted target data to a data receiver;

[0020] Uploading the second identity information to the blockchain to trigger the smart contract of the blockchain to verify whether the second identity information and the first identity information are matched with each other;

[0021] The second identity information is identity information of a permitted object permitted by the data holder to obtain the target data;

[0022] The first identity information is information provided by the data receiver of the encrypted target data, used to prove that the data receiver is the permitted object.

[0023] In some optional embodiments, before the encrypted target data is sent to the data receiver, the method further includes:

[0024] Obtaining a digital identity identifier of the data receiver;

[0025] Parsing the digital identity identifier to obtain an encryption public key of the data receiver;

[0026] Encrypting the target data based on the encryption public key to obtain the encrypted target data.

[0027] In a third aspect, the embodiments of the present application provide a data sharing method applied to an identity authentication module, and the method comprises the following steps:

[0028] generating an encryption key of a receiving party or generating a decryption key of a data receiving party;

[0029] encrypting target data of a data holding party by using the encryption key to obtain encrypted target data;

[0030] decrypting the encrypted target data received by the data receiving party when the smart contract of the blockchain verifies that the first identity information and the second identity information match each other;

[0031] the first identity information is information provided by the data receiving party of the encrypted target data and used to prove that the data receiving party is a licensed object;

[0032] the second identity information is identity information of a licensed object licensed by the data holding party to obtain the target data.

[0033] In a fourth aspect, the embodiments of the present application provide a data sharing device applied to a data receiving party, comprising a data receiving module, an information uploading module and a data decryption module, wherein:

[0034] the data receiving module is configured to receive the encrypted target data sent by the data holding party;

[0035] the information uploading module is configured to upload the first identity information to the blockchain; the first identity information is used to prove that the data receiving party is a licensed object licensed by the data holding party to obtain the target data; the blockchain stores the second identity information uploaded by the data holding party; and the second identity information is identity information of a licensed object licensed by the data holding party to obtain the target data;

[0036] the data decryption module is configured to trigger the identity authentication module to decrypt the encrypted target data based on the verification pass result when the verification pass result is generated by the blockchain; and the identity authentication module is configured to decrypt the encrypted target data by taking the verification pass result generated by the blockchain as a target data decryption trigger condition.

[0037] the verification pass result represents that the verification result of the smart contract of the blockchain is that the first identity information and the second identity information match each other.

[0038] In a fifth aspect, the embodiments of the present application provide an electronic device, comprising a memory, a processor and a computer program stored in the memory and capable of running on the processor, wherein the computer program is executed by the processor to implement the steps of the data sharing method described above.

[0039] In a sixth aspect, an embodiment of the present application provides a computer readable storage medium, and the computer readable storage medium stores a computer program. The computer program is executed by a processor to implement the steps of the data sharing method.

[0040] In a ninth aspect, an embodiment of the present application provides a computer program product, which includes a computer program. The computer program is executed by a processor to implement the data sharing method.

[0041] The above at least one technical solution adopted by the embodiment of the present application can achieve the following beneficial effects:

[0042] By using the method provided by the embodiment of the present application, when it is determined that the first identity information and the second identity information match each other, that is, when it is determined that the identity information of the data receiver and the identity information of the licensed object of the data holder permitted to obtain the target data match each other, the encrypted target data is decrypted by taking the verification pass result of the block chain as the target data decryption trigger condition, and thus the risk of data abuse in the medical data sharing process in the related art can be avoided, thereby ensuring the security and accountability of the target data in the data sharing process. BRIEF DESCRIPTION OF DRAWINGS

[0043] The accompanying drawings, which are included to provide a further understanding of the present application, constitute a part of the present application and illustrate the illustrative embodiments of the present application and their description serve to explain the present application, and do not constitute improper limitations on the present application. In the drawings:

[0044] FIG. 1a is a schematic diagram of an implementation process of a data sharing method according to an embodiment of the present application;

[0045] FIG. 1b is a schematic diagram of an implementation process of a key generation method in a data sharing method according to an embodiment of the present application;

[0046] FIG. 1c is a schematic diagram of an implementation process of an identity information authentication method of a data holder and a data receiver in a data sharing method according to an embodiment of the present application;

[0047] FIG. 2 is a schematic diagram of an implementation process of a data sharing method according to an embodiment of the present application;

[0048] FIG. 3 is a schematic diagram of an implementation process of a data sharing method according to an embodiment of the present application;

[0049] FIG. 4 is a schematic diagram of an application process of the method according to an embodiment of the present application in practice;

[0050] FIG. 5 is a schematic diagram of a specific structure of a data sharing device according to an embodiment of the present application;

[0051] FIG. 6 is a schematic diagram of a specific structure of a data sharing apparatus according to an embodiment of the present application;

[0052] FIG. 7 is a schematic diagram of a specific structure of a data sharing apparatus according to an embodiment of the present application;

[0053] FIG. 8 is a schematic diagram of a structure of an electronic device according to an embodiment of the present application. DETAILED DESCRIPTION

[0054] In order to make the objectives, technical solutions and advantages of the present application clearer, the technical solutions of the present application will be described below in detail with reference to the embodiments of the present application and corresponding drawings. Obviously, the described embodiments are only some of the embodiments of the present application, but not all the embodiments of the present application. Based on the embodiments in the present application, all other embodiments obtained by those of ordinary skill in the art without creative work fall within the scope of protection of the present application.

[0055] The technical solutions provided by the embodiments of the present application will be described in detail below with reference to the accompanying drawings.

[0056] In order to solve the problem of data misuse and other risks in the medical data sharing process in the related art, and to ensure the security of medical data, the embodiments of the present application provide a data sharing method.

[0057] The execution subject of the method can include various types of computing devices, or can include an application program or application (APP) installed on a computing device. The computing device can include, for example, a user terminal such as a mobile phone, a tablet computer, a smart wearable device, etc., and can also include a server, etc.

[0058] For ease of description, the embodiments of the present application take the server as an example of the execution subject of the method to introduce the method. Those skilled in the art can understand that the embodiments of the present application take the server as an example to introduce the method, which is only an exemplary description, and does not limit the scope of protection of the corresponding claims of the present application.

[0059] Specifically, the implementation process of the method provided by the embodiments of the present application is shown in FIG. 1a, which is applied to a data receiver and includes the following steps:

[0060] Step 11, receiving the encrypted target data sent by the data holder.

[0061] The data holder refers to an entity or organization that owns or controls specific data. For example, in the medical data sharing scenario, the data holder can refer to a medical patient who owns medical data (such as medical record information), etc.

[0062] Target data refers to data to be shared by a data holder, or can also be understood as data requested to be shared by a data receiver.

[0063] For example, taking a medical data sharing scenario as an example, assuming that user A (such as a patient) has medical diagnosis data, and user B (such as a staff of a medical institution) requests user A to share the medical diagnosis data, at this time, user A can be understood as a data holder, and user B can be understood as a data receiver; correspondingly, the medical diagnosis data of user A is also target data.

[0064] In actual application, if a data receiver expects to obtain target data held by a data holder, the data receiver can send a data sharing request to the data holder. After receiving the data sharing request, the data holder can send encrypted target data to the data receiver in response to the data sharing request of the data receiver.

[0065] Among them, the data holder sends the encrypted target data to the data receiver instead of directly sending the target data to the data receiver, in order to ensure that the target data is not obtained or tampered with by an unauthorized third party in the transmission process.

[0066] In the embodiments of the present application, the encrypted target data sent by the data holder can be obtained by the data holder based on the encryption public key of the data receiver; wherein the encryption public key can be generated by the identity authentication module of the data receiver.

[0067] When the encryption public key is generated by the identity authentication module, since the identity authentication module has hardware-level security permission management measures, unauthorized access and operation can be prevented, only the data receiver who has legally completed the blockchain decryption request can perform data decryption, thereby improving the security of the target data.

[0068] In an optional implementation, the identity authentication module can include a subscriber identity module (SIM card), or also referred to as a mobile phone external chip, or an external chip CHIP, etc.

[0069] Hereinafter, taking the identity authentication module as a SIM card as an example, the method of generating an encryption public key based on the identity authentication module mentioned in the embodiments of the present application is described.

[0070] In an alternative embodiment, when the encryption public key needs to be generated, the data holder or the data recipient can respectively initiate the designated local application or application on the terminal device of the data holder or the data recipient, and initiate the SIM card application on the terminal device of the data holder or the data recipient to send a key generation request to the SIM card application on the terminal device. After the SIM card application on the terminal device of the data holder or the data recipient receives the key generation request, the encryption public key can be generated for the data holder.

[0071] The designated local application or application on the terminal device of the data holder, for example, can include a SIM Toolkit (STK) application. The STK application can perform the key generation operation through a menu option on the SIM card.

[0072] In an alternative embodiment, when the data holder or the data recipient needs to use other keys, such as an encryption private key, a digital signature public key, or a digital signature private key, the keys can also be generated based on the SIM card application on the terminal device of the data holder or the data recipient. The generation method is the same as the method of generating the encryption public key described above, which will not be repeated here.

[0073] For example, as shown in FIG. 1b, assuming that the data holder is a medical data holder, the medical data holder can send a key generation request to the SIM card of the medical data holder terminal device based on the designated local application or application installed in the medical data holder terminal device. After the SIM card receives the key generation request of the medical data holder terminal device, the SIM card can generate public and private keys for encryption and decryption (i.e., the public key and the private key in FIG. 1b) and public and private keys for digital signature (i.e., the public key and the private key in FIG. 1b) for the medical data holder terminal device, respectively. Then, the encryption and decryption public key and the digital signature public key are returned to the medical data holder terminal device through a data interface (i.e., the I PK in FIG. 1b). The encryption and decryption private key (i.e., the private key in FIG. 1b) and the digital signature private key (i.e., the private key in FIG. 1b) will always be stored in the SIM card (always not leaving the SIM card) and invisible to the outside.

[0074] Similarly, for the medical data receiver, the SIM card of the medical data receiver terminal device can be sent a key generation request based on a specified local application or application installed in the medical data receiver terminal device; after the SIM card receives the key generation request of the medical data receiver terminal device, the SIM card can generate a public key and a private key (i.e., the public key and the private key in FIG. 1b and ) for encryption and decryption, and a public key and a private key (i.e., the public key and the private key in FIG. 1b and ) for digital signature for the medical data receiver terminal device. Then, the public key for encryption and decryption and the public key for digital signature are returned to the medical data receiver terminal device through a data interface. The private key for encryption and decryption and the private key for digital signature are stored in the SIM card (always do not leave the SIM card) and are invisible to the outside.

[0075] In FIG. 1b, the represents an encryption public key of the medical data holder, which is used for encrypting data; represents an encryption private key of the medical data holder, which is used for decrypting data; represents a digital signature public key of the medical data holder, which is used for verifying the authenticity of a digital signature; represents a digital signature private key of the medical data holder, which is used for digital signature; represents an encryption public key of the medical data receiver, which is used for encrypting data; represents an encryption private key of the medical data receiver, which is used for decrypting data; represents a digital signature public key of the medical data receiver, which is used for verifying the authenticity of a digital signature; represents a digital signature private key of the medical data receiver, which is used for digital signature.

[0076] It should be noted that, in the embodiment of the present application, the data holder encrypts the target data based on the encryption public key of the data receiver, rather than encrypting the target data through the encryption public key of the data holder. Therefore, before the data holder encrypts the target data based on the encryption public key of the data receiver, the data holder also needs to obtain the encryption public key of the data receiver.

[0077] In an optional implementation, in order to facilitate the data holder to obtain the encryption public key of the data receiver, and in order to facilitate the subsequent data holder and the smart contract of the blockchain to verify the digital signature of the data receiver, after the identity authentication module of the data receiver generates the encryption public key and the digital signature public key, the data receiver can upload the encryption public key and the digital signature public key to the blockchain, so that the data holder can obtain the encryption public key and the digital signature public key of the data receiver from the blockchain.

[0078] In an optional implementation, the data holder can also upload the encryption and decryption public key and the digital signature public key generated by the identity authentication module of the data holder to the blockchain.

[0079] In addition, in an optional implementation, in order to facilitate the data holder or the smart contract of the blockchain to obtain the encryption public key and the digital signature public key of the data receiver from the blockchain, it is usually necessary to bind the mapping relationship between the encryption public key, the digital signature public key of the data receiver and the identity information of the data receiver. In this way, the data holder or the smart contract of the blockchain can obtain the encryption public key and the digital signature public key of the data receiver that matches the identity information from the blockchain according to the identity information of the data receiver.

[0080] For example, taking the phone number as the identity information, the mapping relationship between the encryption public key, the digital signature public key of the data receiver and the phone number of the data receiver can be bound in the embodiments of the present application, so that the subsequent data holder can determine the encryption public key and the digital signature public key of the data receiver based on the phone number of the data receiver.

[0081] However, in actual application, considering that if the identity information (such as the phone number) of the data receiver is directly used, it may cause the problem of leakage of the identity information of the data receiver. In order to avoid this problem, in the embodiments of the present application, the DID digital identity of the data receiver can be pre-applied based on the identity information of the data receiver, and then the relationship among the DID digital identity of the data receiver, the identity information, the encryption public key and the digital signature public key of the data receiver can be bound, so that the encryption public key and the digital signature public key of the data receiver and other information can be obtained through the DID digital identity of the data receiver. In this way, since the identity information (such as the phone number) of the data receiver is not directly used to obtain the encryption public key and the digital signature public key of the data receiver, the problem of leakage of the identity information of the data receiver can be avoided.

[0082] For example, as shown in FIG. 1c, in an optional implementation, the following method can be used to apply for and register the DID digital identity, and to bind the relationship among the DID digital identity, the identity information, the encryption public key and the digital signature public key:

[0083] (1) The local application of the data receiver / data holder respectively verifies the identity information of the data receiver / data holder, such as the phone number; when the verification is passed, the following step (2) is performed. Otherwise, the registration of the DID digital identity is stopped.

[0084] (2) The data receiver / data holder calls the data interface I PK based on the identity information, such as the phone number and the ID card number, to apply for the public key of the SIM card of the data receiver / data holder, which includes the digital signature public key and the encryption public key.

[0085] (3) After the SIM card receives the public key application request sent by the data receiver / data holder, the data interface I PK returns the digital signature public key and the encryption public key of the data receiver / data holder to the data receiver / data holder.

[0086] (4) After the data receiver / data holder receives the digital signature public key and the encryption public key, the data receiver / data holder can apply for the registration of the DID digital identity based on the identity information of the data receiver / data holder, the obtained digital signature public key, and the encryption public key to the DID digital identity registration and resolution interface (hereinafter referred to as the DID digital identity registration and resolution interface for convenience).

[0087] (5) After the DID digital identity registration and resolution interface receives the DID digital identity registration request sent by the data receiver / data holder, the DID digital identity registration and resolution interface can generate the digital identity DID and the matching DID document for the data receiver / data holder, and upload them to the block chain for storage.

[0088] In an optional embodiment, the format of the digital identity DID conforms to the W3C DID standard, and the digital identity DID can include the identifier prefix, the DID method identifier, and the user unique identity code.

[0089] For example, in an optional embodiment, the digital identity DID of the data receiver / data holder can be described as follows:

[0090] “did:example:ejiegjlrijrgirgj229939”;

[0091] wherein did is the identifier prefix, example is the DID method identifier, and ejiegjlrijrgirgj229939 is the generated user unique identity code.

[0092] Secondly, the matched DID document can include digital identity DID, identity information, digital signature public key, and encryption public key, etc. For example, in an optional embodiment, the matched DID document can be described in the following format:

[0093] Among them, "id": "did:example:ejiegjlrijrgirgj229939" is the digital identity DID; "phone": "+86 138 1111 1111" is the identity information; "0x33jtlti3tt34tij4ti" is the encryption public key; "0x3xxxxxxx" is the digital signature public key.

[0094] Through the above steps (1)-(5), the digital identity DID of the data receiver / data holder, the digital signature public key of the data receiver / data holder, the encryption public key, and the identity information of the data receiver / data holder can be recorded in the DID document, and are bound to each other.

[0095] It should be noted that the above-mentioned digital identity DID and the format of the matched DID document are only an exemplary description of the embodiments of the present application, and do not cause any limitation on the embodiments of the present application.

[0096] (5) After the blockchain consensus, the DID document of the data receiver / data holder can be stored in the block.

[0097] (6) Then, the blockchain can return the DID document on-chain result and storage address to the DID digital identity registration and analysis interface.

[0098] (7) After receiving the DID document on-chain result and storage address, the DID digital identity registration and analysis interface can return the digital identity DID to the designated local application or application of the data receiver / data holder. At this point, the digital identity DID, the digital signature public key, the encryption public key, and the identity information of the data receiver / data holder are bound.

[0099] Step 12, uploading the first identity information to the blockchain.

[0100] The first identity information is used to prove that the data receiver is a licensed object permitted by the data holder to obtain the target data.

[0101] The licensed object is a data demander who has the permission to obtain the target data.

[0102] In practical applications, malicious users may intercept data during data transmission. For example, a data holder wants to transmit target data to user A, but the target data is intercepted by malicious user B during data transmission. In this case, the actual data receiver of the target data is malicious user B, rather than user A as expected by the data holder.

[0103] To avoid the leakage of target data when the actual data receiver is not the data receiver expected by the data holder, the identity information of the data receiver needs to be verified in the embodiments of the present application to confirm whether the actual data receiver is the data receiver expected by the data holder. Therefore, the data receiver needs to upload first identity information that can be used to prove that the data receiver is a permitted object permitted by the data holder to obtain the target data.

[0104] The blockchain stores second identity information uploaded by the data holder. The second identity information is the identity information of a permitted object permitted by the data holder to obtain the target data. In other words, the second identity information can also be understood as the identity information of a specific permitted object or entity permitted by the data holder to obtain the target data.

[0105] For example, if the data holder permits user A to obtain the target data, the first identity information is the identity information of user A.

[0106] In an optional embodiment, the first identity information can include a first digital signature of the target data encrypted based on a digital signature private key of the data receiver, and the second identity information can include a digital signature public key of the permitted object.

[0107] In this way, when the blockchain receives the first identity information uploaded by the data receiver, the first digital signature of the target data encrypted based on the digital signature private key of the data receiver can be verified based on the second identity information, i.e., the digital signature public key of the permitted object, to verify whether the first identity information and the second identity information match each other. Specifically, if the verification passes, it is considered that the first identity information and the second identity information match each other, i.e., the data receiver is the permitted object permitted by the data holder to obtain the target data.

[0108] In an optional embodiment, when the first identity information includes the first digital signature of the target data encrypted based on the digital signature private key of the data receiver, in order to prevent the first digital signature from being tampered with and thus affecting the identity confirmation result of the data receiver, the following steps can also be performed:

[0109] (1) signing the first digital signature based on the digital signature private key to obtain a second digital signature;

[0110] (2) uploading the second digital signature to the blockchain, so that the smart contract verifies whether the first identity information and the second identity information match each other after verifying the second digital signature based on the digital signature public key of the authorized object.

[0111] In the embodiment, the first digital signature is signed based on the digital signature private key to obtain the second digital signature, so as to prevent the first digital signature from being tampered with, thereby affecting the identity confirmation result of the data receiver.

[0112] In an optional embodiment, the digital signature public key of the authorized object can be recorded in the first receipt authorization record created by the data holder.

[0113] The first data authorization record Record can be used to record information related to the target data that the data holder authorizes the authorized object to obtain.

[0114] For example, in addition to the digital signature public key of the authorized object, the first data authorization record Record can further include the validity period of the target data that the data holder authorizes the authorized object to obtain, and the ciphertext digest of the data holder.

[0115] In another optional embodiment, in addition to the first identity information of the data receiver, the request date of the data receiver for the target data, and the ciphertext digest of the data receiver, the information can also assist in verifying the legitimacy of the identity of the data receiver, so the data receiver can upload the request date of the data receiver for the target data and the ciphertext digest of the data receiver to the blockchain in addition to the first identity information.

[0116] In an optional embodiment, the first identity information, the request date of the data receiver for the target data, and the ciphertext digest of the data receiver can be recorded in the second data authorization record Record.

[0117] The second data authorization record Record can be used to record information related to the data receiver for proving that the data receiver is the authorized object authorized by the data holder to obtain the target data.

[0118] In the following, taking the digital signature public key of the authorized object (i.e. the second identity information) recorded in the first receipt authorization record created by the data holder and the first identity information recorded in the second data authorization record Record as an example, the application of step 12 in practice is described in detail in combination with actual scenarios.

[0119] (1) The data receiver can first digitally sign the encrypted target data using its digital signature private key after receiving the encrypted target data, and then update the first data authorization record Record in the smart contract to obtain an updated second data authorization record Record, and upload the second data authorization record Record to the blockchain.

[0120] In an optional embodiment, considering that in some cases the data volume of the encrypted target data can be large, if the encrypted target data is digitally signed using the digital signature private key of the data receiver, the workload and work difficulty can increase. To solve this problem, in an optional embodiment of the present application, the data receiver can digitally sign the ciphertext digest using its digital signature private key instead of digitally signing the encrypted target data using its digital signature private key, thereby reducing the workload and reducing the work difficulty.

[0121] It should be noted that in the present application, it is not limited to digitally signing the ciphertext digest based on the digital signature private key of the data receiver, or digitally signing the encrypted target data based on the digital signature private key of the data receiver. In actual application, the digital signature private key of the data receiver can be selected to digitally sign the ciphertext digest or digitally sign the encrypted target data based on the actual needs.

[0122] The smart contract includes a first data authorization record Record created by the data holder.

[0123] In an optional embodiment, taking the example of selecting the digital signature private key of the data receiver to digitally sign the ciphertext digest, the structure of the data authorization record Record can be defined as:

[0124] Record=[

[0125] Authorized decryption party: {ciphertext digest, validity period, digital signature public key of the receiver for verifying the digital signature},

[0126] Actual decryption party: {ciphertext digest, request date, digital signature of the receiver's digital signature private key on the ciphertext digest}

[0127] ]

[0128] Wherein, the authorized party is the data holder; the decryption party is the data receiver.

[0129] It should be noted that in the first data authorization record Record created by the data holder, the information of the decryption party (i.e. the data receiver) is empty and needs to be updated by the data receiver later.

[0130] For example, taking the above-mentioned data authorization record Record as an example, in the embodiments of the present application, the data authorization record Record created by the data holder may, for example, include:

[0131] Record=[

[0132] Authorized decryptor: {0x001, after 20231006, MFYwEA…},

[0133] Actual decryptor: {null, null, null}

[0134] ]

[0135] Among them, “0x001” is the ciphertext digest in the first data authorization record Record of the data holder; “after 20231006” is the validity period in the first data authorization record Record of the data holder; “MFYwEA…” is the digital signature public key of the data holder in the first data authorization record Record of the data holder, which is the digital signature public key of the permitted object.

[0136] Correspondingly, the content of the second data authorization record Record updated by the data receiver can be described as follows:

[0137] Record=[

[0138] Authorized decryptor: {0x001, after 20231006, MFYwEA…},

[0139] Actual decryptor: {0x001, 20231018, YHKoZIz…}

[0140] ]

[0141] Among them, “0x0001” is the ciphertext digest in the second data authorization record Record of the data receiver; “after 20231006” is the request date in the second data authorization record Record of the data receiver; “MFYwEA…” is the first digital signature of the data receiver based on the digital signature private key of the data receiver on the ciphertext digest in the second data authorization record Record of the data receiver.

[0142] (2) After obtaining the second data authorization record Record, the data receiver can also sign the second data authorization record Record based on the digital signature private key, for example:

[0143] (3) The data receiver creates a new transaction on the blockchain, and sends the second data authorization record Record and the digital signature of the second data authorization record Record, i.e., (Evidence Receiver , Record) as a transaction appendix to the blockchain.

[0144] After the blockchain receives the transaction appendix, the blockchain can verify the correctness of the digital signature through the smart contract of the blockchain. If the verification is incorrect, i.e., false = Verify(Evidence Resiver , Record, ), the system exits. Otherwise, (Evidence Resiver , Record) is saved to the blockchain.

[0145] In an optional implementation, the smart contract mentioned in the embodiments of the present application can be described as follows:

[0146] It should be noted that the above-mentioned examples of the smart contract are only exemplary descriptions of the embodiments of the present application and do not limit the embodiments of the present application in any way.

[0147] Step 13, when the blockchain produces a verification pass result, based on the verification pass result, triggering the identity authentication module to decrypt the encrypted target data; the identity authentication module is configured to: taking the verification pass result generated by the blockchain as a target data decryption trigger condition, decrypting the encrypted target data;

[0148] The verification pass result represents that the verification result of the smart contract of the blockchain is that the first identity information and the second identity information match each other.

[0149] It should be noted that in the embodiments of the present application, in order to ensure the ownership of the target data, the target data can be stored only on the local device of the data holder and the data receiver, and not stored in the cloud service, the blockchain or other third-party devices.

[0150] In the embodiments of the present application, when the blockchain confirms the first identity information, a verification pass result can be generated and sent to the identity authentication module to trigger the identity authentication module to decrypt the encrypted target data.

[0151] For example, following the example of step 12 described above, i.e., after the blockchain confirms the transaction created by the data holder on the blockchain and the updated authorization record, the confirmed transaction and the updated authorization record can be sent to the identity authentication module as proof information to trigger the identity authentication module to decrypt the encrypted target data.

[0152] In the embodiments of the present application, after the identity authentication module receives the confirmed transaction and the updated authorization record, the following operations can be performed:

[0153] (1) judging whether the transaction created by the data receiver is confirmed by the block chain, that is, judging whether the transaction created by the data receiver is on the chain;

[0154] (2) judging whether the digital signature of the data receiver's public key for the encrypted target data is correct;

[0155] If any one of conditions (1) and (2) is not met, the identity authentication module stops decryption; and only when conditions (1) and (2) are met at the same time, the identity authentication module performs decryption.

[0156] Specifically, the identity authentication module can obtain the encryption and decryption private key stored by the identity authentication module, then decrypt the encrypted target data based on the encryption and decryption private key, and display the decrypted target data to the data receiver.

[0157] In an optional embodiment, after the encrypted target data is decrypted, the transaction information can also be audited by an auditor on the block chain.

[0158] Specifically, the auditor can read the transaction information and smart contract information recorded on the block chain, and if there is transaction information, it means that the data sharing and decryption have been completed. Alternatively, if it is confirmed that the data receiver has not decrypted within the specified decryption range, such as not decrypted within the specified time, the auditor can hold the data receiver accountable and punish the data receiver.

[0159] Among them, the accountability mode may include, for example: the auditor can use the block chain analysis tools and technologies based on the transaction records recorded on the block chain to detail the illegal behavior of the data receiver, and provide the corresponding evidence and analysis results, so as to realize the accountability.

[0160] Secondly, the punishment mode may include, for example: reducing the credit of the data receiver, freezing the data assets of the data receiver, or fining the data receiver, etc.

[0161] It should be noted that the above-mentioned accountability mode and punishment mode are only examples of the embodiments of the present application, and do not limit the present application in any way.

[0162] In an optional implementation, it is considered that in actual application, the data receiver cannot decrypt the encrypted target data according to the decryption rule / regulation preset by the data holder, which may be affected by some unpredictable emergent conditions in the decryption process, rather than maliciously not decrypting according to the preset decryption rule / regulation. In order to avoid mispenalizing the data receiver by the auditor in this case, in the embodiment of the present application, when the auditor monitors that the data receiver does not decrypt according to the preset decryption rule / regulation, it can be first judged whether the data receiver is maliciously not decrypting according to the preset decryption rule / regulation or is affected by the emergent condition and cannot decrypt according to the decryption rule / regulation preset by the data holder. Then, whether to penalize the data receiver is determined based on the judgment result.

[0163] Specifically, when it is determined that the data receiver is maliciously not decrypting according to the preset decryption rule / regulation, the data receiver can be penalized. On the contrary, if it is determined that the data receiver is affected by the emergent condition and cannot decrypt according to the decryption rule / regulation preset by the data holder, the data receiver is not penalized.

[0164] In an optional implementation, when it is determined that the data receiver is affected by the emergent condition and cannot decrypt according to the decryption rule / regulation preset by the data holder, in the embodiment of the present application, the user authorized by the data receiver can also be allowed to decrypt the encrypted target data according to the authorization information of the data receiver.

[0165] By using the method provided in the embodiment of the present application, when it is determined that the first identity information and the second identity information match each other, that is, when it is determined that the identity information of the data receiver matches the identity information of the authorized object of the data holder permitted to obtain the target data, the verification pass result of the block chain is used as a decryption trigger condition of the target data, and the encrypted target data is decrypted, thereby avoiding the risk of data abuse in the medical data sharing process in the related art, and ensuring the security of the target data in the data sharing process.

[0166] To solve the problem of data abuse in the medical data sharing process in the related art and the difficulty in ensuring the security of the medical data, the embodiment of the present application provides a data sharing method, which is applied to a data holder. Specifically, the implementation process of the method provided in the embodiment of the present application is shown in FIG. 2, which includes the following steps:

[0167] Step 21, sending the encrypted target data to the data receiver.

[0168] In the embodiments of the present application, the data holder sends the encrypted target data to the data receiver instead of directly sending the target data to the data receiver, in order to ensure that the target data is not acquired or tampered with by unauthorized third parties during transmission.

[0169] In an optional implementation, the encrypted target data sent by the data holder can be encrypted by the data holder based on the encryption public key of the data receiver; wherein the encryption public key can be generated by the identity authentication module of the data receiver.

[0170] In the embodiments of the present application, when the identity authentication module generates the encryption public key for encrypting the target data, since the identity authentication module has hardware-level security permission management measures, unauthorized access and operation can be prevented, and only the data receiver who has legally completed the blockchain decryption request can perform data decryption, thereby improving the security of the target data.

[0171] In an optional implementation, the identity authentication module can include a Subscriber Identity Module (SIM) card, or also known as a mobile phone external chip, or an external chip CHIP, etc.

[0172] Wherein, the specific implementation of generating the encryption public key for encrypting the target data based on the identity authentication module can refer to the description related to Figure 1b in Embodiment 1 above, which will not be repeated here.

[0173] It should be noted that, in the embodiments of the present application, the data holder encrypts the target data based on the encryption public key of the data receiver, rather than encrypting the target data through the data holder's own encryption public key. Therefore, before the data holder encrypts the target data based on the encryption public key of the data receiver, the data holder also needs to obtain the encryption public key of the data receiver.

[0174] In an optional implementation, in order to facilitate the data holder to obtain the encryption public key of the data receiver, in the embodiments of the present application, after the data holder generates the encryption public key based on the identity authentication module, the data holder can upload the encryption public key to the blockchain, so that the data holder can obtain the encryption public key of the data receiver from the blockchain.

[0175] Step 22, upload the second identity information to the blockchain to trigger the smart contract of the blockchain to verify whether the second identity information and the first identity information match each other.

[0176] It should be noted that the above step 21 and the above step 22 do not limit the execution order of the present application. For example, in an alternative embodiment, the second identity information can be uploaded to the block chain while the encrypted target data is sent to the data receiver.

[0177] The second identity information is identity information of a licensed object permitted by the data holder to obtain the target data. The licensed object is a data demander who has the permission to obtain the target data.

[0178] The first identity information is information provided by the data receiver of the encrypted target data to prove that the data receiver is the licensed object.

[0179] In an alternative embodiment, the first identity information can include a first digital signature of the encrypted target data based on a digital signature private key of the data receiver, and the second identity information can include a digital signature public key of the licensed object.

[0180] In an alternative embodiment, the digital signature public key of the licensed object can be recorded in the first receipt authorization record created by the data holder.

[0181] The first data authorization record Record can be used to record information related to the permission of the licensed object to obtain the target data by the data holder, etc. For example, in addition to the digital signature public key of the licensed object, the first data authorization record Record can also include the validity period of the permission of the licensed object to obtain the target data by the data holder, and the information such as the ciphertext digest of the data holder.

[0182] In an alternative embodiment, the structure of the data authorization record Record can be defined as:

[0183] Authorized decryptor: {ciphertext digest, validity period, digital signature public key of the receiver for verifying the digital signature},

[0184] Actual decryptor: {ciphertext digest, request date, digital signature of the receiver digital signature private key on the ciphertext digest / digital signature of the receiver digital signature private key on the encrypted target data}

[0185] ]

[0186] The authorized decryptor is the data holder, and the actual decryptor is the data receiver.

[0187] It should be noted that the information of the actual decryptor (i.e., the data receiver) in the data authorization record Record created by the data holder is empty and needs to be updated by the data receiver subsequently.

[0188] Specifically, the data authorization record Record created by the data holder can include, for example:

[0189] Record = [

[0190] Authorized decryptor: {0x001, after 20231006, MFYwEA…},

[0191] Actual decryptor: {null, null, null}

[0192] ]

[0193] Wherein, "0x001" is the ciphertext digest in the first data authorization record Record of the data holder; "after 20231006" is the validity period in the first data authorization record Record of the data holder; "MFYwEA…" is the digital signature public key in the first data authorization record Record of the data holder, which is used by the receiver to verify the digital signature, that is, the digital signature public key of the permitted object.

[0194] In an optional embodiment, before sending the encrypted target data to the data receiver, the method further comprises:

[0195] Obtaining a digital identity identifier of the data receiver;

[0196] Parsing the digital identity identifier to obtain an encryption public key of the data receiver;

[0197] Encrypting the target data based on the encryption public key to obtain the encrypted target data.

[0198] Wherein, the digital identity identifier of the data receiver can include a DID digital identity; the DID digital identity can be obtained by the data receiver applying for registration to a Decentralized identifiers (DID) digital identity registration and parsing interface.

[0199] Specifically, the specific implementation of the data receiver applying for registration of the DID digital identity to the Decentralized identifiers (DID) digital identity registration and parsing interface can refer to the description related to FIG. 1c in the above embodiment 1, which will not be repeated here.

[0200] In an optional embodiment, if the data holder is obtaining the encryption public key of the data receiver for the first time, in order to ensure the accuracy of the encryption public key of the data receiver, the data holder can authenticate the data receiver in the embodiment of the application. Wherein, the way in which the data holder authenticates the data receiver includes the following:

[0201] (1) When the data holder needs to authenticate the data receiver, identity authentication challenge information X can be sent to the data receiver;

[0202] (2) After the data receiver receives the identity authentication challenge information X, the identity authentication challenge information X can be digitally signed by the digital signature private key, and the digitally signed identity authentication challenge information X is returned to the data holder;

[0203] (3) After the data holder receives the digitally signed identity authentication challenge information X, the digital signature public key of the data receiver is obtained to verify the above-mentioned digital signature; if the verification is successful, it is proved that the encryption public key obtained by the data holder is the encryption public key of the data receiver.

[0204] Based on the above, the following describes in detail the way in which the data holder encrypts the target data and creates a data authorization record Record in the embodiments of the present application in combination with actual scenarios:

[0205] (1) The data holder can first obtain the DID identifier of the data receiver from the blockchain; then, the DID identifier is uploaded to the DID digital identity registration and parsing interface to parse the DID identifier into the DID document of the data receiver, and the encryption public key of the data receiver is obtained therefrom.

[0206] (2) The data holder uses the encryption public key of the data receiver to encrypt the target data using an asymmetric encryption scheme to generate encrypted target data.

[0207] (3) The data holder creates a first data authorization record Record, which can include the ciphertext digest of the data holder, the validity period, the digital signature public key of the data receiver, and the like.

[0208] Among them, the first data authorization record Record created by the data holder is empty in the information of the decryption party (i.e., the data receiver), which needs to be updated by the data receiver subsequently. For example, the first data authorization record Record created by the data holder can include:

[0209] Record=[

[0210] Authorized decryption party: {0x001, after 20231006, MFYwEA...},

[0211] Actual decryption party: {null, null, null}

[0212] ]

[0213] wherein, "0x001" is the ciphertext digest in the first data authorization record Record of the data holder; "after 20231006" is the validity period in the first data authorization record Record of the data holder; "MFYwEA…" is the digital signature public key in the first data authorization record Record of the data holder, which is used by the receiver to verify the digital signature, i.e., the digital signature public key of the licensed object.

[0214] wherein, the authorized decryptor is the data holder; and the actual decryptor is the data receiver.

[0215] It should be noted that the information of the actual decryptor (i.e., the data receiver) in the data authorization record Record created by the data holder is empty and needs to be updated by the data receiver subsequently.

[0216] (4) In order to ensure that the first data authorization record Record is tamper-proof, in the embodiments of the present application, the data holder can also sign the first data authorization record Record based on the digital signature private key. For example, wherein, Evidence Sender represents the digital signature result of signing the first data authorization record Record based on the digital signature private key; represents the digital signature private key of the data holder.

[0217] (5) Then, the data holder can create a transaction on the blockchain and send (Evidence Sender , Record) as a transaction note to the blockchain.

[0218] After receiving the transaction note, the blockchain can verify the correctness of the digital signature through the smart contract of the blockchain. If the verification is incorrect, i.e., false = Verify(Evidence Sender , Record, ), the system exits. Otherwise, (Evidence Sender , Record) is saved to the blockchain.

[0219] (6) Finally, the data holder sends the encrypted target data to the data receiver.

[0220] By adopting the method provided in the embodiments of the present application, the data holder can send the encrypted target data to the data receiver, and upload the second identity information to the block chain to trigger the smart contract of the block chain to verify whether the second identity information and the first identity information match each other. The second identity information is the identity information of the licensed object licensed by the data holder to obtain the target data. The first identity information is the information provided by the data receiver of the encrypted target data to prove that the data receiver is the licensed object. In this way, the encrypted target data is decrypted only when and only when it is determined that the first identity information and the second identity information match each other, that is, when and only when it is determined that the identity information of the data receiver matches the identity information of the licensed object licensed by the data holder to obtain the target data, and thus the risk of data abuse in the medical data sharing process in the related art can be avoided, and the security of the target data in the data sharing process is ensured.

[0221] To solve the problem of data abuse in the medical data sharing process in the related art and the difficulty in ensuring the security of medical data, the embodiments of the present application provide a data sharing method, which is applied to an identity authentication module. Specifically, the implementation process of the method provided in the embodiments of the present application is shown in FIG. 3, which includes the following steps:

[0222] Step 31, generating an encryption key of the receiving holder or generating a decryption key of the data receiver.

[0223] The encryption key is used to encrypt the target data of the data holder to obtain the encrypted target data.

[0224] The decryption key is used to decrypt the encrypted target data received by the data receiver when the smart contract of the block chain verifies that the first identity information and the second identity information match each other.

[0225] The first identity information is the information provided by the data receiver of the encrypted target data to prove that the data receiver is the licensed object.

[0226] The second identity information is the identity information of the licensed object licensed by the data holder to obtain the target data.

[0227] In an optional implementation, the identity authentication module can include a Subscriber Identity Module (SIM card), also known as a mobile phone external chip or an external chip CHIP.

[0228] The specific implementation of generating the encryption key of the receiving holder or generating the decryption key of the data receiver based on the identity authentication module can refer to the related content of FIG. 1b in Embodiment 1, which will not be described here.

[0229] By adopting the method provided in the embodiments of the present application, the identity authentication module can generate an encryption key of the data receiving party or generate a decryption key of the data receiving party. The encryption key is used to encrypt the target data of the data holding party to obtain encrypted target data. The decryption key is used to decrypt the encrypted target data received by the data receiving party when the smart contract of the blockchain verifies that the first identity information and the second identity information match each other. The first identity information is information provided by the data receiving party of the encrypted target data and used to prove that the data receiving party is a licensed object. The second identity information is the identity information of the licensed object licensed by the data holding party to obtain the target data. In this way, when it is determined that the first identity information and the second identity information match each other, that is, when it is determined that the identity information of the data receiving party matches the identity information of the licensed object licensed by the data holding party to obtain the target data, the encrypted target data is decrypted again by taking the verification pass result of the blockchain as a target data decryption trigger condition, and thus the risk of data abuse in the medical data sharing process in the related art can be avoided, thereby ensuring the security of the target data in the data sharing process.

[0230] The following describes how the method provided in the embodiments of the present application is applied in practice in combination with an actual scenario.

[0231] For the convenience of description, before introducing an application process of the method provided in the embodiments of the present application in practice, the related entities involved in the embodiments of the present application are introduced.

[0232] Blockchain system: can be used as a trust infrastructure to manage data authorization and track the sharing process. It should be noted that the medical data in the present application is not on the chain.

[0233] Devices with external chips, such as mobile terminals with SIM cards: can be used as a client carrier for users to perform data processing, business handling, and other operations and data storage. At the same time, the external chip has an authentication module, a key generation module, and a key storage module, so that the entire terminal has the functions of authentication, digital signature, and encryption and decryption.

[0234] Medical data holder: can include medical patients, and each patient stores, records, and shares his / her own medical and medical record information through a device with an external chip. The medical data holder is the owner of the medical data.

[0235] Medical data receiver: can be composed of staff in medical institutions, including nurses, doctors, and business process management personnel, etc. The receiver processes medical business data through a device with an external chip, including receiving, auditing, and processing medical record information, etc.

[0236] Auditors: can be composed of government, audit department, medical management department and other institutions with audit function, mainly to supervise the medical data sharing process.

[0237] Please refer to FIG. 4, which is a schematic diagram of an application process of the method provided by the embodiment of the present application in practice, including the following steps:

[0238] (1) The medical data holder and the medical data receiver start their respective local application programs APP and external chips CHIP, respectively generate two pairs of public and private keys for signing and encryption and decryption, chain the two public keys, and store the two private keys in the external chips.

[0239] (2) The medical data holder and the medical data receiver call the authentication module to authenticate the phone number and the corresponding public key, generate a digital identity DID identifier and a supporting DID document through a Decentralized identifiers (DID) digital identity registration and analysis interface, and store them on the chain. The local designated application program or application receives the DID identifier.

[0240] (3) The medical data holder creates a smart contract Contract containing data authorization records Record through the blockchain, and sends the locally generated case information to the receiver after encrypting it using the receiver's encryption public key.

[0241] (4) The medical data receiver receives the ciphertext data C and calls the contract Contract to update the data authorization records Record, and after verification by the smart contract, sends the verified transaction TX and the updated Record to the external chip as proof.

[0242] (5) The medical data receiver's external chip decrypts the ciphertext C.

[0243] (6) After decryption, the auditors read the records TX on the blockchain and perform perceptual auditing based on the records.

[0244] It should be noted that the specific implementation of each of steps (1) to (6) has been described in detail in the previous embodiments 1 to 3, so the specific implementation of each of steps (1) to (6) can refer to the previous related content, and will not be repeated here.

[0245] With the method provided in the embodiments of the present application, after receiving the encrypted target data sent by the data holder, the data receiver can upload the first identity information to the blockchain; the first identity information is used to prove that the data receiver is a licensed object permitted by the data holder to obtain the target data; the blockchain stores the second identity information uploaded by the data holder; the second identity information is the identity information of a licensed object permitted by the data holder to obtain the target data; when the blockchain produces a verification pass result, based on the verification pass result, the identity authentication module is triggered to decrypt the encrypted target data. In this way, when the identity authentication module determines that the first identity information and the second identity information match each other, that is, when it is determined that the identity information of the data receiver matches the identity information of the licensed object permitted by the data holder to obtain the target data, the encrypted target data is decrypted again with the verification pass result produced by the blockchain as the target data decryption trigger condition, which can avoid the risk of data abuse in the medical data sharing process in the related art, thereby ensuring the security of the target data in the sharing process.

[0246] To solve the problem of data abuse in the medical data sharing process in the related art and the difficulty in ensuring the security of medical data, the embodiments of the present application provide a data sharing device, the specific structure diagram of which is shown in FIG. 5, which is applied to a data receiver and includes a data receiving module 51, an information uploading module 52, and a data decryption module 53, wherein:

[0247] The data receiving module 51 is configured to receive encrypted target data sent by a data holder.

[0248] The information uploading module 52 is configured to upload the first identity information to the blockchain; the first identity information is used to prove that the data receiver is a licensed object permitted by the data holder to obtain the target data; the blockchain stores the second identity information uploaded by the data holder; the second identity information is the identity information of a licensed object permitted by the data holder to obtain the target data.

[0249] The data decryption module 53 is configured to, when the blockchain produces a verification pass result, based on the verification pass result, trigger the identity authentication module to decrypt the encrypted target data; the identity authentication module is configured to decrypt the encrypted target data with the verification pass result produced by the blockchain as the target data decryption trigger condition.

[0250] The verification pass result represents that the verification result of the smart contract of the blockchain is that the first identity information and the second identity information match each other.

[0251] In an optional implementation, the first identity information comprises a first digital signature of the encrypted target data based on a digital signature private key of the data receiver; and the second identity information comprises a digital signature public key of the licensed object.

[0252] In an optional implementation, the apparatus further comprises:

[0253] a signature module, configured to sign the first digital signature based on the digital signature private key to obtain a second digital signature;

[0254] The information uploading module 52 is further configured to:

[0255] upload the second digital signature to the blockchain, so that the smart contract verifies whether the first identity information and the second identity information match each other based on verification of the second digital signature based on the digital signature public key of the licensed object.

[0256] The data receiving module 51, the information uploading module 52, the data decryption module 53, and the signature module perform the specific execution processes as described above, which are consistent with the method flow of Embodiment 1, and details are not described herein again.

[0257] With the apparatus provided in the embodiments of the present application, after receiving the encrypted target data sent by the data holder, the data receiver can upload the first identity information to the blockchain. The first identity information is used to prove that the data receiver is a licensed object licensed by the data holder to obtain target data. The blockchain stores the second identity information uploaded by the data holder. The second identity information is the identity information of the licensed object licensed by the data holder to obtain target data. When the blockchain produces a verification pass result, based on the verification pass result, the identity authentication module decrypts the encrypted target data. In this way, when it is determined that the first identity information and the second identity information match each other, that is, when it is determined that the identity information of the data receiver matches the identity information of the licensed object licensed by the data holder to obtain target data, the encrypted target data is decrypted based on the verification pass result produced by the blockchain as a target data decryption trigger condition. This can avoid the risk of data abuse in the medical data sharing process in the related art, thereby ensuring the security of the target data in the sharing process.

[0258] To solve the problem of data abuse in the medical data sharing process in the related art and the difficulty in ensuring the security of medical data, the embodiments of the present application provide a data sharing apparatus. The specific structure diagram of the apparatus is shown in FIG. 6, which is applied to a data holder and comprises a data sending module 61 and a second identity information uploading module 62.

[0259] The data sending module 61 is configured to send the encrypted target data to a data receiver.

[0260] The second identity information uploading module 62 is configured to upload the second identity information to a block chain to trigger a smart contract of the block chain to verify whether the first identity information and the second identity information match each other.

[0261] The second identity information is identity information of a licensed object permitted by the data holder to obtain the target data.

[0262] The first identity information is information provided by a data receiver of the encrypted target data to prove that the data receiver is the licensed object.

[0263] In an optional implementation, the apparatus further includes:

[0264] The encryption module is configured to:

[0265] Obtain a digital identity identifier of the data receiver.

[0266] Parse the digital identity identifier to obtain an encryption public key of the data receiver.

[0267] Encrypt the target data based on the encryption public key to obtain the encrypted target data.

[0268] The specific execution process of the data sending module 61, the second identity information uploading module 62, and the encryption module is consistent with the method flow in Embodiment 2, and reference can be made to the related description in Embodiment 2, which will not be described herein again.

[0269] By using the apparatus provided in the embodiments of the present application, the data holder can send the encrypted target data to the data receiver, and upload the second identity information to the block chain to trigger the smart contract of the block chain to verify whether the first identity information and the second identity information match each other. The second identity information is identity information of a licensed object permitted by the data holder to obtain the target data. The first identity information is information provided by a data receiver of the encrypted target data to prove that the data receiver is the licensed object. In this way, the encrypted target data is decrypted only when it is determined that the first identity information and the second identity information match each other, that is, when it is determined that the identity information of the data receiver matches the identity information of the licensed object permitted by the data holder to obtain the target data, and the verification pass result of the block chain is used as a decryption trigger condition of the target data. Thus, the risk of data abuse in the medical data sharing process in the related art can be avoided, and the security of the target data in the data sharing process is ensured.

[0270] To solve the problem of data misuse and other risks in the process of medical data sharing in the related art, and to ensure the security of medical data, the embodiment of the present application provides a data sharing device, the specific structure diagram of which is shown in Figure 7. The device is applied to an identity authentication module and includes a key generation module 71, wherein:

[0271] The key generation module 71 is configured to generate an encryption key of a receiving holder or generate a decryption key of a data receiver.

[0272] The encryption key is used to encrypt target data of a data holder to obtain encrypted target data.

[0273] The decryption key is used to decrypt encrypted target data received by the data receiver when the smart contract of the blockchain verifies that the first identity information and the second identity information match each other.

[0274] The first identity information is information provided by the data receiver of the encrypted target data to prove that the data receiver is a licensed object.

[0275] The second identity information is the identity information of a licensed object licensed by the data holder to obtain the target data.

[0276] The specific execution process of the key generation module 71 is consistent with the method flow in Embodiment 3, and reference can be made to the related description in Embodiment 3, which will not be described here.

[0277] The device provided in the embodiment of the present application can generate an encryption key of a receiving holder or generate a decryption key of a data receiver. The encryption key is used to encrypt target data of a data holder to obtain encrypted target data. The decryption key is used to decrypt encrypted target data received by the data receiver when the smart contract of the blockchain verifies that the first identity information and the second identity information match each other. The first identity information is information provided by the data receiver of the encrypted target data to prove that the data receiver is a licensed object. The second identity information is the identity information of a licensed object licensed by the data holder to obtain the target data. In this way, when it is determined that the first identity information and the second identity information match each other, that is, when it is determined that the identity information of the data receiver matches the identity information of the licensed object licensed by the data holder to obtain the target data, the encrypted target data is decrypted with the result of the blockchain verification as a target data decryption trigger condition, and thus the data misuse and other risks in the process of medical data sharing in the related art can be avoided, thereby ensuring the security of the target data in the process of data sharing.

[0278] Fig. 8 is a schematic diagram of a hardware structure of an electronic device implementing various embodiments of the present application. The electronic device 800 includes, but is not limited to, a radio frequency unit 801, a network module 802, an audio output unit 803, an input unit 804, a sensor 805, a display unit 806, a user input unit 807, an interface unit 808, a storage 809, a processor 810, and a power supply 811, etc. Those skilled in the art can understand that the electronic device structure shown in Fig. 8 does not constitute a limitation on the electronic device, and the electronic device can include more or fewer components than those shown, or combine certain components, or arrange different components. In embodiments of the present application, the electronic device includes, but is not limited to, a mobile phone, a tablet computer, a notebook computer, a palm computer, a vehicle terminal, a wearable device, and a pedometer, etc.

[0279] The processor 810 is configured to receive encrypted target data sent by a data holder, upload first identity information to a blockchain, and trigger a decryption module to decrypt the encrypted target data based on a verification pass result of the blockchain when the verification pass result is generated. The first identity information is used to prove that a data receiver is a licensed object permitted by the data holder to obtain the target data. The blockchain stores second identity information uploaded by the data holder. The second identity information is identity information of the licensed object permitted by the data holder to obtain the target data.

[0280] In an optional implementation, the first identity information includes a first digital signature of the encrypted target data based on a digital signature private key of the data receiver, and the second identity information includes a digital signature public key of the licensed object.

[0281] In an optional implementation, the processor 810 is further configured to:

[0282] sign the first digital signature based on the digital signature private key to obtain a second digital signature;

[0283] upload the second digital signature to the blockchain, so that the smart contract verifies whether the first identity information and the second identity information match each other based on a verification pass of the second digital signature based on the digital signature public key of the licensed object.

[0284] Alternatively, the processor 810 is further configured to send the encrypted target data to the data receiver.

[0285] uploading the second identity information to the blockchain to trigger the smart contract of the blockchain to verify whether the first identity information and the second identity information match each other;

[0286] The second identity information is identity information of a licensed object licensed by the data holder to obtain the target data.

[0287] The first identity information is information provided by a data receiver of the encrypted target data to prove that the data receiver is the licensed object.

[0288] In an optional implementation, before the encrypted target data is sent to the data receiver, the method further comprises:

[0289] Obtaining a digital identity identifier of the data receiver;

[0290] Parsing the digital identity identifier to obtain an encryption public key of the data receiver;

[0291] Encrypting the target data based on the encryption public key to obtain the encrypted target data.

[0292] Alternatively, the processor 810 is configured to generate an encryption key of the receiving holder or generate a decryption key of the data receiver;

[0293] The encryption key is used to encrypt the target data of the data holder to obtain the encrypted target data.

[0294] The decryption key is used to decrypt the encrypted target data received by the data receiver when the smart contract of the blockchain verifies that the first identity information and the second identity information match each other.

[0295] The first identity information is information provided by a data receiver of the encrypted target data to prove that the data receiver is the licensed object.

[0296] The second identity information is identity information of a licensed object licensed by the data holder to obtain the target data.

[0297] The memory 809 is configured to store a computer program executable on the processor 810, and the computer program is executed by the processor 810 to realize the above-mentioned functions realized by the processor 810.

[0298] It should be understood that in the embodiments of the present application, the radio frequency unit 801 can be configured to receive and send signals in the process of receiving or transmitting information or calls. Specifically, after receiving the downlink data from the base station, the radio frequency unit 801 processes the data for the processor 810. In addition, the radio frequency unit 801 sends the uplink data to the base station. Generally, the radio frequency unit 801 includes, but is not limited to, an antenna, at least one amplifier, a transceiver, a coupler, a low-noise amplifier, a duplexer, and the like. In addition, the radio frequency unit 801 can also communicate with the network and other devices through a wireless communication system.

[0299] The electronic device provides the user with wireless broadband Internet access through the network module 802, such as helping the user to send and receive emails, browse web pages, and access streaming media, and the like.

[0300] The audio output unit 803 can convert audio data received by the radio frequency unit 801 or the network module 802 or stored in the memory 809 into an audio signal and output as sound. Moreover, the audio output unit 803 can also provide audio output related to a specific function performed by the electronic device 800 (for example, a call signal reception sound, a message reception sound, and the like). The audio output unit 803 includes a speaker, a buzzer, a receiver, and the like.

[0301] The input unit 804 is configured to receive audio or video signals. The input unit 804 can include a graphics processor (GPU) 8041 and a microphone 8042. The graphics processor 8041 processes image data of a still picture or a video obtained by an image capture device (such as a camera) in a video capture mode or an image capture mode. The processed image frame can be displayed on the display unit 806. The image frame processed by the graphics processor 8041 can be stored in the memory 809 (or other storage medium) or transmitted via the radio frequency unit 801 or the network module 802. The microphone 8042 can receive sound and can process such sound into audio data. The processed audio data can be converted into a format that can be transmitted to a mobile communication base station via the radio frequency unit 801 in the case of a telephone call mode.

[0302] The electronic device 800 further includes at least one sensor 805, such as a light sensor, a motion sensor, and other sensors. Specifically, the light sensor includes an ambient light sensor and a proximity sensor, where the ambient light sensor can adjust the brightness of the display panel 8061 according to the brightness of ambient light, and the proximity sensor can turn off the display panel 8061 and / or the backlight when the electronic device 800 is moved to the ear. As one of the motion sensors, the accelerometer sensor can detect the magnitude of acceleration in each direction (generally three axes), the magnitude and direction of gravity when at rest, and can be configured to identify the posture of the electronic device (such as switching between landscape and portrait, related games, magnetometer posture calibration), vibration recognition related functions (such as pedometer, tapping), and the like. The sensor 805 can also include a fingerprint sensor, a pressure sensor, an iris sensor, a molecular sensor, a gyroscope, a barometer, a hygrometer, a thermometer, an infrared sensor, and the like, which will not be described here.

[0303] The display unit 806 is configured to display information input by a user or information provided to the user. The display unit 806 can include a display panel 8061, which can be configured in the form of a liquid crystal display (LCD), an organic light-emitting diode (OLED), or the like.

[0304] The user input unit 807 can be configured to receive input digital or character information, and to generate key signal inputs related to user settings and function control of the electronic device. Specifically, the user input unit 807 includes a touch panel 8071 and other input devices 8072. The touch panel 8071, also known as a touch screen, can collect touch operations of a user thereon or adjacent thereto (such as operations of a user using a finger, a stylus, or any suitable object or accessory on or adjacent to the touch panel 8071). The touch panel 8071 can include two parts, a touch detection device and a touch controller. The touch detection device detects the touch position of the user and detects signals caused by the touch operation, and transmits the signals to the touch controller; the touch controller receives touch information from the touch detection device, converts it into touch coordinates, and sends it to the processor 810, receives commands from the processor 810 and executes them. In addition, the touch panel 8071 can be implemented in various types such as resistive, capacitive, infrared, and surface acoustic wave. In addition to the touch panel 8071, the user input unit 807 can also include other input devices 8072. Specifically, the other input devices 8072 can include, but are not limited to, a physical keyboard, function keys (such as volume control buttons, on-off buttons, etc.), trackballs, mice, joysticks, and the like, which will not be described here.

[0305] Further, the touch panel 8071 can be overlaid on the display panel 8061, and when the touch panel 8071 detects a touch operation thereon or in the vicinity thereof, transmits the touch event to the processor 810 to determine the type of the touch event, and then the processor 810 provides corresponding visual output on the display panel 8061 according to the type of the touch event. Although in FIG. 8, the touch panel 8071 and the display panel 8061 are implemented as two independent components to realize the input and output functions of the electronic device, in some embodiments, the touch panel 8071 and the display panel 8061 can be integrated to realize the input and output functions of the electronic device, which is not limited here.

[0306] The interface unit 808 is an interface for connecting external devices to the electronic device 800. For example, the external devices can include a wired or wireless headset port, an external power supply (or battery charger) port, a wired or wireless data port, a memory card port, a port for connecting a device having an identification module, an audio input / output (I / O) port, a video I / O port, a headphone port, and the like. The interface unit 808 can be configured to receive input (e.g., data information, power, and the like) from the external devices and transmit the received input to one or more elements within the electronic device 800 or can be configured to transmit data between the electronic device 800 and the external devices.

[0307] The memory 809 can be configured to store software programs and various data. The memory 809 can include a storage program area and a storage data area, where the storage program area can store operating systems, application programs (such as sound play functions, image play functions, and the like) required by at least one function, and the like, and the storage data area can store data (such as audio data, phone books, and the like) created according to the use of the mobile phone, and the like. In addition, the memory 809 can include a high-speed random access memory, and can also include a non-volatile memory, such as at least one magnetic disk storage device, a flash memory device, or other volatile solid-state memory device.

[0308] The processor 810 is the control center of the electronic device, connects all parts of the electronic device through various interfaces and lines, executes various functions of the electronic device and processes data by running or executing software programs and / or modules stored in the memory 809 and calling data stored in the memory 809, and thus monitors the entire electronic device. The processor 810 can include one or more processing units; preferably, the processor 810 can integrate an application processor and a modem processor, where the application processor mainly processes operating systems, user interfaces, and application programs, and the modem processor mainly processes wireless communication. It can be understood that the above-mentioned modem processor can also not be integrated into the processor 810.

[0309] The electronic device 800 can further include a power supply 811 (such as a battery) that supplies power to the various components of the electronic device 800. The power supply 811 is preferably logically connected to the processor 810 through a power management system, which can enable functions such as managing charging, discharging, and power consumption management.

[0310] In addition, the electronic device 800 includes some functional modules that are not shown here and will not be described again.

[0311] Preferably, the embodiments of the present application further provide an electronic device, including a processor 810, a memory 809, and a computer program stored in the memory 809 and executable on the processor 810. The computer program is executed by the processor 810 to implement each process of the above-mentioned data sharing method embodiments and achieve the same technical effects. To avoid repetition, details are not described here.

[0312] The embodiments of the present application further provide a computer readable storage medium, which stores a computer program. The computer program is executed by a processor to implement each process of the above-mentioned data sharing method embodiments and achieve the same technical effects. To avoid repetition, details are not described here. The computer readable storage medium includes, for example, a Read-Only Memory (ROM), a Random Access Memory (RAM), a magnetic disk, or an optical disk.

[0313] Those skilled in the art should understand that the embodiments of the present application can be provided as a method, a system, or a computer program product. Therefore, the present application can be in the form of an entirely hardware embodiment, an entirely software embodiment, or an embodiment combining software and hardware aspects. Moreover, the present application can be in the form of a computer program product implemented on one or more computer-usable storage media (including, but not limited to, a disk memory, a CD-ROM, an optical memory, etc.) containing computer-usable program code.

[0314] The present application is described with reference to the flowcharts and / or block diagrams of the methods, devices (systems), and computer program products according to the embodiments of the present application. It should be understood that each flow and / or block in the flowcharts and / or block diagrams, as well as combinations of flows and / or blocks in the flowcharts and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a general-purpose computer, a special-purpose computer, an embedded processor, or other programmable data processing devices to produce a machine, so that the instructions executed by the processor of the computer or other programmable data processing devices produce the functions specified in one or more flows in the flowcharts and / or one or more blocks in the block diagrams.

[0315] These computer program instructions can also be stored in a computer- readable memory that can direct a computer or other programmable data processing apparatus to function in a particular manner, such that the instructions stored in the computer-readable memory produce an article of manufacture including instructions which implement the function specified in the flowchart or flowsheets and / or block or blocks of the block diagrams.

[0316] These computer program instructions can also be loaded onto a computer or other programmable data processing apparatus to cause a series of operational steps to be performed on the computer or other programmable apparatus to produce a computer implemented process such that the instructions which execute on the computer or other programmable apparatus provide steps for implementing the functions specified in the flowchart or flowsheets and / or block or blocks of the block diagrams.

[0317] In one typical configuration, the computing device includes one or more processors (CPUs), input / output interfaces, network interfaces, and memory.

[0318] The memory can include non-persistent memory and / or volatile memory, such as random access memory (RAM) and / or cache memory, non-volatile memory, such as read-only memory (ROM), EPROM, and / or flash memory, etc. The memory is an example of computer readable media.

[0319] Computer readable media includes permanent and non-permanent, removable and non-removable media implemented in any method or technology for storage of information such as computer readable instructions, data structures, program modules or other data. Examples of computer storage media include, but are not limited to, phase change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technology, compact disc read-only memory (CD-ROM), digital versatile discs (DVDs) or other optical storage, magnetic cassettes, magnetic tapes, magnetic disk storage or other magnetic storage devices, or any other non-transmission medium that can be configured to store information accessible to a computing device. According to the definition herein, computer readable media does not include transitory media, such as modulated data signals and carrier waves.

[0320] It is also to be noted that the terms "comprising", "including", or any other variations thereof, are intended to cover a non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements does not include only those elements but can also include other elements not expressly listed or inherent to such process, method, article, or apparatus. An element proceeded by "comprises a... " does not, without more constraints, exclude the presence of additional identical elements in the process, method, article, or apparatus that comprises the element.

[0321] The above description is merely illustrative of the application, and not restrictive. Various modifications and changes can become apparent to those skilled in the art. Incorporating any modification, equivalent substitution, improvement, etc. within the spirit and principle of the application, shall be included in the scope of the claims of the application.

Claims

1. A data sharing method applied to a data receiver, the method comprising: receiving encrypted target data sent by a data holder; uploading first identity information to a blockchain; the first identity information being used to prove that the data receiver is a permitted object permitted by the data holder to obtain target data; the blockchain storing second identity information uploaded by the data holder; the second identity information being identity information of a permitted object permitted by the data holder to obtain target data; after the blockchain generates a verification pass result, triggering an identity authentication module to decrypt the encrypted target data based on the verification pass result; the identity authentication module being configured to decrypt the encrypted target data with the verification pass result generated by the blockchain as a target data decryption trigger condition; the verification pass result representing that the first identity information and the second identity information are verified by a smart contract of the blockchain and the verification result is that the first identity information and the second identity information match each other. 2.The method of claim 1, wherein: the first identity information comprises a first digital signature of the encrypted target data based on a digital signature private key of the data receiver; the second identity information comprises a digital signature public key of the permitted object.

3. The method of claim 2, wherein, The method further comprises: signing the first digital signature based on the digital signature private key to obtain a second digital signature; uploading the second digital signature to the blockchain so that the smart contract verifies whether the first identity information and the second identity information match each other based on verification of the second digital signature by the digital signature public key of the permitted object. 4.A data sharing method applied to a data holder, the method comprising: sending encrypted target data to a data receiver; uploading second identity information to a blockchain to trigger a smart contract of the blockchain to verify whether the second identity information and first identity information match each other; the second identity information being identity information of a permitted object permitted by the data holder to obtain target data; the first identity information being information provided by a data receiver of the encrypted target data to prove that the data receiver is the permitted object.

5. The method of claim 4, wherein, Before the sending of the encrypted target data to the data receiver, the method further comprises: obtaining a digital identity identifier of the data receiver; parsing the digital identity identifier to obtain an encryption public key of the data receiver; encrypting the target data based on the encryption public key to obtain the encrypted target data. 6.A data sharing method applied to an identity authentication module, the method comprising: generating an encryption key of a data receiver or generating a decryption key of a data receiver; the encryption key being used to encrypt target data of the data holder to obtain encrypted target data; the decryption key being used to decrypt the encrypted target data received by the data receiver when a smart contract of a blockchain verifies that first identity information and second identity information match each other. The first identity information is information provided by the data receiver of the encrypted target data to prove that the data receiver is a permitted object; The second identity information is identity information of the permitted object permitted by the data holder to obtain target data. 7.A data sharing apparatus applied to a data receiver, comprising a data receiving module, an information uploading module and a data decryption module, wherein: The data receiving module is configured to receive encrypted target data sent by a data holder; The information uploading module is configured to upload first identity information to a blockchain; the first identity information is used to prove that the data receiver is a permitted object permitted by the data holder to obtain target data; the blockchain stores second identity information uploaded by the data holder; the second identity information is identity information of the permitted object permitted by the data holder to obtain target data; The data decryption module is configured to, when the blockchain produces a verification pass result, trigger an identity authentication module to decrypt the encrypted target data based on the verification pass result; the identity authentication module is configured to decrypt the encrypted target data with the verification pass result produced by the blockchain as a target data decryption trigger condition; The verification pass result represents that the first identity information and the second identity information are matched with each other via smart contract verification of the blockchain.

8. An electronic device comprising: A memory, a processor and a computer program stored on the memory and executable on the processor, the computer program being executed by the processor to implement the steps of the data sharing method according to any one of claims 1 to 6. 9.A computer readable storage medium, the computer readable storage medium storing a computer program, the computer program being executed by a processor to implement the steps of the data sharing method according to any one of claims 1 to 6. 10.A computer program product, comprising a computer program, the computer program being executed by a processor to implement the data sharing method according to any one of claims 1 to 6.

Images