Methods, devices, and electronic equipment for managing node permissions in consortium blockchains

Abstract

This application discloses a method, apparatus, and electronic device for managing node permissions in a consortium blockchain. The method involves selecting a trusted node from among trusted nodes as the permission authentication node responsible for allocating node permissions; storing the key pairs of other nodes in the consortium blockchain, along with node identity information, on the permission authentication node to authenticate the legitimacy of the corresponding node; responding to an identity allocation request from a node that has passed the legitimacy authentication, retrieving the public key encapsulated on the permission authentication node and binding it to a digital certificate; and issuing the digital certificate to the node that has passed the legitimacy authentication. When a node that has passed the legitimacy authentication initiates a data transaction request, the digital certificate carried in the data transaction request is verified to determine whether the node that has passed the legitimacy authentication possesses the permission to make the data transaction request, thereby avoiding security risks caused by impersonating blockchain nodes.

Description

Technical Field

[0001] This application relates to the field of consortium blockchain technology, and in particular to a method, apparatus and electronic device for managing node permissions in a consortium blockchain. Background Technology

[0002] Consortium blockchain technology lacks a single authoritative central node for unified management of data within the system. Each node in a consortium blockchain stores a copy of its data on its disk. This necessitates a consensus mechanism that coordinates the actions of each node to reach an agreement on blocks, thereby ensuring data consistency across all nodes.

[0003] However, consortium blockchains are essentially based on internet technology, which means that during data processing, there may be instances of people impersonating blockchain nodes, leading to security risks. Summary of the Invention

[0004] To address the aforementioned issues, this application provides a method, apparatus, and electronic device for managing node permissions in a consortium blockchain.

[0005] The embodiments of this application disclose the following technical solutions:

[0006] According to a first aspect of the embodiments of this application, a method for managing node permissions in a consortium blockchain is provided, including:

[0007] Based on the trusted authentication algorithm, trusted nodes in the consortium blockchain are identified, and a trusted node is selected from the trusted nodes to serve as the authorization authentication node responsible for node permission allocation.

[0008] The key pairs of other nodes in the consortium blockchain, as well as the node identity information, are stored on the authorization authentication node to authenticate the legality of the corresponding node.

[0009] In response to the identity assignment request of a node that has passed the subject legitimacy authentication, the public key encapsulated on the authorization authentication node is retrieved and bound to the digital certificate. There is a one-to-one mapping relationship between the public key, the key pair and the node identity information.

[0010] Digital certificates are issued to nodes that have passed the entity legitimacy authentication. When a node that has passed the entity legitimacy authentication initiates a data transaction request, the digital certificate carried in the data transaction request is verified to determine whether the node that has passed the entity legitimacy authentication has the authority to make the data transaction request.

[0011] Optionally, based on a trusted authentication algorithm, trusted nodes in the consortium blockchain are determined, including: determining multiple trusted behavior data of the blockchain nodes running each application in the consortium blockchain based on the trusted value of each application in the application whitelist of the consortium blockchain, so as to form a trusted behavior data rule base; collecting real-time behavior data of any application running on the blockchain node in real time; and determining the matching degree between the real-time behavior data and the trusted behavior data to determine trusted nodes in the consortium blockchain.

[0012] Optionally, based on the trust value of each application in the application whitelist of the consortium blockchain, multiple trust behavior data of the blockchain nodes of the consortium blockchain running each application are determined to form a trust behavior data rule base. This includes: generating a trust measurement log based on the calculated trust value of each application in the application whitelist. The trust measurement log records the files called during the startup process of each application and their corresponding trust values.

[0013] Optionally, based on the trust value of each application in the application whitelist of the consortium blockchain, multiple trust behavior data of the blockchain nodes of the consortium blockchain running each application are determined to form a trust behavior data rule base, including: parsing the trust measurement log to obtain the files called during the startup process of each application and their corresponding trust values.

[0014] Optionally, a trust measurement log is generated based on the calculated trust value of each application in the application whitelist. This includes: after the blockchain node running each application in the application whitelist is powered on and started, but before its application starts, performing a hash operation on the integrity data of each application in the application whitelist to obtain a hash value, and calculating the trust value of each application in the application whitelist when running on the corresponding blockchain node based on the hash value.

