Data requesting, verifying and sending method and device

Abstract

The invention provides a data requesting, verifying and sending method and device, and the method comprises the steps: receiving a data demand sent by a data receiving node DR, the data demand at least comprises verification content and the data description of request data, and the verification content is generated based on a DID technology; verifying the verification content; and in response to verification passing, establishing a request item in the block chain demand list based on the verification content, the data description of the request data and the demand time. By adopting the DID technology, the identity decentralization of the user is realized, the user can autonomously create and manage the identity, the method is suitable for the situation that two transaction parties do not share a trusted identity authentication mechanism in a cross-domain environment, and meanwhile, the security of data transmission can be greatly improved by providing a node for a contract to authenticate the authentication content.

Description

Technical Field

[0001] The present disclosure relates to the technical field of data sharing, and in particular to a method and device for requesting, verifying and sending data. Background Art

[0002] Blockchain technology is a distributed ledger technology. Blockchain is composed of a series of blocks, each of which contains a certain number of transaction records. These records are linked together after being processed by the encrypted hash algorithm to form an unalterable chain.

[0003] Identity verification is required during the process of uploading data to the chain. When uploading batches of data to the chain, huge computing power is required to support batch verification, but the computing power of blockchain nodes is limited, and efficient batch verification cannot be achieved in some cases. Summary of the invention

[0004] The present disclosure aims to solve one of the technical problems in the related art at least to some extent.

[0005] To this end, an object of the present disclosure is to propose a data request method suitable for a contract providing node.

[0006] The second objective of the present disclosure is to propose a data request method applicable to a data receiving node DR.

[0007] The third objective of the present disclosure is to propose a data request method applicable to a data providing node DP.

[0008] A fourth objective of the present disclosure is to provide a data verification method suitable for ISP.

[0009] The fifth objective of the present disclosure is to propose a data sending method suitable for DR.

[0010] The sixth objective of the present disclosure is to propose a sending method suitable for a contract providing node.

[0011] The seventh objective of the present disclosure is to propose a data request device suitable for a contract providing node.

[0012] The eighth objective of the present disclosure is to provide a data request device suitable for a data receiving node DR.

[0013] The ninth objective of the present disclosure is to provide a data requesting device suitable for a data providing node DP.

[0014] A tenth objective of the present disclosure is to provide a data verification device suitable for an ISP.

[0015] An eleventh objective of the present disclosure is to provide a data sending device suitable for DR.

[0016] A twelfth objective of the present disclosure is to provide an electronic device.

[0017] The thirteenth object of the present disclosure is to provide a non-transitory computer-readable storage medium.

[0018] The fourteenth objective of the present disclosure is to provide a computer program product.

[0019] To achieve the above-mentioned purpose, the first aspect of the present disclosure proposes a data request method, which is applicable to a contract providing node, including: receiving a data demand sent by a data receiving node DR, the data demand including at least a verifiable expression and a DR signature, the verifiable expression is determined based on a first verification credential generated by an identity providing node ISP, the first verification credential and the DR signature are determined by the ISP based on a first attribute set and a DR identity of the data receiving node DR; verifying the verifiable expression, the DR signature and the first verification credential; in response to the verifiable expression, the DR signature and the first verification credential all being verified, establishing a request item in a blockchain demand list based on the first verification credential and the demand time.

[0020] To achieve the above-mentioned purpose, the second aspect of the present disclosure proposes a data request method, which is applicable to a data receiving node DR, including: receiving a first verification credential sent by an identity providing node ISP, wherein the first verification credential includes a DR signature, and the first verification credential and the DR signature are generated by the ISP based on a first attribute set of the DR and a DR identity identifier; determining a DR verifiable expression based on the first verification credential and the DR signature; generating a data demand based on the DR verifiable expression, a data description of the requested data, the DR signature and the address of a contract providing node; and sending the data demand to the contract providing node.

[0021] To achieve the above-mentioned purpose, the third aspect of the present disclosure proposes a data request method, which is applicable to a data providing node DP, including: obtaining a request item in an identity identification list, wherein the request item is generated by the ISP in the identity identification list based on a first verification credential; verifying the request item based on a third attribute set of the DP; in response to the verification being passed, encrypting the request data based on a DP private key to generate encrypted request data; sending the encrypted request data to a communication node, and receiving a data link corresponding to the encrypted request data fed back by the communication node; constructing a second target transaction based on the data link, and sending it to a contract providing node

[0022] To achieve the above-mentioned purpose, the fourth aspect of the present disclosure proposes a data verification method, which is applicable to an ISP, including: verifying a target attribute set and a target identity of a target end sent by the target end, wherein the target end is one of a DP or a DR; in response to passing the verification, generating a target signature based on the attribute set of the target end and the identity of the target end; generating a target verification credential corresponding to the target end based on the identity of the target end, the attribute set of the target end, the target signature and the target ISP identity of the ISP; and sending the target verification credential to the target end.

[0023] To achieve the above-mentioned purpose, the fifth aspect of the present disclosure proposes a data sending method, which is applicable to DR, including: obtaining a third shared record in the node list provided by the blockchain contract; downloading the corresponding encrypted request data from the storage space of the communication node based on the data link in the third shared record; decrypting the encrypted request data to obtain the decrypted request data.

[0024] To achieve the above-mentioned purpose, the sixth aspect of the present disclosure proposes a data sending method, which is applicable to a contract providing node, including: receiving completion feedback sent by a DR; verifying the completion feedback; and confirming the completion of data transmission in response to successful verification.

[0025] To achieve the above-mentioned purpose, the seventh aspect embodiment of the present disclosure proposes a data request device, which is suitable for a contract providing node, and the device includes: a first receiving module, used to receive a data demand sent by a data receiving node DR, the data demand at least including a verifiable expression and a DR signature, the verifiable expression is determined based on a first verification credential generated by an identity providing node ISP, the first verification credential and the DR signature are determined by the ISP based on a first attribute set and a DR identity of the data receiving node DR; a first judgment module, used to make a legality judgment on the verifiable expression and the DR signature; a first determination module, used to determine whether the ISP identity and the DR identity exist in a blockchain identity list in response to the legality judgment being passed; a second judgment module, used to determine whether the first verification credential is legal in response to the ISP identity and the DR identity being in the blockchain identity list; an establishment module, used to establish a request item in the blockchain demand list based on the first verification credential and the demand time in response to the first verification credential being legal.

[0026] To achieve the above-mentioned purpose, an eighth aspect embodiment of the present disclosure proposes a data request device, which is applicable to a data receiving node DR, and the device includes: a second receiving module, used to receive a first verification credential sent by an identity providing node ISP, wherein the first verification credential includes a DR signature, and the first verification credential and the DR signature are generated by the ISP based on a first attribute set of the DR and a DR identity identifier; a first determination module, used to determine a DR verifiable expression based on the first verification credential and the DR signature; a first generation module, used to generate data requirements based on the DR verifiable expression, a data description of the requested data, the DR signature and the address of the contract providing node; and a first sending module, used to send the data requirements to the contract providing node.

[0027] To achieve the above-mentioned purpose, the ninth aspect embodiment of the present disclosure proposes a data request device, which is suitable for a data providing node DP, and the device includes: a first acquisition module, used to obtain a request item in an identity identification list, and the request item is generated by the ISP in the identity identification list based on a first verification credential; a first verification module, used to verify the request item based on a third attribute set of the DP; an encryption module, used to encrypt the request data based on the DP private key in response to the verification passing to generate encrypted request data; a second sending module, used to send the encrypted request data to a communication node, and receive a data link corresponding to the encrypted request data fed back by the communication node; a third sending module, used to construct a second target transaction based on the data link, and send it to the contract providing node.

[0028] To achieve the above-mentioned purpose, the tenth aspect embodiment of the present disclosure proposes a data verification device, which is suitable for an ISP, and the device includes: a third receiving module, used to verify the target attribute set of the target end and the target identity of the target end sent by the target end, wherein the target end is one of the DP or the DR; a second generating module, used to generate a target signature based on the attribute set of the target end and the identity of the target end in response to the verification being passed; a third generating module, used to generate a target verification credential corresponding to the target end based on the identity of the target end, the attribute set of the target end, the target signature and the target ISP identity of the ISP; and a fourth sending module, used to send the target verification credential to the target end.

[0029] To achieve the above-mentioned purpose, the eleventh embodiment of the present disclosure proposes a data sending device, which is suitable for DR, and the device includes: a second acquisition module, used to obtain a third shared record in the node list provided by the blockchain contract; a download module, used to download the corresponding encrypted request data from the storage space of the communication node based on the data link in the third shared record; a decryption module, used to decrypt the encrypted request data to obtain the decrypted request data.