[0015] Optionally, based on a trusted authentication algorithm, trusted nodes in the consortium blockchain are determined, including: identifying a second blockchain node in the consortium blockchain that initiates communication with a first blockchain node, and establishing an authentication connection between the first and second blockchain nodes to obtain neighbor trust proofs in the first blockchain node; determining whether the first blockchain node has performed trust authentication on the second blockchain node based on the neighbor trust proofs; if not, determining the trust propagation path between the first and second blockchain nodes; identifying other blockchain nodes located on the trust propagation path and adjacent to the first and second blockchain nodes respectively; and propagating the neighbor trust proofs of the other blockchain nodes adjacent to the first and second blockchain nodes along the trust propagation path to the first blockchain node, so as to determine all blockchain nodes traversed by the trust propagation path as trusted nodes.

[0016] Optionally, obtaining the neighbor trust proof in the first blockchain node includes: obtaining the trusted authentication kernel and parsing the trusted authentication kernel to obtain the neighbor trust proof.

[0017] Optionally, a trusted node is selected from the trusted nodes as the authorization authentication node responsible for node permission allocation, including: quantifying the trustworthiness of the trusted node to obtain the corresponding trust value, and comparing the trust value with the set trust threshold to select the trusted node with the largest trust value among all trusted nodes as the authorization authentication node.

[0018] Optionally, the digital certificate carried in the data transaction request is verified, including: parsing the digital certificate to obtain the public key bound to it, and determining whether the public key is a public key that has a mapping relationship with the key pair and the node identity information. If so, the digital certificate verification is passed, and it is determined that the node that has passed the subject legitimacy authentication has the right to request data transactions.

[0019] According to a second aspect of the embodiments of this application, a device for managing node permissions in a consortium blockchain is provided, comprising:

[0020] The first program unit is used to determine the trusted nodes in the consortium blockchain based on the trusted authentication algorithm, so as to select a trusted node from the trusted nodes as the authorization authentication node responsible for the allocation of node permissions.

[0021] The second program unit is used to store the key pairs of other nodes in the consortium blockchain, as well as the node identity information, on the authorization authentication node in order to authenticate the legality of the corresponding node.

[0022] The third program unit is used to respond to the identity allocation request of a node that has passed the subject legitimacy authentication, retrieve the public key encapsulated on the authorization authentication node, and bind it to the digital certificate. The public key, the key pair, and the node identity information have a one-to-one mapping relationship.

[0023] The fourth program unit is used to issue digital certificates to nodes that have passed the subject legitimacy authentication, so that when a node that has passed the subject legitimacy authentication initiates a data transaction request, it can verify the digital certificate carried in the data transaction request to determine whether the node that has passed the subject legitimacy authentication has the authority to make the data transaction request.

[0024] Optionally, the first program unit is further configured to: determine multiple trusted behavior data of the blockchain nodes of the consortium blockchain running each application based on the trusted value of each application in the application whitelist of the consortium blockchain, so as to form a trusted behavior data rule base; collect real-time behavior data of any application running on the blockchain node in real time; and determine the matching degree between the real-time behavior data and the trusted behavior data to identify trusted nodes in the consortium blockchain.

[0025] Optionally, the first program unit is further configured to: generate a trust measurement log based on the trust value of each application in the calculated application whitelist, wherein the trust measurement log records the files called during the startup process of each application and the corresponding trust value.

[0026] Optionally, the first program unit is further used to: parse the trust measurement log to obtain the files called during the startup process of each application and their corresponding trust values.

[0027] Optionally, the first program unit is further configured to: after the blockchain node running each application in the application whitelist is powered on and before its application starts, perform a hash operation on the integrity data of each application in the application whitelist to obtain a hash value, and calculate the trust value of each application in the application whitelist when running on the corresponding blockchain node based on the hash value.

[0028] Optionally, the first program unit is further configured to: identify a second blockchain node in the consortium blockchain that initiates communication with the first blockchain node, and establish an authentication connection between the first and second blockchain nodes to obtain a neighbor trust proof in the first blockchain node; determine whether the first blockchain node has performed trust authentication on the second blockchain node based on the neighbor trust proof; if not, determine the trust propagation path between the first and second blockchain nodes; identify other blockchain nodes located on the trust propagation path and adjacent to the first and second blockchain nodes respectively; propagate the neighbor trust proofs of the other blockchain nodes adjacent to the first and second blockchain nodes along the trust propagation path to the first blockchain node, so as to determine all blockchain nodes traversed by the trust propagation path as trusted nodes.

[0029] Optionally, the first program unit is further used to: obtain a trusted authentication kernel, and parse the trusted authentication kernel to obtain a neighbor trust proof.

[0030] Optionally, the first program unit is further used to: quantify the trustworthiness of the trusted node to obtain the corresponding trust value, and based on the comparison between the trust value and the set trust threshold, select the trusted node with the largest trust value among all trusted nodes as the authorization authentication node.

[0031] Optionally, the fourth program unit is further configured to: parse the digital certificate to obtain the public key bound to it, and determine whether the public key is a public key that has a mapping relationship with the key pair and the node identity information. If so, the digital certificate verification is passed, and it is determined that the node that has passed the subject legitimacy authentication has the right to request data transactions.

[0032] According to a third aspect of the embodiments of this application, an electronic device is provided, including a memory and a processor. The memory stores an executable program, and when the processor runs the executable program, it performs the following steps:

[0033] Based on the trusted authentication algorithm, trusted nodes in the consortium blockchain are identified, and a trusted node is selected from the trusted nodes to serve as the authorization authentication node responsible for node permission allocation.

[0034] The key pairs of other nodes in the consortium blockchain, as well as the node identity information, are stored on the authorization authentication node to authenticate the legality of the corresponding node.

[0035] In response to the identity assignment request of a node that has passed the subject legitimacy authentication, the public key encapsulated on the authorization authentication node is retrieved and bound to the digital certificate. There is a one-to-one mapping relationship between the public key, the key pair and the node identity information.

[0036] Digital certificates are issued to nodes that have passed the entity legitimacy authentication. When a node that has passed the entity legitimacy authentication initiates a data transaction request, the digital certificate carried in the data transaction request is verified to determine whether the node that has passed the entity legitimacy authentication has the authority to make the data transaction request.

[0037] In the technical solution of this application embodiment, a trusted node in the consortium blockchain is determined based on a trusted authentication algorithm. A trusted node is then selected from these trusted nodes as the authorization authentication node responsible for allocating node permissions. The key pairs of other nodes in the consortium blockchain, along with node identity information, are stored on the authorization authentication node to perform entity legitimacy authentication on the corresponding nodes. In response to an identity allocation request from a node that has passed entity legitimacy authentication, the public key encapsulated on the authorization authentication node is retrieved and bound to a digital certificate. The public key, key pairs, and node identity information have a one-to-one mapping relationship. A digital certificate is issued to the node that has passed entity legitimacy authentication. When a node that has passed entity legitimacy authentication initiates a data transaction request, the digital certificate carried in the data transaction request is verified to determine whether the node that has passed entity legitimacy authentication has the authority to make the data transaction request, thereby avoiding security risks caused by impersonating blockchain nodes. Attached Figure Description

[0038] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0039] Figure 1This is a flowchart illustrating a method for managing node permissions in a consortium blockchain, as described in an embodiment of this application.

[0040] Figure 2 This is a schematic diagram of the structure of a node permission management device in a consortium blockchain according to an embodiment of this application;

[0041] Figure 3 This is a schematic diagram of the structure of the electronic device in the embodiments of this application;

[0042] Figure 4 This is a schematic diagram of the hardware structure of the electronic device in the embodiments of this application. Detailed Implementation

[0043] Implementing any technical solution of the embodiments of this application does not necessarily require achieving all of the above advantages at the same time.

[0044] To enable those skilled in the art to better understand the present invention, the technical solutions of the present invention will be clearly and completely described below with reference to the accompanying drawings of the embodiments of the present invention. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0045] In the technical solution of this application embodiment, a trusted node in the consortium blockchain is determined based on a trusted authentication algorithm. A trusted node is then selected from these trusted nodes as the authorization authentication node responsible for allocating node permissions. Key pairs and node identity information of other nodes in the consortium blockchain are stored on the authorization authentication node to perform entity legitimacy authentication on the corresponding nodes. In response to an identity allocation request from a node that has passed the entity legitimacy authentication, a public key encapsulated on the authorization authentication node is retrieved and bound to a digital certificate. The public key has a one-to-one mapping relationship with the key pair and the node identity information. The digital certificate is issued to the node that has passed the entity legitimacy authentication. When the node that has passed the entity legitimacy authentication initiates a data transaction request, the digital certificate carried in the data transaction request is verified to determine whether the node that has passed the entity legitimacy authentication has the permission to make the data transaction request, thereby avoiding security risks caused by impersonating blockchain nodes.

[0046] Figure 1 This is a flowchart illustrating a method for managing node permissions in a consortium blockchain according to an embodiment of this application; as shown in Figure 1, it includes:

[0047] S101. Based on the trusted authentication algorithm, determine the trusted nodes in the consortium blockchain, and select a trusted node from the trusted nodes as the authorization authentication node responsible for node permission allocation.

[0048] S102. Store the key pairs of other nodes in the consortium blockchain and the node identity information on the authorization authentication node to perform entity legitimacy authentication on the corresponding node.

[0049] S103. In response to the identity allocation request of the node that has passed the subject legitimacy authentication, retrieve the public key encapsulated on the authorization authentication node and bind it to the digital certificate. The public key has a one-to-one mapping relationship with the key pair and the node identity information.