[0030] To achieve the above-mentioned purpose, the twelfth aspect embodiment of the present disclosure proposes an electronic device, comprising: at least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores instructions executable by the at least one processor, and the instructions are executed by the at least one processor to implement the data request method as described in the first aspect embodiment, the second aspect embodiment, and the third aspect embodiment of the present disclosure, or the data verification method as described in the fourth aspect embodiment, or the data sending method as described in the fifth aspect embodiment and the sixth aspect embodiment.

[0031] To achieve the above-mentioned purpose, the thirteenth aspect embodiment of the present disclosure proposes a non-transitory computer-readable storage medium storing computer instructions, wherein the computer instructions are used to implement the data request method as described in the first aspect embodiment, the second aspect embodiment, and the third aspect embodiment of the present disclosure, or the data verification method as described in the fourth aspect embodiment, or the data sending method as described in the fifth aspect embodiment and the sixth aspect embodiment.

[0032] To achieve the above-mentioned purpose, the fourteenth embodiment of the present disclosure proposes a computer program product, including a computer program, which, when executed by a processor, is used to implement the data request method as described in the first, second, and third embodiments of the present disclosure, or the data verification method as described in the fourth embodiment, or the data sending method as described in the fifth and sixth embodiments.

[0033] By adopting DID technology, user identities can be decentralized and created and managed independently by users. It is suitable for scenarios where the two parties to a transaction do not have a shared trusted identity authentication agency in a cross-domain environment. At the same time, by providing nodes for contracts to verify the legitimacy of each role, the security of data transmission can be greatly improved. BRIEF DESCRIPTION OF THE DRAWINGS

[0034] Figure 1 is a schematic diagram of a data request method according to an embodiment of the present disclosure, which is applicable to a contract providing node;

[0035] Figure 2 is a schematic diagram of another data request method according to an embodiment of the present disclosure, which is applicable to a contract providing node;

[0036] Figure 3 is a schematic diagram of a data request method according to an embodiment of the present disclosure, which is applicable to a data receiving node DR;

[0037] Figure 4 It is a schematic diagram of another data request method according to an embodiment of the present disclosure;.

[0038] Figure 5 is a schematic diagram of a data request method according to an embodiment of the present disclosure, applicable to a data providing node DP;

[0039] Figure 6 is a schematic diagram of a data verification method according to an embodiment of the present disclosure, which is applicable to ISPs;

[0040] Figure 7 is a schematic diagram of a data sending method according to an embodiment of the present disclosure, which is applicable to DR;

[0041] Figure 8 is a schematic diagram of a data sending method according to an embodiment of the present disclosure, which is applicable to a contract providing node;

[0042] Fig. 9 is a schematic diagram of a data request device according to an embodiment of the present disclosure, which is applicable to a contract providing node;

[0043] Fig.10 is a schematic diagram of a data requesting device according to an embodiment of the present disclosure, which is applicable to a data receiving node DR;

[0044] Fig.11 is a schematic diagram of a data requesting device according to an embodiment of the present disclosure, applicable to a data providing node DP;

[0045] Fig.12 is a schematic diagram of a data verification device according to one embodiment of the present disclosure, which is applicable to ISP;

[0046] Fig.13 is a schematic diagram of a data sending device according to an embodiment of the present disclosure, which is applicable to DR;

[0047] Fig.14 is a schematic diagram of a data sending device according to an embodiment of the present disclosure, which is applicable to a contract providing node;

[0048] Fig.15 is a schematic diagram of an electronic device according to an embodiment of the present disclosure. DETAILED DESCRIPTION

[0049] Embodiments of the present disclosure are described in detail below, examples of which are shown in the accompanying drawings, wherein the same or similar reference numerals throughout represent the same or similar elements or elements having the same or similar functions. The embodiments described below with reference to the accompanying drawings are exemplary and are intended to be used to explain the present disclosure, and should not be construed as limiting the present disclosure.

[0050] The acquisition, storage, use, and processing of data in the technical solution disclosed in this disclosure are in compliance with the relevant provisions of relevant laws and regulations.

[0051] It should be noted that in the embodiments of the present application, certain software, components, models and other existing solutions in the industry may be mentioned, and they should be considered as exemplary. Their purpose is only to illustrate the feasibility of implementing the technical solution of the present application, but it does not mean that the applicant has or will necessarily use the solution.

[0052] Figure 1 is a schematic diagram of a data request method according to an embodiment of the present disclosure, which is applicable to a contract providing node, such as Figure 1 As shown, the data request method includes the following steps:

[0053] S101, receiving data requirements sent by a data receiving node DR, where the data requirements at least include verification content and a data description of the requested data, and the verification content is generated based on the decentralized identifier DID technology.

[0054] The data request method of the embodiment of the present application can be applicable to the scenario of data application in the Internet environment of the communication node. The executor of the data request of the embodiment of the present application can be the data request device of the embodiment of the present application, and the data request device can be set on an electronic device.

[0055] It should be noted that the communication node e ) refers to a device or facility used to transmit, receive or process information in a network. Communication nodes can be divided into various types, and the communication nodes in the embodiments of the present disclosure are not limited. For example, the communication nodes in the embodiments of the present disclosure can be communication satellites, base stations, distributed antenna systems, etc.

[0056] It should be noted that the contract providing node ShareC in the disclosed solution is used to provide functional functions, which may include multiple functions, including but not limited to adding did (add), publishing requirements (need), requesting sharing (req), responding to sharing (order), providing data (offer), confirming sharing (complete), timeout without providing data arbitration (arbitrate_timeout), etc. order ), provide error data arbitration Data does not meet the arbitration requirements Timeout for unconfirmed shared arbitration (arbitrate_time offered ).

[0057] ShareC is also used to maintain the blockchain identity list DidList, the blockchain demand list NeedList, and the blockchain contract provided node list SharingList, where DidList stores the DIDs of system participants, NeedList records the data requirements of data receiving nodes, and SharingList is used to record data sharing status.

[0058] It should be noted that a data receiving node (DR) is an entity that receives data according to its actual purpose. Each data receiving node DR publishes its data needs through the data sharing system. For example, a DR can be a terminal, an electronic computer, etc.

[0059] Identity Service Provider (ISP): An ISP is an off-chain entity trusted by the data receiving node DR and the data providing node DP, and issues a verifiable credential (VC) for identity authentication to the data receiving node DR and the data providing node DP.

[0060] Data Provider (DP). DP is an entity that holds data and can generate data based on various IoT devices. Each data provider DP discovers data needs through this system and issues sharing requests. For example, DP can be a data acquisition device, sensor, etc.

[0061] The verification credential may include a variety of information, which is not limited here. For example, the verification credential may include the identity of the DR, the identity of the DP, and the identity of the ISP, etc., to prove the legality of the identities of the DP, the DR, and the ISP.

[0062] It should be noted that the verification credentials in the embodiments of the present disclosure are globally unique identifiers encoded using Uniform Resource Names (URN). A decentralized identifier (DID) is used to represent the digital identity of an entity. It does not rely on a central issuer (identity provider node) to create and control it, but is created and managed by the identity owner. The DID is associated with a DID document in JSON-LD format that contains information about the DID, including the public key, authentication protocol, and available service endpoints.

[0063] DID does not rely on centralized authorities to manage and verify identifiers. Users have full control over their DIDs. Users can decide the life cycle of DIDs by themselves. They can also achieve compatibility between different systems so that they can be used on different platforms or systems. At the same time, the principle of minimum information disclosure is taken into account when designing to protect user privacy. Encryption technology is used to ensure the security and immutability of DIDs.

[0064] S102, verifying the verification content.

[0065] In the disclosed embodiment, after the data demand is obtained, the verifiable expression, DR signature and the first verification credential are verified, that is, the legitimacy of the DR and the ISP is verified to prevent the occurrence of erroneous requests or illegal requests.

[0066] S103, in response to the verification being passed, establishing a request item in the blockchain requirement list based on the verification content, the data description of the requested data, and the requirement time.

[0067] It should be noted that the demand time is the effective time. During the demand time, the currently established request items are effective demand items. The demand time is designed in advance and can be changed according to actual design needs. There is no limitation here.

[0068] In one possible implementation, you can add

[0069]

[0070] To NeedList, where For the required data Description, time need Indicates the need id In time need Valid until expiration, id is need id A unique identifier for That is, id is a The integer after H2 hash calculation. VP DR For a verifiable expression, ξ DR Indicates the type of DR.

[0071] In the embodiment of the present disclosure, a data demand sent by a data receiving node DR is received, and the data demand includes at least verification content and a data description of the requested data, and the verification content is generated based on the DID technology. Then, the verification content is verified, and in response to the verification passing, a request item is established in the blockchain demand list based on the verification content, the data description of the requested data, and the demand time. In the present disclosure, by adopting the DID technology, the user's identity is decentralized, and can be created and managed independently by the user. It is suitable for scenarios where the two parties to the transaction in a cross-domain environment do not have a common trusted identity authentication agency. At the same time, by verifying the verification content of the contract providing node, the security of data transmission can be greatly improved.

[0072] In the above embodiment, the verification content includes a verifiable expression and a DR signature. The verifiable expression is determined based on a first verification credential generated by an identity providing node ISP. The first verification credential and the DR signature are determined by the ISP based on a first attribute set and a DR identity of a data receiving node DR. The DR identity is generated based on a decentralized identifier DID technology. The verification content is verified, and the verifiable expression, the DR signature and the first verification credential are verified. Figure 2 Explaining further, the method includes:

[0073] S201, judging the legitimacy of the verifiable expression and DR signature.

[0074] It should be noted that the first attribute set is a set of attributes of the DR, and each element in the set represents an attribute of the DR. For example, the attribute may be age, address, etc.

[0075] In the embodiment of the present disclosure, the legitimacy of the verifiable expression and the DR signature can be judged by a verification algorithm. The verification algorithm can be various and is not limited here.

[0076] In one possible implementation, the verification algorithm may be:

[0077] 1=Veri(did DR , VP DR .body, VP DR .σ DR )

[0078] Among them, did DR DR identity, VP DR .body is the subject of the verifiable expression, VP DR .σ DR Sign for DR.

[0079] If the above formula is true, it is determined that the verifiable expression and DR signature are legal. If not, the data request is stopped.

[0080] S202, in response to the legitimacy judgment being passed, determining whether the ISP identity and the DR identity exist in the blockchain identity list, wherein the ISP identity is generated based on the DID technology.

[0081] In the disclosed embodiment, it is possible to determine whether VP DR .VC DR .did ISP , VP DR .VC DR .did DR Whether it is in DidList, that is, whether the user is a trusted user who has been on the chain. If not, stop this data request.

[0082] Among them, VP DR For verifiable expression, VC DR Is the first verification credential, did ISP Is the ISP's identity, did DR The ID of the DR.

[0083] S203, in response to the ISP identity and the DR identity being in the blockchain identity list, determining whether the first verification credential is legal.

[0084] In the embodiment of the present disclosure, the first verification credential may be verified by a verification algorithm to determine whether the first verification credential is legitimate. The verification algorithm may be of various types and is not limited here. In one possible implementation, the verification algorithm may be as shown in the following algorithm:

[0085] Judgment 1 = Veri(VP DR .VC DR .did ISP , VP DR .VC DR .body, VP DR .VC DR .σ ISP ), the calculation formula is to determine the VP provided by the user DR The first verification certificate VC included DR Is it legal? If not, stop this data request.

[0086] In the disclosed embodiment, the legitimacy of the verifiable expression and the DR signature is first judged, and in response to the legitimacy judgment being passed, it is determined whether the ISP identity and the DR identity exist in the blockchain identity list, and in response to the ISP identity and the DR identity existing in the blockchain identity list, it is judged whether the first verification credential is legal. Thus, by performing identity authentication on the DR and the ISP respectively, and verifying the legitimacy of the first verification credential, the security of data transmission at the request stage can be guaranteed.

[0087] In the above embodiment, after receiving the request item, DP will establish a second target transaction. After receiving the second target transaction fed back by DP based on the request item, the contract providing node will verify based on the second target transaction. In response to the verification being passed, a first shared record will be established in the blockchain contract providing node list, wherein the first shared record is valid before the required time. This step is the process of DP establishing a transaction on the DP side after receiving the data request from DR and verifying the identity of DR.

[0088] In the embodiment of the present disclosure, the process of verification based on the second target transaction may be as follows:

[0089] ShareC executes the req function to issue a transaction request:

[0090] Judgment 1 = Veri(VP DP .VC DP .did DP , VP DP .body,VP DP .σ DP ), if not, stop this data request.

[0091] Judging VP DP .VC DP .did ISP , VP DP .VC DP .did DP Is it in DidList? If not, stop this data request.

[0092] Determine need id .ξ DR =VP DP .VC DP .{P1, ..., P l}, if not true, stop this data request.

[0093] Judgment 1 = Veri(VP DP .VC DP .did ISP , VP DP .VCDP .body, VP DP .VC DP .σ ISP ), if not, stop this data request.

[0094] Verify whether the current time is less than need id .time need If the verification fails, stop the data request, otherwise continue with the following steps.

[0095] Add to

[0096]

[0097] To SharingList, where time need Indicates that the shared record was at time req Valid until expiration, id is sharing id The unique identifier is equal to tx = {σ, addr Sharee ,(id,url,VP DP )}. represents the ciphertext of the key, Indicates that the ciphertext of the key is empty. In this case, the ciphertext of the key is not provided.

[0098] Among them, VP DP is a verifiable expression of DP, VC DP For the second verification credential, did DP is the identity of DP, σ DP is the signature of DP, {P1, ..., P l} is the attribute set of DP, url is the link corresponding to the request data, It is the status of the requested data. Requested means the status of the requested data is requested.

[0099] In another embodiment of the present disclosure, the contract providing node is further used to receive the first target transaction generated by the DR based on the first shared record, and then verify based on the first target transaction, and in response to successful verification, establish a second shared record in the blockchain contract providing node list, wherein the second shared record is valid before the required time. In this step,

[0100] In the embodiment of the present disclosure, based on the first target transaction, verification is performed, and in response to successful verification, a process of establishing a second shared record in the blockchain contract providing node list may be as follows:

[0101] ShareController r function:

[0102] Judgment 1 = Veri(VP DR .VC DR .did DR , VP DR .body,VP DR .σ DR ), if not, stop this data request.

[0103] Judging VP DR .VC DR .did ISP , VP DR .VC DR .did DR Is it in DidList? If not, stop this data request.

[0104] Judgment 1 = Veri(VP DR .VC DR .did ISP , VP DR .VC DR .body, VP DR .VC DR ·σ ISP ) If it is not true, stop this data request.

[0105] judge If not, output ⊥, i∈[1,n].

[0106] judge If not, stop the data request. Otherwise, continue to execute the following steps, i∈[1,n].

[0107] set up

[0108]

[0109] in express In time order Valid until expiration. represents the ciphertext of the key, Indicates that the ciphertext of the key is empty. In this case, the ciphertext of the key is not provided.

[0110] Among them, σ ISP Signature for ISP, VP DR For verifiable expression, VC DR Is the first verification credential, did ISP Is the ISP's identity, did DR is the DR's identity, url is the link corresponding to the requested data, The state of the requested data, ordered means that the state of the requested data is approved. This step is the process of establishing a transaction on the DR side after DR receives the first target transaction established by DP and verifies the identity of DP.

[0111] In the disclosed embodiment, the contract providing node is also used to receive the second target transaction sent by DP, and then verify the second target transaction. In response to successful verification, a third shared record is established in the blockchain contract providing node list based on the data link corresponding to the DP private key and the encrypted request data in the second target transaction. This step is that after DP receives the second target transaction established by DR, DP establishes a third shared record with the DP private key and the encrypted request data, so as to provide it to DR for data download according to the data link, and decrypts the downloaded data through the DP private key.

[0112] In the disclosed embodiment, the third shared record is established in the blockchain contract providing node list based on the data link corresponding to the DP private key and the encrypted request data in the second target transaction as follows:

[0113] ShareC executes r function:

[0114] Judgment 1 = Veri(VP DP .VC DP .did DP , VP DP .body,VP DP .σ DP ), if not, the arbitration shall be terminated.

[0115] Judging VP DP .VC DP .did ISP , VP DP .VC DP .did DP Is it in DidList? If not, stop arbitration.

[0116] Find shared records sharing id , satisfy sharing id .did DP =VP DP .VC DP .did DP .

[0117] Judgment 1 = Veri(VP DP .VC DP .did ISP , VP DP .VC DP .body, VPDP .VC DP .σ ISP ), if not, the arbitration shall be terminated.

[0118] Verify whether the current time is less than sharing id .time order If the verification fails, output ⊥, otherwise continue to execute the following steps.

[0119] judge If not, output ⊥, otherwise continue to execute the following steps.

[0120] set up

[0121]

[0122] Among them sharing id .time offered Indicates sharing id In time offered It is valid until expiration. The DP ciphertext will be shared to the node list provided by the blockchain contract.

[0123] Figure 3 is a schematic diagram of a data request method according to an embodiment of the present disclosure, which is applicable to a data receiving node DR, such as Figure 3 As shown, the data request method includes the following steps:

[0124] S301, receiving a first verification credential sent by an identity providing node ISP, wherein the first verification credential includes a DR signature, and the first verification credential and the DR signature are generated by the ISP based on a first attribute set of the DR and a DR identity.

[0125] It should be noted that the first verification credential is a credential generated by the ISP for proving the identity of the DR.

[0126] S302, determining a DR verifiable expression based on the first verification credential and the DR signature.