[0050] S104. The digital certificate is issued to the node that has passed the subject legitimacy authentication, so that when the node that has passed the subject legitimacy authentication initiates a data transaction request, the digital certificate carried in the data transaction request is verified to determine whether the node that has passed the subject legitimacy authentication has the authority to make the data transaction request.

[0051] Optionally, determining trusted nodes in the consortium blockchain based on a trusted authentication algorithm includes: determining multiple trusted behavior data of the blockchain nodes running the applications in the consortium blockchain based on the trusted values ​​of each application in the application whitelist of the consortium blockchain, to form a trusted behavior data rule base; collecting real-time behavior data of any application running on the blockchain node in real time; and determining the matching degree between the real-time behavior data and the trusted behavior data to determine trusted nodes in the consortium blockchain, thereby ensuring that the determined trusted nodes have high reliability.

[0052] Optionally, the step of determining multiple trusted behavior data of the blockchain nodes of the consortium blockchain running each application based on the trusted value of each application in the application whitelist of the consortium blockchain to form a trusted behavior data rule base includes: generating a trusted measurement log based on the calculated trusted value of each application in the application whitelist. The trusted measurement log records the files called during the startup process of each application and their corresponding trusted values, thereby ensuring that the generated trusted values ​​are relatively accurate. At the same time, it reduces the amount of data processed by the algorithm and improves the execution efficiency of the algorithm.

[0053] Optionally, the step of determining multiple trusted behavior data of the blockchain nodes of the consortium blockchain running each application based on the trusted value of each application in the application whitelist of the consortium blockchain to form a trusted behavior data rule base includes: parsing the trusted measurement log to obtain the files called during the startup process of each application and their corresponding trusted values, thereby improving the accuracy of trusted data.

[0054] Optionally, the step of generating a trust measurement log based on the calculated trust value of each application in the application whitelist includes: after the blockchain node running each application in the application whitelist is powered on and started, but before its application starts, performing a hash operation on the integrity data of each application in the application whitelist to obtain a hash value, and calculating the trust value of each application in the application whitelist when running on the corresponding blockchain node based on the hash value. This makes the trust value calculation process a dynamic process, effectively ensuring the accuracy of the trust value.

[0055] Optionally, determining trusted nodes in the consortium blockchain based on a trusted authentication algorithm includes: identifying a second blockchain node in the consortium blockchain that initiates communication with a first blockchain node, and establishing an authentication connection between the first and second blockchain nodes to obtain neighbor trustworthiness proofs in the first blockchain node; determining whether the first blockchain node has performed trust authentication on the second blockchain node based on the neighbor trustworthiness proofs; if not, determining a trust propagation path between the first and second blockchain nodes; identifying other blockchain nodes located on the trust propagation path and adjacent to the first and second blockchain nodes respectively; and propagating the neighbor trustworthiness proofs of the other blockchain nodes adjacent to the first and second blockchain nodes along the trust propagation path to the first blockchain node, so as to determine all blockchain nodes traversed by the trust propagation path as trusted nodes.

[0056] In this embodiment, based on the aforementioned trust propagation path, mutual authentication of trust is achieved, thereby ensuring that the identified trusted nodes have high reliability.

[0057] Optionally, obtaining the neighbor trust proof in the first blockchain node includes: obtaining a trusted authentication kernel, and parsing the trusted authentication kernel to obtain the neighbor trust proof. The trusted authentication kernel prevents the leakage of trusted authentication-related data, thereby ensuring the reliability of the trusted node.

[0058] Optionally, the step of selecting a trusted node from the trusted nodes as the authorization authentication node responsible for node authorization allocation includes: quantifying the trustworthiness of the trusted node to obtain a corresponding trust value, comparing the trust value with a set trust threshold, and selecting the trusted node with the largest trust value among all trusted nodes as the authorization authentication node, thereby improving the efficiency of algorithm execution.

[0059] Optionally, the verification of the digital certificate carried in the data transaction request includes: parsing the digital certificate to obtain the public key bound thereto, and determining whether the public key is a public key that has the mapping relationship with the key pair and the node identity information. If so, the digital certificate verification is successful, and it is determined that the node that has passed the subject legitimacy authentication has the authority to make the data transaction request.

[0060] By mapping the public key, the key pair, and the node identity information, the isolation performance between data during algorithm execution is improved, ensuring the security of individual data.

[0061] Figure 2 Figure 2 is a schematic diagram of a node permission management device in a consortium blockchain according to an embodiment of this application; as shown in Figure 2, it includes:

[0062] The first program unit 201 is used to determine the trusted nodes in the consortium blockchain based on a trusted authentication algorithm, so as to select a trusted node from the trusted nodes as the authorization authentication node responsible for node authorization allocation.

[0063] The second program unit 202 is used to store the key pairs of other nodes in the consortium blockchain and the node identity information on the authorization authentication node in order to perform subject legitimacy authentication on the corresponding node.

[0064] The third program unit 203 is used to respond to the identity allocation request of the node that has passed the subject legitimacy authentication, retrieve the public key encapsulated on the authorization authentication node, and bind it to the digital certificate. The public key has a one-to-one mapping relationship with the key pair and the node identity information.

[0065] The fourth program unit 204 is used to issue the digital certificate to the node that has passed the subject legitimacy authentication, so as to verify the digital certificate carried in the data transaction request when the node that has passed the subject legitimacy authentication initiates the data transaction request, so as to determine whether the node that has passed the subject legitimacy authentication has the authority to make the data transaction request.

[0066] Optionally, the first program unit 201 is further configured to: determine multiple trusted behavior data of the blockchain nodes of the consortium blockchain running the respective applications based on the trusted values ​​of each application in the application whitelist of the consortium blockchain, so as to form a trusted behavior data rule base; collect real-time behavior data of any application running on the blockchain node in real time; and determine the matching degree between the real-time behavior data and the trusted behavior data to identify trusted nodes in the consortium blockchain.

[0067] Optionally, the first program unit 201 is further configured to: generate a trust measurement log based on the trust value of each application in the calculated application whitelist, wherein the trust measurement log records the files called during the startup process of each application and the corresponding trust value.

[0068] Optionally, the first program unit 201 is further configured to: parse the trust measurement log to obtain the files called during the startup process of each application and their corresponding trust values.

[0069] Optionally, the first program unit 201 is further configured to: after the blockchain node running each application in the application whitelist is powered on and before its application is started, perform a hash operation on the integrity data of each application in the application whitelist to obtain a hash value, and calculate the trust value of each application in the application whitelist when running on the corresponding blockchain node based on the hash value.

[0070] Optionally, the first program unit 201 is further configured to: determine a second blockchain node in the consortium blockchain that initiates communication with the first blockchain node, and establish an authentication connection between the first blockchain node and the second blockchain node to obtain a neighbor trust proof in the first blockchain node; determine whether the first blockchain node has performed trust authentication on the second blockchain node based on the neighbor trust proof; if not, determine a trust propagation path between the first blockchain node and the second blockchain node; determine other blockchain nodes located on the trust propagation path and adjacent to the first blockchain node and the second blockchain node respectively; propagate the neighbor trust proofs of the other blockchain nodes adjacent to the first blockchain node and the second blockchain node respectively along the trust propagation path to the first blockchain node, so as to determine all blockchain nodes traversed by the trust propagation path as the trusted nodes.

[0071] Optionally, the first program unit 201 is further configured to: obtain a trusted authentication kernel, and parse the trusted authentication kernel to obtain the neighbor trustworthiness proof.

[0072] Optionally, the first program unit 201 is further configured to: quantify the trustworthiness of the trusted node to obtain a corresponding trust value, and based on the comparison between the trust value and a set trust threshold, select the trusted node with the largest trust value among all trusted nodes as the authorization authentication node.

[0073] Optionally, the fourth program unit 204 is further configured to: parse the digital certificate to obtain the public key bound thereto, and determine whether the public key is a public key that has the mapping relationship with the key pair and the node identity information. If so, the digital certificate verification is passed, and it is determined that the node that has passed the subject legitimacy authentication has the right to request data transactions.

[0074] Figure 3 This is a schematic diagram of the structure of an electronic device according to an embodiment of this application; as shown Figure 3 As shown, it includes a memory 301 and a processor 302. The memory stores an executable program, and when the processor runs the executable program, it performs the following steps:

[0075] Based on a trusted authentication algorithm, trusted nodes in the consortium blockchain are determined, and a trusted node is selected from the trusted nodes as the authorization authentication node responsible for node permission allocation.

[0076] The key pairs of other nodes in the consortium blockchain, as well as the node identity information, are stored on the authorization authentication node to authenticate the legality of the corresponding node.

[0077] In response to the identity assignment request of a node that has passed the subject legitimacy authentication, the public key encapsulated on the authorization authentication node is retrieved and bound to the digital certificate. The public key has a one-to-one mapping relationship with the key pair and the node identity information.

[0078] The digital certificate is issued to nodes that have passed the entity legitimacy authentication, so that when a node that has passed the entity legitimacy authentication initiates a data transaction request, the digital certificate carried in the data transaction request is verified to determine whether the node that has passed the entity legitimacy authentication has the authority to make the data transaction request. Figure 4 This is a schematic diagram of the hardware structure of the electronic device in the embodiments of this application; as shown Figure 4 As shown, the hardware structure of this electronic device may include: Electronic device 400 includes a computing unit 401, which can perform various appropriate actions and processes according to a computer program stored in read-only memory (ROM) 402 or a computer program loaded from storage unit 406 into random access memory (RAM) 403. The RAM 403 may also store various programs and data required for the operation of device 400. The computing unit 401, ROM 402, and RAM 403 are interconnected via bus 404. Input / output (I / O) interface 405 is also connected to bus 404.

[0079] Multiple components in electronic device 400 are connected to I / O interface 405, including: input unit 406, output unit 407, storage unit 408, and communication unit 409. Input unit 406 can be any type of device capable of inputting information to electronic device 400. Input unit 406 can receive input digital or character information and generate key signal inputs related to user settings and / or function control of electronic device. Output unit 407 can be any type of device capable of presenting information and may include, but is not limited to, a display, speaker, video / audio output terminal, vibrator, and / or printer. Storage unit 404 may include, but is not limited to, disks and optical discs. Communication unit 409 allows electronic device 400 to exchange information / data with other devices through computer networks such as the Internet and / or various telecommunications networks, and may include, but is not limited to, modems, network cards, infrared communication devices, wireless communication transceivers, and / or chipsets, such as Bluetooth™ devices, WiFi devices, WiMax devices, cellular communication devices, and / or the like.

[0080] The computing unit 401 can be a variety of general-purpose and / or special-purpose processing components with processing and computing capabilities. Some examples of the computing unit 401 include, but are not limited to, a central processing unit (CPU), a graphics processing unit (GPU), various special-purpose artificial intelligence (AI) computing chips, various computing units running machine learning model algorithms, a digital signal processor (DSP), and any suitable processor, controller, microcontroller, etc. The computing unit 401 performs the various methods and processes described above. For example, in some embodiments, the above steps can be implemented as a computer software program tangibly contained in a machine-readable medium, such as storage unit 40*. In some embodiments, part or all of the computer program can be loaded and / or installed on the electronic device 400 via ROM 402 and / or communication unit 409. In some embodiments, the computing unit 401 can be configured to perform the above steps by any other suitable means (e.g., by means of firmware).

[0081] The electronic devices in this application embodiments exist in various forms, including but not limited to:

[0082] (1) Mobile communication devices: These devices are characterized by their mobile communication capabilities and primarily aim to provide voice and data communication. These terminals include: smartphones (e.g., iPhones), multimedia phones, feature phones, and low-end phones, etc.

[0083] (2) Ultra-mobile personal computer devices: These devices fall under the category of personal computers, possessing computing and processing capabilities, and generally also have mobile internet access features. These terminals include PDAs, MIDs, and UMPCs, such as the iPad.

[0084] (3) Portable entertainment devices: These devices can display and play multimedia content. This category includes audio and video players (such as iPods), handheld game consoles, e-book readers, as well as smart toys and portable car navigation devices.

[0085] (4) Server: A device that provides computing services. The components of a server include a processor 410, hard disk, memory, system bus, etc. Servers are similar to general computer architectures, but because they need to provide highly reliable services, they have higher requirements in terms of processing power, stability, reliability, security, scalability, and manageability.

[0086] (5) Other electronic devices with data interaction functions.

[0087] It should be noted that the various embodiments in this specification are described in a progressive manner, and the same or similar parts between the various embodiments can be referred to mutually. Each embodiment focuses on describing the differences from other embodiments. In particular, for the device and system embodiments, since they are basically similar to the method embodiments, the description is relatively simple, and the relevant parts can be referred to the description of the method embodiments. The device and system embodiments described above are merely illustrative. The modules described as separate components may or may not be physically separate, and the components indicated as modules may or may not be physical modules, that is, they may be located in one place or distributed across multiple network modules. Some or all of the modules can be selected to achieve the purpose of the solution in this embodiment according to actual needs. Those skilled in the art can understand and implement this without creative effort.

[0088] The above description is merely one specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the technical scope disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

Claims