[0127] DR calculates and stores the verifiable expression VP DR A verifiable expression is a descriptive statement issued by a user to endorse certain attributes of another user, and appended with his own digital signature. Here, VP DR Contains the verifiable certificate VC obtained above and issued by a trusted ISP DR , and digitally sign it, as shown below

[0128] VP DR = {VC DR , σDR}

[0129] Among them, VC DR is the first verification credential, σ DR Sign for DR.

[0130] Among them, σ DR =Sign(sk DR , VP DR .body),

[0131] VP DR .body={VC DR}.

[0132] S303, generate data requirements based on the DR verifiable expression, data description of the requested data, DR signature and the address of the contract providing node.

[0133] In the embodiment of the present disclosure, the data requirements may be generated as follows:

[0134] Call the need function of the transaction contract ShareC, where For the required data Description, σ is the digital signature, addr ShareC is the address of ShareC.

[0135] S304, sending the data requirement to the contract providing node.

[0136] In the disclosed embodiment, the first verification credential sent by the identity providing node ISP is first received, wherein the first verification credential includes a DR signature, and the first verification credential and the DR signature are generated by the ISP based on the first attribute set of the DR and the DR identity, and then the DR verifiable expression is determined based on the first verification credential and the DR signature, and then the data demand is generated based on the DR verifiable expression, the data description of the requested data, the DR signature and the address of the contract providing node, and finally the data demand is sent to the contract providing node. Therefore, by introducing the identity authentication mechanism and blockchain technology to improve the security and credibility of the data demand processing process, the efficiency of identity authentication can be improved.

[0137] In one embodiment of the present disclosure, the first verification credential sent by the identity providing node ISP is received, and the first verification credential sent by the identity providing node ISP is received. Figure 4 Explaining further, the method includes:

[0138] S401, obtaining a second attribute set and a first identity identifier of the DR, wherein the first identity identifier is generated based on the DID technology.

[0139] In the disclosed embodiment, in addition to sending the second attribute set and the first identity identifier, the DR may also send relevant credentials, which may be information such as an ID card, passport, driver's license, etc. This may be set according to actual design needs, thereby increasing the verification dimension and improving the security of data interaction.

[0140] S402: Send the second attribute set and the first identity identifier to the ISP for verification.