1. A method for managing node permissions in a consortium blockchain, characterized in that, include: Based on a trusted authentication algorithm, trusted nodes in the consortium blockchain are determined, and a trusted node is selected from the trusted nodes as the authorization authentication node responsible for node permission allocation. The key pairs of other nodes in the consortium blockchain, as well as the node identity information, are stored on the authorization authentication node to authenticate the legality of the corresponding node. In response to the identity assignment request of a node that has passed the subject legitimacy authentication, the public key encapsulated on the authorization authentication node is retrieved and bound to the digital certificate. The public key has a one-to-one mapping relationship with the key pair and the node identity information. The digital certificate is issued to nodes that have passed the entity legitimacy authentication, so that when a node that has passed the entity legitimacy authentication initiates a data transaction request, the digital certificate carried in the data transaction request is verified to determine whether the node that has passed the entity legitimacy authentication has the authority to make the data transaction request.

2. The method for managing node permissions in a consortium blockchain according to claim 1, characterized in that, The process of determining trusted nodes in the consortium blockchain based on a trusted authentication algorithm includes: determining multiple trusted behavior data of the blockchain nodes running the applications in the consortium blockchain based on the trusted values ​​of each application in the application whitelist of the consortium blockchain, to form a trusted behavior data rule base; collecting real-time behavior data of any application running on the blockchain node in real time; and determining the matching degree between the real-time behavior data and the trusted behavior data to determine the trusted nodes in the consortium blockchain.

3. The method for managing node permissions in a consortium blockchain according to claim 1, characterized in that, The step of determining multiple trusted behavior data of the blockchain nodes of the consortium blockchain running each application based on the trusted value of each application in the application whitelist of the consortium blockchain to form a trusted behavior data rule base includes: generating a trusted measurement log based on the calculated trusted value of each application in the application whitelist, wherein the trusted measurement log records the files called during the startup process of each application and the corresponding trusted value.

4. The method for managing node permissions in a consortium blockchain according to claim 3, characterized in that, The step of determining multiple trusted behavior data of the blockchain nodes of the consortium blockchain running each application based on the trusted value of each application in the application whitelist of the consortium blockchain to form a trusted behavior data rule base includes: parsing the trusted measurement log to obtain the files called during the startup process of each application and their corresponding trusted values.

5. The method for managing node permissions in a consortium blockchain according to claim 3, characterized in that, The step of generating a trust measurement log based on the calculated trust value of each application in the application whitelist includes: after the blockchain node running each application in the application whitelist is powered on and started, but before its application starts, performing a hash operation on the integrity data of each application in the application whitelist to obtain a hash value, and calculating the trust value of each application in the application whitelist when running on the corresponding blockchain node based on the hash value.

6. The method for managing node permissions in a consortium blockchain according to claim 1, characterized in that, The method of determining trusted nodes in the consortium blockchain based on a trusted authentication algorithm includes: identifying a second blockchain node in the consortium blockchain that initiates communication with a first blockchain node, and establishing an authentication connection between the first and second blockchain nodes to obtain neighbor trustworthiness proofs from the first blockchain node; determining whether the first blockchain node has performed trust authentication on the second blockchain node based on the neighbor trustworthiness proofs; if not, determining a trust propagation path between the first and second blockchain nodes; identifying other blockchain nodes located on the trust propagation path and adjacent to the first and second blockchain nodes respectively; and propagating the neighbor trustworthiness proofs of the other blockchain nodes adjacent to the first and second blockchain nodes along the trust propagation path to the first blockchain node, so as to determine all blockchain nodes traversed by the trust propagation path as trusted nodes.

7. The method for managing node permissions in a consortium blockchain according to claim 6, characterized in that, The step of obtaining the neighbor trust proof in the first blockchain node includes: obtaining the trusted authentication kernel and parsing the trusted authentication kernel to obtain the neighbor trust proof.

8. The method for managing node permissions in a consortium blockchain according to claim 1, characterized in that, The step of selecting a trusted node from the trusted nodes as the authorization authentication node responsible for node authorization allocation includes: quantifying the trustworthiness of the trusted node to obtain a corresponding trust value, comparing the trust value with a set trust threshold, and selecting the trusted node with the largest trust value among all trusted nodes as the authorization authentication node.

9. The method for managing node permissions in a consortium blockchain according to claim 1, characterized in that, The verification of the digital certificate carried in the data transaction request includes: parsing the digital certificate to obtain the public key bound to it, and determining whether the public key is a public key that has the mapping relationship with the key pair and the node identity information. If so, the digital certificate verification is successful, and it is determined that the node that has passed the subject legitimacy authentication has the authority to make the data transaction request.