[0141] ISP Verification and the correctness of relevant credentials (such as ID card, passport, driver's license, etc.). If the verification fails, it means that the current DR and the DR that has been chained in the ISP are not the same DR, and the step is terminated.

[0142] S403, the ISP generates a first verification credential and a DR signature after the verification is successful.

[0143] ISP calculates verifiable credentials, which are used to verify the identity of users participating in data sharing

[0144] VC DR ={did ISP , did DR , (R1,…,R l ), σ ISP},

[0145] Among them, σ ISP =Sign(sk ISP , VC DR .body) is the ISP to VC DR .body digital signature, VC DR .body={did ISP , did DR , (R1,…,R l )}.

[0146] Among them, VC DR is the first verification credential, σ ISP Signed for DR, did ISP Is the ISP identity, did DR is the DR identity, (R1, ..., R l ) is the second attribute set, σ ISP Sign for ISP.

[0147] In the disclosed embodiment, the second attribute set and the first identity of the DR are first obtained, wherein the first identity is generated based on the DID technology, and then the second attribute set and the first identity are sent to the ISP for verification, and finally the ISP generates the first verification credential and the DR signature after the verification is passed. Thus, by comparing the second attribute set with the first attribute set that has been put on the chain, it is determined whether the current DR and the DR that has been put on the chain are the same DR.

[0148] In the embodiment of the present disclosure, before determining the DR verifiable expression based on the first verification credential and the DR signature, the first verification credential fed back by the ISP based on the first attribute set and the first identity identifier can be first received, and then the first verification credential can be decrypted based on the DR's private key to generate a first verification plaintext, and the DR's second identity identifier, the ISP's third identity identifier, and the second attribute set are obtained from the first verification plaintext, wherein the second identity identifier and the third identity identifier are generated based on the DID technology, and finally verification is performed based on the verification plaintext DR's second identity identifier, the ISP's third identity identifier, the second attribute set, and the DR signature, and the verification passes.

[0149] In the embodiment of the present disclosure, verification is performed based on the second identity identifier of the plaintext DR, the third identity identifier of the ISP, the second attribute set and the DR signature. The second identity identifier, the third identity identifier, the second attribute set and the DR signature can be first calculated based on a preset verification algorithm. In response to the calculation result being the same as the verification success result, the verification is successful; or in response to the calculation result being different from the verification success result, the verification fails and the DR's data request is terminated.

[0150] In the embodiment of the present disclosure, the second identity identifier, the third identity identifier, the second attribute set and the DR signature are calculated based on a preset verification algorithm as follows:

[0151] DR computes the plaintext of the verifiable credential

[0152] Then judge 1 = Veri (VC ' DR .did ISP , VC′ DR .body,VC′ DR .σ ISP ), if the verification fails, the step is terminated, otherwise VC′ is stored locally DR .

[0153] Among them, s DR It is the private key of DR.

[0154] In the disclosed embodiment, after sending the data demand to the contract providing node, the DR can verify the request item after sending the data demand to the contract providing node, and in response to successful verification, construct the first target transaction and send it to the contract providing node. The specific implementation steps can refer to the content in the above embodiment, which will not be repeated here.

[0155] Figure 5 is a schematic diagram of a data request method according to an embodiment of the present disclosure, which is applicable to a data providing node DP, such as Figure 5 As shown, the data request method includes the following steps:

[0156] S501, obtaining a request item in an identity identification list, where the request item is generated by the ISP in the identity identification list based on a first verification credential.

[0157] It should be noted that the generation of request items may refer to the contents in the above embodiments, which will not be repeated here.

[0158] S502: Verify the request item based on the third attribute set of DP.

[0159] In the disclosed embodiment, DP may determine ξ DP =need id .VP DR .VC DR .{R1, ..., R l}, that is, to determine the identity attribute set {R1, ..., R l} whether it satisfies the specified receiver type ξ DP ,If the verification fails, DP aborts and does not perform any ,operation.

[0160] S503: In response to the verification being successful, encrypt the request data based on the DP private key to generate encrypted request data.

[0161] In the disclosed embodiment, DP may select a private key Calculate the ciphertext of the data to be shared That is, Q is the ciphertext of the data to be shared. A group element obtained by H1 hash calculation. It should be noted that That is, DR selects a random private key from the entire cycle of q.

[0162] DP chooses secret value And calculate r = H2 (k·G, k·Q), s = ((1 + sk DP ) -1·kr·skDPmodq, wherein k, r, s are all integers, k·G represents a group element obtained by scalar multiplication of the integer k and the generator G, and k·Q represents a group element obtained by scalar multiplication of the integer k and the group element Q.

[0163] DP calculation V = sk DP Q, v = H3(V), proof = (V, A, B, s), where A = k·G, B = k·Q, where V, A, B are group elements after corresponding scalar multiplication, v is an integer, and proof is a proof set containing group elements V, A, B and integer s.

[0164] DP calculation V = sk DP Q, v = H3(V), proof = (V, A, B, s), where A = k·G, B = k·Q, where V, A, B are group elements after corresponding scalar multiplication, v is an integer, and proof is a proof set containing group elements V, A, B and integer s.

[0165] S504, sending the encrypted request data to the communication node, and receiving the data link corresponding to the encrypted request data fed back by the communication node.

[0166] S505, construct a second target transaction based on the data link and send it to the contract providing node.

[0167] After obtaining the data link fed back by the communication node, DP calculates VP DP = {VC DP , σ DP}, where σ DP =Sign(sk DP , VP DP .body), VP DP .body={VC DP}.

[0168] Among them, VP DP is a verifiable expression of DP, VC DP is the second verification certificate of DP, σ DP Signature for DP, VP DP .body is the main body of the DP verifiable expression.

[0169] Building a second target transaction based on the data link can be as follows:

[0170] tx={σ,addr ShareC ,(id,url,VP DP )}

[0171] Among them, tx is the second target transaction.

[0172] In the disclosed embodiment, before obtaining the request item in the identity list, the request item in the identity list can be obtained first, the request item is generated by the ISP in the identity list based on the first verification credential, and then the request item is verified based on the third attribute set of the DP. The DP can first obtain the request item in the identity list, the request item is generated by the ISP in the identity list based on the first verification credential, and then the request item is verified based on the third attribute set of the DP. In response to the verification passing, the request data is encrypted based on the DP private key to generate encrypted request data, and then the encrypted request data is sent to the communication node, and the data link corresponding to the encrypted request data fed back by the communication node is received, and finally the second target transaction is constructed based on the data link and sent to the contract providing node. Thus, after receiving the request item, the request item is verified, and after the verification is successful, the second target transaction is established to send information that can be verified to the DR, and the data link containing the request data is used for the subsequent DR to perform further authentication based on the data link, so as to improve the security of data transmission.

[0173] DP computes the plaintext of the verifiable credential

[0174] DP judgment 1 = Veri (VC ' DP .did ISP , VC′ DP .body,VC′ DP .σ ISP ), if the verification fails, the step is terminated, otherwise VC′ is stored locally DP .

[0175] Among them, sk DP is the private key of DP, VC′ DP is the second verification plaintext, It is the second verification credential.

[0176] In the disclosed embodiment, DP also constructs a third target transaction based on the DP private key and sends it to the contract providing node, which is used to share the private key ciphertext with DR to decrypt the downloaded request data.

[0177] Figure 6 is a schematic diagram of a data request method according to an embodiment of the present disclosure, which is applicable to ISPs, such as Figure 6 As shown, the data request method includes the following steps:

[0178] S601, verifying a target attribute set and a target identity of the target end sent by the target end, wherein the target end is one of the DP and the DR, and wherein the target identity is generated based on the DID technology.

[0179] It should be noted that the target end in the embodiment of the present disclosure is DP or DR.

[0180] S602, in response to verification being passed, generating a target signature based on the attribute set of the target end and the identity of the target end, wherein the target end is DR and the target verification credential is the first verification credential, or the target end is DP and the target verification credential is the second verification credential.

[0181] In the embodiment of the present disclosure, a target signature is generated based on the attribute set of the target end and the identity of the target end. First, the ISP private key of the ISP can be obtained, and then the DR signature is generated based on the ISP private key for the identity of the target end, the attribute set of the target end and the target ISP identity of the ISP.

[0182] S603, generating a target verification credential corresponding to the target end based on the data description of the request data, the identity of the target end, the attribute set of the target end, the target signature and the target ISP identity of the ISP.

[0183] It should be noted that the generation of the target signature and the target verification credential may refer to the contents in the above embodiments, which will not be repeated here.

[0184] In response to the target end being DR, the target authentication credential is the first authentication credential, or in response to the target end being DP, the target authentication credential is the second authentication credential.

[0185] S604, sending the target verification credential to the target end.

[0186] In the disclosed embodiment, the target attribute set and the target identity of the target sent by the target are first verified, wherein the target is one of DP or DR, wherein the target identity is generated based on DID technology, and in response to the verification being passed, a target signature is generated based on the attribute set and the identity of the target, and then a target verification credential corresponding to the target is generated based on the data description of the request data, the identity of the target, the attribute set of the target, the target signature and the target ISP identity of the ISP, and finally the target verification credential is sent to the target. This identity authentication process based on DID technology can effectively improve the security, credibility and privacy protection level of the system, while simplifying the process of identity management and verification, promoting interoperability between different platforms, and enhancing the overall trust of the system through transparency and traceability.

[0187] It should be noted that, in order to improve the security of data transmission, the identity of the target end and the target verification credential may be encrypted before the target verification credential is sent to the target end.

[0188] In one embodiment of the present disclosure, the ISP is also used to add the target end's identity to the blockchain identity list, as shown below:

[0189] ISP constructs and sends transaction tx = {σ, addr ShareC , add, (did DR )}, call the add function of the Share contract to do DR Add it to the blockchain DidList to realize the user identity on the chain, and the identity on the chain is considered credible.

[0190] In one embodiment of the present disclosure, the ISP is also used to receive a third target transaction sent by the DP, and then verify the third target transaction. In response to successful verification, a third shared record is established in the blockchain contract providing node list based on the data link corresponding to the DP private key and encrypted request data in the third target transaction.

[0191] It should be noted that the process of establishing the third shared record may refer to the contents in the above embodiment, which will not be described in detail here.

[0192] Figure 7 is a schematic diagram of a data sending method according to an embodiment of the present disclosure, which is applicable to DR, such as Figure 7 As shown, the data sending method includes the following steps:

[0193] S701, obtain the third shared record in the node list provided by the blockchain contract.

[0194] It should be noted that the process of establishing the third shared record may refer to the contents in the above embodiment and will not be described in detail here.

[0195] S702: Download corresponding encrypted request data from the storage space of the communication node based on the data link in the third shared record.

[0196] S703: decrypt the encrypted request data to obtain decrypted request data.

[0197] DR Acquisition Perform decryption calculation to obtain the plaintext of the key.

[0198]

[0199] DR is obtained by downloading from sharingid.url

[0200] DR performs decryption calculations to obtain the plaintext of the data

[0201] In the disclosed embodiment, the third shared record in the node list provided by the blockchain contract is first obtained, and then the corresponding encrypted request data is downloaded from the storage space of the communication node based on the data link in the third shared record, and finally the encrypted request data is decrypted to obtain the decrypted request data. Thus, by using the Internet communication technology of the communication node to realize the forwarding of the data to be shared, a stable and reliable data sharing service is provided for sparsely populated areas, offshore oil exploration, and cross-domain environments such as ships and aircraft.

[0202] In one possible implementation, if there are n sharingid sharing request records with the same id in SharingList, that is, And the current time satisfies i∈[1, n], that is, the current time is within the validity period of the corresponding shared record, and DR performs the following operations:

[0203] Step 1: DR pass Download i∈[1,n], that is, a total of i∈[1,n].

[0204] Step 2: DR determines v for all i∈[1,n] i =H3(V i ) is established, if not, terminate.

[0205] Step 3: DR calculates the group element Q for all i∈[1,n] i =H1(m i ).

[0206] Step 4: DR calculates the integer r for all i∈[1,n] i =H2(A i , B i ).

[0207] Step 5: DR selects 2 integers for all i∈[1,n]

[0208] Steps 1 to 5 are preprocessing operations for batch verification of this scheme to obtain the required input parameters for batch verification.

[0209] Step 6: DR calculation If true, return 1; otherwise, return 0. This step aggregates multiple proof set proof verification equations into one decision equation, thereby achieving batch verification of multiple proofs and improving verification efficiency.

[0210] tx={σ,addr ShareC,order,(id,VP DR )}, call the order function of the ShareC contract.

[0211] In the disclosed embodiment, after obtaining the decrypted request number, the DR may also generate completion feedback and send it to the contract providing node.

[0212] DR constructs and sends transaction tx = {σ, addr ShareC ,complete,(id,did DP , VP DR )}, call the ShareC contract complete function.

[0213] Figure 8 A schematic diagram of a data transmission method according to an embodiment of the present disclosure is applicable to a contract providing node, such as Figure 8 The data sending method comprises the following steps:

[0214] S801, receiving completion feedback sent by DR.

[0215] S802, verifying the completion feedback.

[0216] S803, in response to successful verification, confirming completion of data transmission.

[0217] In the disclosed embodiment, ShareC executes the complete function:

[0218] Judgment 1 = Veri(VP DR .VC DR .did DR , VP DR .body,VP DR .σ DR ), if not, the transmission is confirmed to be abnormal. This step is used to determine whether the first verification credential of the DR is correct.

[0219] Judging VP DR .VC DR .did ISP , VP DR .VC DR .did DR Is it in DidList? If not, the transmission is confirmed to be abnormal. This step is used to determine whether the DR is on the chain.

[0220] Judgment 1 = Veri(VP DR .VC DR .did ISP , VP DR .VC DR .body,VPDR .VC DR .σ ISP ) If it is not true, the transmission is confirmed to be abnormal.

[0221] Find transaction records sharingi d , meet sharingi d .did DP =did DP This step is used to determine whether the DP identity in the node list provided by the blockchain contract is the same as the corresponding DP identity.

[0222] Judgment sharingi d .did DR =VP DR .VC DR .did DR , if not established, the transmission is confirmed to be abnormal.

[0223] judge If not, the transmission is confirmed to be abnormal, otherwise continue to perform the following steps.

[0224] Verify whether the current time is less than sharing id .time offered , if the verification fails, the transmission is confirmed to be abnormal, otherwise continue to perform the following steps.

[0225] set up Data sharing between DR and DP is completed.

[0226] In the disclosed embodiment, the completion feedback sent by the DR is first received, and then the completion feedback is verified. In response to successful verification, the completion of data transmission is confirmed. Through this completion feedback mechanism, the success rate of data transmission can be improved, and the effectiveness and security of data transmission can be guaranteed.

[0227] In the embodiment of the present disclosure, when data sharing is abnormal, transaction arbitration is required for this data transmission. It should be noted that transaction arbitration is performed by an arbitrator, arbitrator (Ar). r It is an off-chain entity trusted by the data receiving node DR and the data providing node DP. If a dispute occurs between DR and DP during the data sharing process, Ar will participate in off-chain arbitration to resolve the dispute.

[0228] Transaction arbitration may include many types, which are not limited here. In one possible implementation, transaction arbitration may include:

[0229] Arbitration 1: In one embodiment of the present disclosure, when the current time exceeds time order ,and That is, if the DP fails to provide data within the specified time, the DR initiates arbitration. The execution steps are as follows:

[0230] Step 1: DR constructs and sends a transaction

[0231] tx={σ,addr ShareC , arbitrate_time order ,(id,did DP , VP DR )}Call ShareC contract arbitrate_time order function.

[0232] Step 2: ShareC contract executes arbitrate_time order function:

[0233] Judgment 1 = Veri(VP DR .VC DR .did DR , VP DR .body,VP DR .σ DR ), if not, the arbitration shall be terminated.

[0234] Judging VP DR .VC DR .did ISP , VP DR .VC DR .did DR Is it in DidList? If not, stop arbitration.

[0235] Judgment 1 = Veri(VP DR .VC DR .did ISP , VP DR .VC DR .body, VP DR .VC DR .σ ISP ) If it is not established, the arbitration shall be terminated.

[0236] Find shared records sharing id , satisfy sharing id .did DP =did DP .

[0237] Judgment sharing id .did DR =VP DR .did DR, if not established, the arbitration shall be terminated.

[0238] Get the current time

[0239] judge: Follow these steps:

[0240] If true, delete the did in the Did List DP , and set End of arbitration

[0241] If not, delete the did in the Did List DR , and set The arbitration is over.

[0242] Arbitration 2: DP provided error DR (Calculated To initiate arbitration, the execution steps are as follows:

[0243] Step 1: DR constructs and sends a transaction

[0244] Calling ShareC contract function.

[0245] Step 2: ShareC contract execution function:

[0246] Judgment 1 = Veri(VP DR .VC DR .did DR , VP DR .body,VP DR .σ DR ), if not, the arbitration shall be terminated.

[0247] Judge V DR .VC DR .did ISP , VP DR .VC DR .did DR Is it in DidList? If not, stop arbitration.

[0248] Judgment 1 = Veri(VP DR .VC DR .did ISP , VP DR .VC DR .body, VP DR .VC DR ·σ ISP) If it is not established, the arbitration shall be terminated.

[0249] Find shared records sharingi d , meet sharingi d .did DP =did DP .

[0250] Judgment sharing id .did DR =VP DR .did DR , if not established, the arbitration shall be terminated.

[0251] judge If not true, delete the did in DidList DR , and set The arbitration is over, otherwise continue with the following steps.

[0252] By sharing id .VP DP .url download

[0253] calculate Follow these steps:

[0254] If it is possible to calculate Delete the did in DidList DR , and set The arbitration is over.

[0255] If you cannot calculate Delete the did in DidList DP , and set The arbitration is over.

[0256] Arbitration 3: Not Compliant That is, the data provided by DP Does not meet DR requirements, DR (calculated ) initiates arbitration, and the execution steps are as follows:

[0257] Step 1: DR constructs and sends a transaction:

[0258] Ararb indicates a request for Ar arbitration.

[0259] Step 2: Ar judgment sharing id Satisfy sharing id.did DP =did DP , perform the following steps:

[0260] If so, proceed to step 3.

[0261] If not, construct and send the transaction Calling ShareC contract Function, delete the did in Did List DR , and set The arbitration is over.

[0262] Step 3: Ar calculation

[0263] Step 4: Ar judgment Compliance Follow these steps:

[0264] If true, construct and send the transaction Calling ShareC contract Function, delete the did in Did List DR , and set The arbitration is over.

[0265] If not, construct and send the transaction Calling ShareC contract Function, delete the did in DidList DP , and set The arbitration is over.

[0266] Arbitration 4: Current time exceeds time offered ,and That is, DR times out and fails to confirm. DP initiates arbitration. The execution steps are as follows:

[0267] Step 1: DP builds and sends a transaction

[0268] tx={σ,addr ShareC , arbitrate_time offered ,(id,VP DP )}Call ShareC contract arbitrate_time offered function.

[0269] Step 2: ShareC contract executes arbitrate_time offered function:

[0270] Judgment 1 = Veri(VP DP .VC DP .did DP, VP DP .body,VP DP .σ DP ), if not, the arbitration shall be terminated.

[0271] Judging VP DP .VC DP .did ISP , VP DP .VC DP .did DP Is it in DidList? If not, stop arbitration.

[0272] Find transaction records sharing id , satisfy sharing id .did DP =VP DP .VC DP .did DP .

[0273] Judgment 1 = Veri(VP DP .VC DP .did ISP , VP DP .VC DP .body, VP DP .VC DP .σ ISP ), if not, the arbitration shall be terminated.

[0274] Get the current time

[0275] judge:

[0276] Follow these steps:

[0277] If not, delete the did in the Did List DR , and set The arbitration is over.

[0278] If true, delete the did in DidList DP , and set The arbitration is over.

[0279] Fig. 9 An interaction diagram of nodes is provided for the disclosed DR, DP, communication nodes, ISP and contracts, such as Fig. 9As shown, ISP is used to issue verifiable credentials for identity authentication to the data receiving node DR and the data providing node DP, the contract providing node ShareC is used to provide functional functions, DR is the entity that receives data according to its actual purpose, and DP is the entity that holds data and can generate data based on various IoT devices. ISP is an off-chain entity trusted by the data receiving node DR and the data providing node DP, and issues verifiable credentials (VC) for identity authentication to the data receiving node DR and the data providing node DP. Ar is an off-chain entity trusted by the data receiving node DR and the data providing node DP. If a dispute occurs between DR and DP during the data sharing process, Ar will participate in off-chain arbitration to resolve the dispute. The communication node network is a communication network composed of multiple communication nodes, which can support communication between ground users participating in data sharing, and is used to forward data held by DP to DR.

[0280] Corresponding to the methods provided in the above-mentioned embodiments, an embodiment of the present disclosure also provides a corresponding device. Since the device provided in the embodiment of the present disclosure corresponds to the methods provided in the above-mentioned embodiments, the implementation methods of the above-mentioned methods are also applicable to the device provided in the embodiment of the present disclosure and will not be described in detail in the following embodiments.

[0281] Fig.10 is a schematic diagram of a data request device according to an embodiment of the present disclosure, which is applicable to a contract providing node, such as Fig.10 As shown, the data request device 1000 includes: a first receiving module 1010, a judging module 1020, and a establishing module 1030.

[0282] Among them, the first receiving module 1010 is used to receive the data demand sent by the data receiving node DR, and the data demand at least includes the verification content and the data description of the requested data, and the verification content is generated based on the decentralized identifier DID technology.

[0283] The judgment module 1020 is used to verify the verification content.

[0284] The establishment module 1030 is used to establish a request item in the blockchain requirement list based on the verification content, the data description of the requested data and the required time in response to the verification being passed.

[0285] In the present disclosure, the user's identity is decentralized by adopting DID technology, which can be created and managed independently by the user. It is suitable for scenarios where the two parties to a transaction do not have a shared trusted identity authentication agency in a cross-domain environment. At the same time, by verifying the legitimacy of the verification content through the contract providing node, the security of data transmission can be greatly improved.

[0286] Fig.11is a schematic diagram of a data request device according to an embodiment of the present disclosure, which is applicable to DR, such as Fig.11 As shown, the data requesting device 1100 includes: a second receiving module 1110 , a first determining module 1120 , a first generating module 1130 , and a first sending module 1140 .

[0287] The second receiving module 1110 is used to receive a first verification credential sent by the identity providing node ISP, wherein the first verification credential includes a DR signature, and the first verification credential and the DR signature are generated by the ISP based on a first attribute set of the DR and a DR identity.

[0288] The first determination module 1120 is used to determine a DR verifiable expression based on the first verification credential and the DR signature.

[0289] The first generation module 1130 is used to generate data requirements based on the DR verifiable expression, the data description of the requested data, the DR signature and the address of the contract providing node.

[0290] The first sending module 1140 is used to send the data requirement to the contract providing node.

[0291] Therefore, by introducing identity authentication mechanisms and blockchain technology to improve the security and credibility of the data demand processing process, the efficiency of identity authentication can be improved.

[0292] Fig.12 is a schematic diagram of a data request device according to an embodiment of the present disclosure, which is applicable to DP, such as Fig.12 As shown, the data requesting device 1200 includes: a first obtaining module 1210 , a first verifying module 1220 , an encryption module 1230 , a second sending module 1240 and a third sending module 1250 .

[0293] The first acquisition module 1210 is used to acquire a request item in the identity identification list, where the request item is generated by the ISP in the identity identification list based on the first verification credential.

[0294] The first verification module 1220 is used to verify the request item based on the third attribute set of the DP.

[0295] The encryption module 1230 is used to encrypt the request data based on the DP private key in response to the verification being passed to generate encrypted request data.

[0296] The second sending module 1240 is used to send the encrypted request data to the communication node, and receive the data link corresponding to the encrypted request data fed back by the communication node.

[0297] The third sending module 1250 is used to construct a second target transaction based on the data link and send it to the contract providing node.

[0298] Therefore, after receiving the request item, the request item is verified. After the verification is successful, a second target transaction is established to send information that can be verified to the DR, and a data link containing the request data is used for subsequent DR to perform further authentication based on the data link, thereby improving the security of data transmission.

[0299] Fig.13 Schematic diagram of a data verification device according to an embodiment of the present disclosure, which is applicable to ISPs, such as Fig.13 As shown, the data verification device 1300 includes: a third receiving module 1310 , a second generating module 1330 , a third generating module 1340 , and a fourth sending module 1340 .

[0300] Among them, the third receiving module 1310 is used to verify the target attribute set and the target identity of the target end sent by the target end, wherein the target end is one of DP or DR, and wherein the target identity is generated based on DID technology.

[0301] The second generation module 1330 is used to generate a target signature based on the attribute set of the target end and the identity of the target end in response to the verification being passed, wherein the target end is DR and the target verification credential is the first verification credential, or the target end is DP and the target verification credential is the second verification credential.

[0302] The third generating module 1340 is used to generate a target verification credential corresponding to the target end based on the data description of the request data, the identity of the target end, the attribute set of the target end, the target signature and the target ISP identity of the ISP.

[0303] The fourth sending module 1340 is used to send the target verification credential to the target end.

[0304] This identity authentication process based on DID technology can effectively improve the security, credibility and privacy protection of the system, while simplifying the identity management and verification process, promoting interoperability between different platforms, and enhancing the overall trust of the system through transparency and traceability.

[0305] Fig.14 is a schematic diagram of a data sending device according to an embodiment of the present disclosure, which is applicable to DR, such as Fig.14 As shown, the data sending device 1400 includes: a second acquisition module 1410 , a download module 1420 , and a decryption module 1430 .

[0306] The second acquisition module 1410 is used to obtain a third shared record in the node list provided by the blockchain contract.

[0307] The download module 1420 is used to download the corresponding encrypted request data from the storage space of the communication node based on the data link in the third shared record.

[0308] The decryption module 1430 is used to decrypt the encrypted request data to obtain decrypted request data.

[0309] Therefore, by using the Internet communication technology of communication nodes to forward the data to be shared, a stable and reliable data sharing service is provided for sparsely populated areas, offshore oil exploration, and cross-domain environments such as ships and aircraft.

[0310] In order to implement the above embodiment, the present disclosure further provides an electronic device 1500, Fig.15 is a schematic diagram of an electronic device according to an embodiment of the present disclosure, such as Fig.15 As shown, the electronic device 1500 includes: a processor 1501 and a memory 1502 connected to the processor in communication, the memory 1502 stores instructions that can be executed by at least one processor, and the instructions are executed by at least one processor 1501 to implement the present disclosure. Figure 1-Figure 9 Method of embodiment.

[0311] In order to implement the above embodiments, the present disclosure also provides a non-transitory computer-readable storage medium storing computer instructions, wherein the computer instructions are used to enable the computer to implement the above embodiments. Figure 1-Figure 9 Method of embodiment.

[0312] In order to implement the above embodiments, the present disclosure also provides a computer program product, including a computer program. When the computer program is executed by a processor, the computer program implements the above embodiments. Figure 1-Figure 9 Method of embodiment.

[0313] It should be noted that personal information from users should be collected for legitimate and reasonable purposes and should not be shared or sold outside of these legitimate uses. In addition, such collection / sharing should be carried out after receiving the user's informed consent, including but not limited to notifying the user to read the user agreement / user notice and sign the agreement / authorization including authorization of relevant user information before the user uses the function. In addition, any necessary steps should be taken to protect and safeguard access to such personal information data and ensure that others who have access to personal information data comply with its privacy policy and procedures.

[0314] The present application is expected to provide an implementation scheme for users to selectively block the use or access of personal information data. That is, the present disclosure is expected to provide hardware and / or software to prevent or block access to such personal information data. Once the personal information data is no longer needed, the risk can be minimized by limiting data collection and deleting the data. In addition, when applicable, such personal information is de-identified to protect the privacy of the user.

[0315] In the description of the aforementioned embodiments, the description with reference to the terms "one embodiment", "some embodiments", "example", "specific example", or "some examples" etc. means that the specific features, structures, materials or characteristics described in conjunction with the embodiment or example are included in at least one embodiment or example of the present application. In this specification, the schematic representations of the above terms do not necessarily refer to the same embodiment or example. Moreover, the specific features, structures, materials or characteristics described may be combined in any one or more embodiments or examples in a suitable manner. In addition, those skilled in the art may combine and combine the different embodiments or examples described in this specification and the features of the different embodiments or examples, without contradiction.

[0316] In addition, the terms "first" and "second" are used for descriptive purposes only and should not be understood as indicating or implying relative importance or implicitly indicating the number of the indicated technical features. Therefore, the features defined as "first" and "second" may explicitly or implicitly include at least one of the features. In the description of this application, the meaning of "plurality" is at least two, such as two, three, etc., unless otherwise clearly and specifically defined.

[0317] Any process or method description in a flowchart or otherwise described herein may be understood to represent a module, fragment or portion of code comprising one or more executable instructions for implementing the steps of a custom logical function or process, and the scope of the preferred embodiments of the present application includes alternative implementations in which functions may not be performed in the order shown or discussed, including performing functions in a substantially simultaneous manner or in the reverse order depending on the functions involved, which should be understood by technicians in the technical field to which the embodiments of the present application belong.

[0318] The logic and / or steps represented in the flowchart or otherwise described herein, for example, can be considered as an ordered list of executable instructions for implementing logical functions, and can be embodied in any computer-readable medium for use by an instruction execution system, device or apparatus (such as a computer-based system, a system including a processor, or other system that can fetch instructions from an instruction execution system, device or apparatus and execute instructions), or in combination with these instruction execution systems, devices or apparatuses. For the purpose of this specification, "computer-readable medium" can be any device that contains, stores, communicates, propagates or transmits a program for use by an instruction execution system, device or apparatus, or in combination with these instruction execution systems, devices or apparatuses. More specific examples (non-exhaustive list) of computer-readable media include the following: an electrical connection with one or more wires (electronic device), a portable computer disk box (magnetic device), a random access memory (RAM), a read-only memory (ROM), an erasable and programmable read-only memory (EPROM or flash memory), a fiber optic device, and a portable compact disk read-only memory (CDROM). In addition, the computer-readable medium may even be paper or other suitable medium on which the program is printed, since the program may be obtained electronically, for example, by optically scanning the paper or other medium and then editing, interpreting or processing in other suitable ways if necessary, and then stored in a computer memory.

[0319] It should be understood that the various parts of the present application can be implemented by hardware, software, firmware or a combination thereof. In the above-mentioned embodiments, multiple steps or methods can be implemented by software or firmware stored in a memory and executed by a suitable instruction execution system. For example, if implemented by hardware, as in another embodiment, it can be implemented by any one of the following technologies known in the art or their combination: a discrete logic circuit having a logic gate circuit for implementing a logic function for a data signal, a dedicated integrated circuit having a suitable combination of logic gate circuits, a programmable gate array (PGA), a field programmable gate array (FPGA), etc.

[0320] A person skilled in the art may understand that all or part of the steps in the method for implementing the above-mentioned embodiment may be completed by instructing related hardware through a program, and the program may be stored in a computer-readable storage medium, which, when executed, includes one or a combination of the steps of the method embodiment.

[0321] In addition, each functional unit in each embodiment of the present application may be integrated into a processing module, or each unit may exist physically separately, or two or more units may be integrated into one module. The above-mentioned integrated module may be implemented in the form of hardware or in the form of a software functional module. If the integrated module is implemented in the form of a software functional module and sold or used as an independent product, it may also be stored in a computer-readable storage medium.

[0322] The storage medium mentioned above may be a read-only memory, a magnetic disk or an optical disk, etc. Although the embodiments of the present application have been shown and described above, it can be understood that the above embodiments are exemplary and cannot be understood as limiting the present application. A person of ordinary skill in the art may change, modify, replace and modify the above embodiments within the scope of the present application.

Claims

1. A data request method, characterized in that: Applicable to a contract providing node, the method comprises: Receive a data demand sent by a data receiving node DR, wherein the data demand includes at least verification content and a data description of the requested data, and the verification content is generated based on the decentralized identifier DID technology; Verifying the verification content; In response to the verification being passed, a request item is established in the blockchain requirement list based on the verification content, the data description of the request data, and the requirement time.

2. The method according to claim 1, characterized in that The verification content includes a verifiable expression and a DR signature, the verifiable expression is determined based on a first verification credential generated by an identity providing node ISP, the first verification credential and the DR signature are determined by the ISP based on a first attribute set and a DR identity of a data receiving node DR, wherein the DR identity is generated based on DID technology, and the verification of the verification content includes: Performing a legality judgment on the verifiable expression and the DR signature; In response to the legitimacy judgment being passed, determining whether the ISP identity and the DR identity exist in the blockchain identity list, wherein the ISP identity is generated based on the DID technology; In response to the ISP identity and the DR identity being in the blockchain identity list, it is determined whether the first verification credential is legal.

3. The method according to claim 1, characterized in that The method further comprises: Receiving a second target transaction fed back by the DP based on the request item; Performing verification based on the second target transaction; In response to the verification being passed, a first shared record is established in the blockchain contract providing node list, wherein the first shared record is valid before the required time.

4. The method according to claim 3, characterized in that The method further comprises: Receiving a first target transaction generated by the DR based on the first shared record; Performing verification based on the first target transaction; In response to successful verification, a second shared record is established in the blockchain contract providing node list, wherein the second shared record is valid before the required time.

5. The method according to claim 1, characterized in that The method further comprises: Receive the second target transaction sent by DP; verifying the second target transaction; In response to successful verification, a third shared record is established in the blockchain contract providing node list based on the data link corresponding to the DP private key and the encrypted request data in the second target transaction.

6. The method according to claim 1, characterized in that The method further comprises: Receive completion feedback sent by DR; verifying the completion feedback; In response to successful verification, completion of the data transfer is confirmed.

7. A data request method, characterized in that: Applicable to data receiving nodes DR, including: Receiving a first verification credential sent by an identity providing node ISP, wherein the first verification credential includes a DR signature, and the first verification credential and the DR signature are generated by the ISP based on a first attribute set of the DR and a DR identity; Determining a DR verifiable expression based on the first verification credential and the DR signature; Generate a data requirement based on the DR verifiable expression, the data description of the requested data, the DR signature, and the address of the contract providing node; The data requirement is sent to the contract providing node.

8. The method according to claim 7, characterized in that The receiving the first verification credential sent by the identity providing node ISP includes: Acquire a second attribute set and a first identity of the DR, wherein the first identity is generated based on DID technology; sending the second attribute set and the first identity identifier to an ISP for verification; The ISP generates the first verification credential and the DR signature after passing the verification.

9. The method according to claim 7, characterized in that: Before determining the DR verifiable expression based on the first verification credential and the DR signature, the method includes: Receiving a first verification credential fed back by the ISP based on the first attribute set and the first identity identifier; Decrypting the first verification credential based on the private key of the DR to generate a first verification plaintext, and obtaining a second identity of the DR, a third identity of the ISP, and a second attribute set from the first verification plaintext, wherein the second identity and the third identity are generated based on the DID technology; Verification is performed based on the second identity of the DR in the verification plain text, the third identity of the ISP, the second attribute set and the DR signature, and the verification passes.

10. The method according to claim 7, characterized in that After sending the data requirement to the contract providing node, the method further includes: Obtain a request item in the blockchain demand list, where the request item is generated by the ISP in the identity identification list based on the first verification credential; Verifying the request item; In response to successful verification, a first target transaction is constructed and sent to the contract providing node.

11. A data request method, characterized in that: Applicable to data provider nodes DP, including: Obtaining a request item in the identity identification list, where the request item is generated by the ISP in the identity identification list based on the first verification credential; Verifying the request item based on a third attribute set of the DP; In response to the verification being passed, encrypting the request data based on the DP private key to generate encrypted request data; Sending the encrypted request data to a communication node, and receiving a data link corresponding to the encrypted request data fed back by the communication node; A second target transaction is constructed based on the data link and sent to the contract providing node.

12. The method according to claim 11, characterized in that The method further comprises: A third target transaction is constructed based on the DP private key and sent to the contract providing node.

13. A data verification method, characterized in that: For ISPs, including: Verify a target attribute set and a target identity of the target sent by the target, wherein the target is one of the DP or the DR, and wherein the target identity is generated based on the DID technology; In response to the verification being passed, generating a target signature based on the attribute set of the target end and the identity of the target end, wherein the target end is the DR and the target verification credential is the first verification credential, or the target end is the DP and the target verification credential is the second verification credential; Generate a target verification credential corresponding to the target end based on the data description of the request data, the identity of the target end, the attribute set of the target end, the target signature and the target ISP identity of the ISP; The target verification credential is sent to the target end.

14. The method according to claim 13, characterized in that The generating a target signature based on the attribute set of the target end and the identity identifier of the target end includes: Obtaining the ISP private key of the ISP; The DR signature is generated based on the ISP private key, the identity of the target end, the attribute set of the target end, and the target ISP identity of the ISP.

15. The method according to claim 13, characterized in that The method further comprises: Add the target end's identity to the blockchain identity list.

16. The method according to claim 13, characterized in that The method further comprises: Receive the third target transaction sent by DP; Verifying the third target transaction; In response to successful verification, a third shared record is established in the blockchain contract providing node list based on the data link corresponding to the DP private key and the encrypted request data in the third target transaction.

17. A data transmission method, characterized in that: Applicable to DR, including: Get the third shared record in the node list provided by the blockchain contract; Downloading corresponding encrypted request data from a storage space of a communication node based on a data link in the third shared record; The encrypted request data is decrypted to obtain decrypted request data.

18. The method according to claim 20, characterized in that After obtaining the number of decrypted requests, it also includes: Generate completion feedback and send it to the contract providing node.

19. A data requesting device, characterized in that: Applicable to contract providing nodes, including: A first receiving module is used to receive a data demand sent by a data receiving node DR, wherein the data demand at least includes verification content and a data description of the requested data, and the verification content is generated based on a decentralized identifier DID technology; A judgment module, used for verifying the verification content; An establishment module is used to establish a request item in a blockchain requirement list based on the verification content, the data description of the request data and the requirement time in response to the verification being passed.

20. A data requesting device, characterized in that: Applicable to data receiving nodes DR, including: A second receiving module is configured to receive a first verification credential sent by an identity providing node ISP, wherein the first verification credential includes a DR signature, and the first verification credential and the DR signature are generated by the ISP based on a first attribute set of the DR and a DR identity identifier; A first determination module, configured to determine a DR verifiable expression based on the first verification credential and the DR signature; A first generation module, for generating data requirements based on the DR verifiable expression, the data description of the requested data, the DR signature and the address of the contract providing node; The first sending module is used to send the data requirement to the contract providing node.

21. A data requesting device, characterized in that: Applicable to data provider nodes DP, including: A first acquisition module, configured to acquire a request item in the identity identification list, wherein the request item is generated by the ISP in the identity identification list based on the first verification credential; A first verification module, configured to verify the request item based on a third attribute set of the DP; An encryption module, configured to encrypt the request data based on the DP private key in response to the verification being passed, so as to generate encrypted request data; A second sending module, used to send the encrypted request data to a communication node, and receive a data link corresponding to the encrypted request data fed back by the communication node; The third sending module is used to construct a second target transaction based on the data link and send it to the contract providing node.

22. A data verification device, characterized in that: For ISPs, including: A third receiving module is used to verify the target attribute set of the target end and the target identity of the target end sent by the target end, wherein the target end is one of the DP or the DR, and wherein the target identity is generated based on the DID technology; A second generating module, configured to generate a target signature based on the attribute set of the target end and the identity identifier of the target end in response to the verification being passed, wherein the target end is the DR and the target verification credential is the first verification credential, or the target end is the DP and the target verification credential is the second verification credential; A third generating module, configured to generate a target verification credential corresponding to the target end based on a data description of the request data, an identity of the target end, a set of attributes of the target end, the target signature, and a target ISP identity of the ISP; The fourth sending module is used to send the target verification certificate to the target end.

23. A data sending device, characterized in that: Applicable to DR, including: The second acquisition module is used to obtain the third shared record in the node list provided by the blockchain contract; A download module, configured to download corresponding encrypted request data from a storage space of a communication node based on a data link in the third shared record; The decryption module is used to decrypt the encrypted request data to obtain decrypted request data.

24. An electronic device, characterized in that: Including memory. processor; The processor runs a program corresponding to the executable program code by reading the executable program code stored in the memory, so as to implement the data request method as described in any one of claims 1 to 6, or the data request method as described in any one of claims 7 to 10, or the data request method as described in claim 11 or 12, or the data verification method as described in any one of claims 13 to 16, or the data sending method as described in claim 17 or 18.

25. A computer-readable storage medium, characterized in that: The computer-readable storage medium stores computer-executable instructions, which, when executed by a processor, are used to implement the data request method as described in any one of claims 1 to 6, or the data request method as described in any one of claims 7 to 10, or the data request method as described in claim 11 or 12, or the data verification method as described in any one of claims 13 to 16, or the data sending method as described in claim 17 or 18.

Images