10. A device for managing node permissions in a consortium blockchain, characterized in that, include: The first program unit is used to determine the trusted nodes in the consortium blockchain based on a trusted authentication algorithm, so as to select a trusted node from the trusted nodes as the authorization authentication node responsible for node permission allocation. The second program unit is used to store the key pairs of other nodes in the consortium blockchain and the node identity information on the authorization authentication node in order to perform subject legitimacy authentication on the corresponding node. The third program unit is used to respond to the identity allocation request of the node that has passed the subject legitimacy authentication, retrieve the public key encapsulated on the authorization authentication node, and bind it to the digital certificate. The public key has a one-to-one mapping relationship with the key pair and the node identity information. The fourth program unit is used to issue the digital certificate to nodes that have passed the subject legitimacy authentication, so as to verify the digital certificate carried in the data transaction request when the node that has passed the subject legitimacy authentication initiates the data transaction request, so as to determine whether the node that has passed the subject legitimacy authentication has the authority to make the data transaction request.

11. The node permission management device in a consortium blockchain according to claim 10, characterized in that, The first program unit is further configured to: determine multiple trusted behavior data of the blockchain nodes of the consortium blockchain running the respective applications based on the trusted value of each application in the application whitelist of the consortium blockchain, so as to form a trusted behavior data rule base; Real-time behavioral data of any application running on the blockchain node is collected. Determine the matching degree between the real-time behavioral data and the trusted behavioral data to identify trusted nodes in the consortium blockchain.

12. The node permission management device in a consortium blockchain according to claim 10, characterized in that, The first program unit is further configured to: generate a trust measurement log based on the trust value of each application in the calculated application whitelist, wherein the trust measurement log records the files called during the startup process of each application and the corresponding trust value.

13. The node permission management device in a consortium blockchain according to claim 12, characterized in that, The first program unit is further configured to: parse the trust measurement log to obtain the files called during the startup process of each application and their corresponding trust values.

14. The node permission management device in a consortium blockchain according to claim 12, characterized in that, The first program unit is further configured to: after the blockchain node running each application in the application whitelist is powered on and before its application is started, perform a hash operation on the integrity data of each application in the application whitelist to obtain a hash value, and calculate the trust value of each application in the application whitelist when running on the corresponding blockchain node based on the hash value.

15. The node permission management device in a consortium blockchain according to claim 10, characterized in that, The first program unit is further configured to: determine the second blockchain node in the consortium blockchain that initiates communication with the first blockchain node, and establish an authentication connection between the first blockchain node and the second blockchain node to obtain the neighbor trust proof in the first blockchain node; Based on the neighbor trust proof, determine whether the first blockchain node has performed trust authentication on the second blockchain node; If not, then determine the trust propagation path between the first blockchain node and the second blockchain node; determine other blockchain nodes located on the trust propagation path and adjacent to the first blockchain node and the second blockchain node respectively; propagate the neighbor trust proofs of the other blockchain nodes adjacent to the first blockchain node and the second blockchain node to the first blockchain node along the trust propagation path, so as to determine all blockchain nodes traversed by the trust propagation path as the trusted nodes.

16. The node permission management device in a consortium blockchain according to claim 15, characterized in that, The first program unit is further configured to: obtain a trusted authentication kernel, and parse the trusted authentication kernel to obtain the neighbor's trustworthiness proof.

17. The node permission management device in a consortium blockchain according to claim 10, characterized in that, The first program unit is further configured to: quantify the trustworthiness of the trusted node to obtain a corresponding trust value, and based on the comparison between the trust value and a set trust threshold, select the trusted node with the largest trust value among all trusted nodes as the authorization authentication node.

18. The node permission management device in a consortium blockchain according to claim 10, characterized in that, The fourth program unit is further configured to: parse the digital certificate to obtain the public key bound thereto, and determine whether the public key is a public key that has the mapping relationship with the key pair and the node identity information. If so, the digital certificate verification is successful, and it is determined that the node that has passed the subject legitimacy authentication has the right to request data transactions.

19. An electronic device, characterized in that, The system includes a memory and a processor, wherein the memory stores an executable program, and the processor executes the following steps when running the executable program: Based on a trusted authentication algorithm, trusted nodes in the consortium blockchain are determined, and a trusted node is selected from these trusted nodes as the authorization authentication node responsible for allocating node permissions. The key pairs of other nodes in the consortium blockchain, as well as the node identity information, are stored on the authorization authentication node to authenticate the legality of the corresponding node. In response to the identity assignment request of a node that has passed the subject legitimacy authentication, the public key encapsulated on the authorization authentication node is retrieved and bound to the digital certificate. The public key has a one-to-one mapping relationship with the key pair and the node identity information. The digital certificate is issued to nodes that have passed the entity legitimacy authentication, so that when a node that has passed the entity legitimacy authentication initiates a data transaction request, the digital certificate carried in the data transaction request is verified to determine whether the node that has passed the entity legitimacy authentication has the authority to make the data transaction request.

Images