WO2023040527A1

WO2023040527A1 - Blockchain-based network node control method and system and consensus node

Info

Publication number: WO2023040527A1
Application number: PCT/CN2022/111680
Authority: WO
Inventors: 刘高; 闫峥; 王海光; 李铁岩
Original assignee: 华为技术有限公司
Priority date: 2021-09-17
Filing date: 2022-08-11
Publication date: 2023-03-23
Also published as: CN115834093A

Abstract

A blockchain-based network node control method. According to the method, the trust value of each network node can be periodically updated, and the consistency of a list of trust values is ensured by using a blockchain, such that different network operators can trust each other, and the unlinkability of a pseudonym for the network node and the validity of trust evaluation are ensured. In this way, different network operators can cooperate to manage the pseudonym for the network node and a corresponding trust value, and a list of <an interdomain pseudonym, a trust value> is issued by means of a blockchain to assist in decision-making of an interdomain network, such that the network operators can provide high-quality network service and improve user experience.

Description

A blockchain-based network node control method, system, and consensus node

This application claims the priority of the Chinese patent application submitted to the State Intellectual Property Office of China on September 17, 2021, with the application number 202111092096.5 and the application name "A blockchain-based network node control method, system, and consensus node" , the entire contents of which are incorporated in this application by reference.

technical field

The present application relates to the field of computer technology, in particular to a block chain-based network node control method, system and consensus node.

Background technique

Due to the openness, heterogeneity and vulnerability of the network, today's network faces various security threats. Understanding the trust state of the network is expected to help network nodes make correct decisions to mitigate potential threats, such as trusted routing through trust-based verification. Therefore, node trust should be evaluated and shared in the network. Many trust evaluation systems employ a centralized architecture to evaluate trust. However, they suffer from a single point of failure.

Contents of the invention

In order to achieve the above technical purpose, this application provides a network node control method, system, consensus node, computer readable storage medium and computer program products, provides a trust evaluation method for inter-domain network nodes, and realizes different network Mutual trust between each consensus node in the network, and realize global anonymous trust evaluation and sharing.

In the first aspect, a blockchain-based network node control method is provided. The blockchain includes a first consensus node and a second consensus node. The first consensus node corresponds to the first server in the first network, and the second consensus node corresponds to the first server in the first network. The node corresponds to the second server in the second network, and both the first network and the second network include at least one network node; the method includes: the first consensus node obtains the first block, and the first block includes the first target list, The first target list includes the first target virtual ID and the first target trust value corresponding to each network node in the first network and the second network, wherein the first target virtual ID is used to characterize the identity of the network node, and the first target virtual ID The identity is different from the real identity of the network node, and is obtained by the first consensus node and the second consensus node based on the real identity of the network node, and the first target trust value is used to represent the trustworthiness of the network node in its network Degree; when the first consensus node meets the first preset condition, the trust value of each network node in the first target list is updated to obtain the second target list, and the second block is generated based on the second target list, wherein, The second block includes the second target list; the first consensus node sends the second block to the second consensus node, so that the second consensus node can verify the second block; the first consensus node obtains the second consensus The first message sent by the node stores the second block in the blockchain, and the first message is used to indicate that the verification of the second block is passed. Therefore, after a consensus node updates the trust value of the network node, another consensus node uses the PBFT consensus mechanism of the blockchain to verify the updated trust value, thereby ensuring the consistency of the management list and realizing the decentralization of list management , so that each consensus node can trust each other, so as to realize global anonymous trust evaluation and sharing. At the same time, each consensus node can record the updated list, so that the network nodes corresponding to each consensus node can realize trust value verification and decision-making by accessing the blockchain.

In a possible implementation manner, the first consensus node obtains the first block, which specifically includes: the first consensus node determines the first initial list, and the first initial list includes the real identity of each network node and the corresponding The first trust value is obtained by encrypting the trust value corresponding to each network node in the first target list by the first consensus node and/or the second consensus node; the first consensus node encrypts each The real identity of the network node, the first virtual identity corresponding to each network node is obtained, and the first trust value corresponding to each network node is respectively decrypted based on the second key, and the second trust value corresponding to each network node is obtained, wherein each The first virtual identity and the second trust value corresponding to each first virtual identity constitute the second initial list; the first consensus node sends the second initial list to the second consensus node, so that the second consensus node can Encrypting the first virtual identifier corresponding to each network node to obtain the first target virtual identifier, and decrypting the second trust value corresponding to each network node based on the fourth key to obtain the first target trust value corresponding to each network node, wherein , each first target virtual ID and the first target trust value corresponding to each first target virtual ID constitute the first target list; the first consensus node obtains the first target list sent by the second consensus node, and generates the first target list based on the first target list The first block, and store the first block in the blockchain. As a result, different consensus nodes generate a target list through a verifiable shuffling algorithm, so that different consensus nodes can trust each other.

In a possible implementation, the first consensus node updates each network node in the first target list to obtain the second target list, which specifically includes: the first consensus node obtains the behavior of each network node within a preset time period data;

Based on the behavior data corresponding to each network node, the preset time decay coefficient and the first target trust value corresponding to each network node, the first consensus node determines the second target trust value corresponding to each network node; The first target trust value in the target list is updated to the second target trust value to obtain the second target list. Therefore, when updating the trust value of the network node, the time decay coefficient is used as one of the calculation parameters, which avoids errors caused by time decay and improves the accuracy of trust value calculation.

In a possible implementation, the method further includes: when the first consensus node satisfies the second preset condition, updating the trust values corresponding to at least two of the network nodes in the second target list to the third Target trust value to obtain the third target list; the first consensus node obtains the third initial list based on the third target list, the third initial list includes the real identity and the third trust value corresponding to each network node, the third trust value Based on the first consensus node and/or the second consensus node encrypting the trust value corresponding to each network node in the third target list; the first consensus node encrypts the real identity of each network node based on the fifth key to obtain the The second virtual identity corresponding to the node and the trust value corresponding to each network node in the third target list are respectively decrypted based on the sixth key to obtain a fourth trust value corresponding to each network node, wherein each second virtual identity and The fourth trust value constitutes the third initial list; the first consensus node sends the third initial list to the second consensus node, so that the second consensus node encrypts the second virtual identity corresponding to each network node based on the seventh key, and obtains The second target virtual identity, and, based on the eighth key, respectively decrypt the trust values corresponding to each network node in the third initial list to obtain the fourth target trust value corresponding to each network node, wherein each second target virtual identity Constitute a fourth target list with each fourth target trust value, and at least two trust values in each fourth target trust value are the same as the third target trust value; the first consensus node obtains the fourth target list sent by the second consensus node , and generate a third block based on the fourth target list, and store the third block in the blockchain. Therefore, when certain conditions are met, the trust value is confused and the virtual identity is updated, thereby preventing attackers from tracking the activities of network nodes for a long time and improving network security. It can be understood that the second target virtual identifier is different from the first target virtual identifier.

In a possible implementation, the first consensus node updates the trust values corresponding to at least two network nodes in the second target list to the third target trust value, which specifically includes: the first consensus node determines at least The target interval to which the trust values corresponding to the two network nodes belong, and using the lower limit value of the target interval as the third target trust value, and updating the trust values corresponding to at least two network nodes to the third target trust value. Therefore, trust confusion is performed by updating the trust values of at least two network nodes to the same trust value, so as to enhance the unlinkability between pseudonyms (ie, virtual identities) and trust values in the list, and improve security.

In a possible implementation manner, before the first consensus node updates the trust values corresponding to at least two network nodes in each network node in the second target list to the third target trust value, it also includes: the first consensus node based on The preset time decay coefficient and the trust value of each network node in the second target list re-determine the trust value of each network node. Therefore, before the trust is confused, the trust value of each network node can be re-evaluated to reduce the impact of time decay on the trust value and improve data security.

In the second aspect, a blockchain-based network node control method is provided. The blockchain includes a first consensus node and a second consensus node. The first consensus node corresponds to the first server in the first network, and the second consensus node corresponds to the first server in the first network. The node corresponds to the second server in the second network, and both the first network and the second network include at least one network node; the method includes: the second consensus node obtains the second block sent by the first consensus node, and the second block in the second block Including the second target list, the second target list is obtained by updating the trust value of each network node in the first target list contained in the first block when the first consensus node meets the first preset condition, the first target list Include the first target virtual identity and the first target trust value corresponding to each network node in the first network and the second network, wherein the first target virtual identity is used to represent the identity of the network node, and the first target virtual identity and the network node The real identity of the network node is different, and is obtained by the first consensus node and the second consensus node based on the real identity of the network node. The first target trust value is used to represent the degree of trust of the network node in its network; the second The consensus node verifies the second block, and when the verification is passed, sends a first message to the first consensus node, where the first message is used to indicate that the second block is verified.

In a possible implementation, before the second consensus node obtains the second block sent by the first consensus node, it also includes: the second consensus node obtains the second initial list sent by the first consensus node, and the second initial list Including the first virtual identity and the second trust value of each network node, the first virtual identity is obtained by encrypting the real identity of the network node in the first initial list by the first consensus node based on the first key, and the second trust value is The first consensus node decrypts the first trust value corresponding to the network node in the first initial list based on the second key, and the first initial list includes the real identity of each network node and the first trust value corresponding to each network node , the first trust value is obtained by encrypting the trust value corresponding to each network node in the first target list by the first consensus node and/or the second consensus node; the second consensus node encrypts the corresponding trust value of each network node based on the third key A virtual identity, to obtain the first target virtual identity, and decrypt the second trust value corresponding to each network node based on the fourth key to obtain the first target trust value corresponding to each network node, wherein each first target virtual identity The first target trust value corresponding to each first target virtual identifier constitutes a first target list; the second consensus node sends the first target list to the first consensus node.

In a possible implementation, the method further includes: the second consensus node obtains the third initial list sent by the first consensus node, the third initial list includes the second virtual identity and the fourth trust value corresponding to each network node, The second virtual identity is obtained by the first consensus node encrypting the real identity of the network node based on the fifth key, and the fourth trust value is the third trust value corresponding to the network node in the third target list by the first consensus node based on the sixth key The value is decrypted to obtain, the third target list includes the real identity and the third trust value corresponding to each network node, the third trust value is based on the first consensus node and/or the second consensus node for each network node in the third target list The corresponding trust value is encrypted, wherein, the third target list is that the first consensus node updates the trust values corresponding to at least two network nodes in the second target list to the first consensus node when the second preset condition is met. The three-target trust value is obtained; the second consensus node encrypts the second virtual ID corresponding to each network node based on the seventh key to obtain the second target virtual ID, and, based on the eighth key, each network in the third initial list The trust value corresponding to the node is decrypted to obtain the fourth target trust value corresponding to each network node, wherein each second target virtual identity and each fourth target trust value constitute a fourth target list, and each fourth target trust value is at least There are two trust values that are the same as the third target trust value; the second consensus node sends the fourth target list to the first consensus node, so that the first consensus node generates a third block based on the fourth target list, and the third Blocks are stored in the blockchain.

In a third aspect, a device control method is provided, which is applied to a first device, and the method includes: the first device acquires a target virtual identifier corresponding to the first device based on a target block in the blockchain, and the target block is The second block obtained based on the first aspect or the second aspect; the first device sends a target message to the second device, the target message includes the target virtual ID and the target signature, and the target signature is based on the first device’s own private key pair The target message is signed. In this way, when the first device communicates with the second device, the first device can obtain its corresponding pseudonym (that is, a virtual ID) from the blockchain block, and carry the pseudonym in the message it sends, so that After the second device obtains the message sent by the first device, it can verify the message based on the pseudonym, and then conduct business activities based on the trust value of the device in the block.

In a fourth aspect, a device control method is provided, which is applied to a second device, and the method includes: the second device acquires a target message sent by the first device, the target message includes a target virtual ID and a target signature, and the target virtual ID is the first The virtual identification of a device, which is obtained by the first device based on the target block in the blockchain, the target block is the second block obtained based on the first aspect or the second aspect, and the target signature is the first device based on its own The private key of the target is obtained by signing the target message; the second device uses the target pseudonym to verify the target signature, and after the verification is passed, uses the target pseudonym to obtain the target trust value corresponding to the target pseudonym from the blockchain, and Conduct business activities based on the target trust value. Exemplarily, the second device may use the target pseudonym to verify the target signature included in the target message by using the ElGamal algorithm.

According to the fifth aspect, there is provided a device control device, which includes at least one memory for storing programs; at least one processor for executing the programs stored in the memory, and when the programs stored in the memory are executed, the processor is used for executing the third The method provided in the aspect, or the method provided in the fourth aspect.

In the sixth aspect, a consensus node is provided, including: at least one memory for storing programs; at least one processor for executing the programs stored in the memory, and when the programs stored in the memory are executed, the processor is used for executing The method provided in one aspect, or execute the method provided in the second aspect.

In the seventh aspect, a computer-readable storage medium is provided. The computer-readable storage medium stores a computer program. When the computer program runs on the electronic device, the electronic device executes the method provided in the first aspect, or executes the method described in the first aspect. The method provided in the second aspect, or execute the method provided in the third aspect, or execute the method provided in the fourth aspect.

In an eighth aspect, a computer program product is provided. When the computer program product runs on an electronic device, the electronic device executes the method as provided in the first aspect, or executes the method as provided in the second aspect, or executes the method as provided in the second aspect. The method provided by the third aspect, or, execute the method provided by the fourth aspect.

It can be understood that, for the beneficial effects of the above-mentioned second aspect to the eighth aspect, reference may be made to relevant descriptions in the above-mentioned first aspect or third aspect, and details are not repeated here.

Description of drawings

The following briefly introduces the drawings used in the embodiments or the description of the prior art.

Figure 1 is a schematic diagram of a hybrid network with two anonymous servers and three network nodes provided by the embodiment of the present application;

FIG. 2a is a schematic diagram of an application scenario of an inter-domain network provided by an embodiment of the present application;

FIG. 2b is a schematic diagram of another application scenario of an inter-domain network according to an embodiment of the present application;

FIG. 3 is a schematic diagram of an inter-domain pseudonym and trust maintenance architecture provided by an embodiment of the present application;

FIG. 4 is a schematic flow diagram of a block chain-based network node control method provided by an embodiment of the present application;

FIG. 5 is a schematic structural diagram of a chip provided by an embodiment of the present application.

Detailed ways

The terms used in the following examples are for the purpose of describing particular examples only, and are not intended to limit the application. As used in the specification and appended claims of this application, the singular expressions "a", "an", "said", "above", "the" and "this" are intended to also Expressions such as "one or more" are included unless the context clearly dictates otherwise. It should also be understood that in the following embodiments of the present application, "at least one" and "one or more" refer to one or more than two (including two). The term "and/or" is used to describe the relationship between associated objects, indicating that there may be three relationships; for example, A and/or B may indicate: A exists alone, A and B exist at the same time, and B exists alone, Wherein A and B can be singular or plural. The character "/" generally indicates that the contextual objects are an "or" relationship.

Reference to "one embodiment" or "some embodiments" or the like in this specification means that a particular feature, structure, or characteristic described in connection with the embodiment is included in one or more embodiments of the present application. Thus, appearances of the phrases "in one embodiment," "in some embodiments," "in other embodiments," "in other embodiments," etc. in various places in this specification are not necessarily All refer to the same embodiment, but mean "one or more but not all embodiments" unless specifically stated otherwise. The terms "including", "comprising", "having" and variations thereof mean "including but not limited to", unless specifically stated otherwise. The term "connected" includes both direct and indirect connections, unless otherwise stated.

Hereinafter, the terms "first" and "second" are used for descriptive purposes only, and cannot be understood as indicating or implying relative importance or implicitly specifying the quantity of indicated technical features. Thus, a feature defined as "first" and "second" may explicitly or implicitly include one or more of these features.

In the embodiments of the present application, words such as "exemplarily" or "for example" are used as examples, illustrations or descriptions. Any embodiment or design solution described as "exemplary" or "for example" in the embodiments of the present application shall not be interpreted as being more preferred or more advantageous than other embodiments or design solutions. Rather, the use of words such as "exemplarily" or "for example" is intended to present related concepts in a concrete manner.

Generally, in a trust evaluation system, the network activities of nodes bound to identities can be monitored to evaluate their trust value, but when nodes use long-term identities for network activities, privacy disclosure may occur. Dynamically updated pseudonyms can be used to prevent attackers from tracking a node's network activity based on its identity. However, this trust evaluation system has flaws, such as inaccurate evaluation caused by changing the pseudonym, and unlinkability damage caused by the trust value link before and after the pseudonym change. In order to ensure accurate evaluation and unlinkability at the same time, some trust evaluation systems use trusted execution environment (TEE) to maintain node pseudonyms and trust values, but TEE has potential security vulnerabilities, such as side channel attacks. Some solutions use a trusted third party to manage pseudonyms and trust values, but such a trusted third party may not exist in practice. Other systems also use non-colluding entities to manage node pseudonyms and trust values within a single network, however, the assumption of the existence of such non-colluding entities within a single network may be unreasonable. In addition, in related technologies, most researches focus on a single network, but do not consider how to support a converged or heterogeneous network that includes multiple trusted domains.

The fifth generation mobile communication technology (5G) can realize the interconnection of everything, including various Internet of Things devices, such as vehicles and drones in the Internet of Vehicles. Mobile IoT devices may roam to other operators beyond the scope of the operator, resulting in cross-domain behavior. When the roaming device accesses the service operator after roaming, since the service operator does not trust the device (zero trust), the roaming device needs to be verified. Therefore, knowing its inter-domain trust value will help access service operators to adopt corresponding security defense adjustments, trust-based cross-domain routing, etc. However, there may be malicious network devices that do not cross domains in the domain. By evaluating and publishing their trust values, it will help decision-making in the domain, such as trust-based routing and security defense adjustments. With the commercialization of 5G, 6G is regarded as a large-scale heterogeneous network that integrates different types of networks or sub-networks, such as mobile cellular networks, the Internet, marine networks, and space-ground integrated networks. Therefore, we expect to be able to evaluate and publish the intra-domain and inter-domain trust values of network equipment in the converged network (6G).

The standards formulated by the 3rd generation partnership project (3GPP) also involve long-term identity (international mobile subscriber number, IMSI) protection of network devices, that is, guarantee of identity privacy. There are two ways to obtain the IMSI: the attacker obtains the IMSI by obtaining the channel of the victim network device; the attacker pretends to be a serving network (serving network, SN) and mutually authenticates with the victim device to obtain the IMSI. The IMSI protection method when a network device (user equipment, UE) accesses a service network mainly uses public key encryption, Root-key encryption, province-based encryption (identity-based encryption, IBE) and pseudonyms.

Among them, the IMSI method based on public key encryption mainly includes three methods: (1) Use the global root of trust to create a chain of trust, allowing the SN to display the certificate to the network device to be connected, and after the network device verifies the certificate, send the IMSI key to the SN. text, SN can decrypt to obtain IMSI for verification. (2) The SN obtains the certificate from the native network (HN) of the network device in advance, and the network device submits the HN public key when accessing so that the SN can find the certificate distributed by the HN locally; the SN shows the found certificate to the network device, and the network device After verification, encrypt the IMSI to the SN for verification. (3) The HN distributes the SN certificate that the network device may access to the network device in advance, and the network device uses the SN public key to encrypt the IMSI to the SN for verification. For method (1), it is difficult to establish a global root of trust in a converged network. For mode (2), when the SN does not store the certificate distributed by the HN of a certain network device, it means that the network device is locked. For (3), cross-domain behaviors are common in converged networks, and there may be many certificates stored in network devices. In the method based on Root-key encryption, the network device encrypts the IMSI with the public key of the HN and sends it to the SN. The SN sends the ciphertext to the HN to request decryption, and the HN returns the IMSI and the verification vector (AV); but whenever a network device is connected, this method requires the interaction between the SN and the HN, which may cause delay.

In the IBE-based method, it is usually assumed that the secret key generator (PKG) uses its own public-private key pair to calculate its public-private key in combination with the recipient's identity, so the network device and SN can use encryption and signature to authenticate each other. However, PKG can decrypt the ciphertext messages of all network devices and SN, and its trust degree is too high.

In the pseudonym-based approach, the HN gives new pseudonyms to network devices in a secure manner. The network device uses a pseudonym to access the SN, and the SN sends an encrypted message to the HN to request verification, and the HN returns the verification vector AV. However, in this method, once the network device is connected, the SN and the HN need to interact, thereby increasing the network delay.

In a converged network, different network operators do not trust each other. In the cross-domain scenario, we expect network nodes to provide their own trust value to the roaming network while maintaining node anonymity; when network nodes perform cross-domain network activities, we expect attackers to not be able to track their network activities through their identities, That is, the unlinkability of activities. In such a converged network, it is not feasible to use a trusted third party to manage the pseudonyms and trust values of all nodes, because it is difficult to find such an entity that is fully trusted by all network domains. There are also potential vulnerabilities in applying TEE. Therefore, in the case that network operators do not trust each other, different network operators can be promoted to collaboratively manage node pseudonyms and trust values in the converged network under untrustworthy conditions. The purpose of cooperation between network operators is to ensure the effectiveness of trust evaluation while protecting the privacy of node identities, especially in cross-domain networks.

Even though different network operators can cooperate, they may store and manage different node pseudonyms and trust values because they may use different trust data for trust evaluation. Therefore, how to effectively ensure that the managed node pseudonyms and trust values are consistent between operators who do not trust each other in the converged network becomes a challenge.

In order to solve the contradiction between trust evaluation and identity privacy protection, this scheme proposes a pseudonym and trust value management method for network nodes in a converged network (or 6G). In the inter-domain network, network operators cooperate to manage network node pseudonyms and corresponding trust values without relying on trusted third parties to provide high-quality network services. At the same time, this scheme ensures the unlinkability of node pseudonyms and the validity of trust evaluation through trust obfuscation and pseudonym update. After trust evaluation, trust obfuscation and pseudonym update of the trust list, the blockchain is used to ensure the consistency of the trust value list. In addition, the <inter-domain pseudonym, trust value> list is published through the blockchain to share information to assist in the decision-making of the inter-domain network. In the intra-domain network, since the intra-domain network nodes trust the local network operator, the operator is responsible for managing the local list of <intra-domain pseudonym, trust value>, including trust value update and list maintenance, so the local list can provide trust verification for the intra-domain network.

Two technologies are mainly used in this scheme, namely verifiable shuffling technology (hereinafter referred to as "Algorithm 1") and Byzantine Fault Tolerant Technology (hereinafter referred to as "Algorithm 2"), which are now introduced as follows:

(1) Verifiable shuffling technology

The purpose of the mixnet is to make communications difficult to track with the help of multiple anonymous servers. These anonymous servers take a list as input; encrypt, decrypt, and permutate list entries; and output a new list. Mixnets enable unlinkability of elements in the input list and elements in the output list. Among them, the shuffling of the hybrid network mainly includes operations such as encryption, decryption, and replacement.

Exemplarily, as shown in Figure 1, in the list _L0 , the first column consists of the long-term public key of the network node

, where _xi is the private key of network node NE _i . The second column of _L0 consists of the corresponding NE's trust value ciphertext

The ciphertext is obtained by encrypting the trust value plaintext TV _i with the selected long-term secret key z _j by the anonymous server. In the shuffle, anonymous server 1 encrypts the first column of list _L0 with a chosen ephemeral _e1 to obtain

decrypt

to get

And perturb the row containing the list of encrypted and decrypted results. It then sends the list it created to the next anonymous server 2 to be shuffled. Among them, g ₁ and g ₂ have been released. Finally, the first column of the output list _L2 contains the pseudonyms of all NEs,

The second column consists of the corresponding trust values TV _i . π(i) is the position of the i-th NE in _L2 .

In order to ensure the correctness of shuffling, many verifiable shuffling schemes have been proposed. In these schemes, the anonymous server should usually generate a zero-knowledge proof of the shuffling so that anyone can check that the shuffling (i.e., encryption, decryption, and permutation) was performed correctly. Algorithm 1 specifies a verifiable shuffling operation sh(L _j-1 , g _j-1 , e _j , z _j ) for anonymous server j, which then sends its generated result to the next anonymous server j+ 1 to shuffle. The generated results include a proof pf _j to convince anyone that the shuffling was performed correctly. The proof needs to be constructed according to the specific encryption algorithm. If m anonymous servers finish shuffling, then the element in the first column of the final output list L _m is the pseudonym of the i-th NE,

The element TV _i in the second column is the plaintext of the trust value of the corresponding NE. The i-th NE uses the published

to calculate its pseudonym

and use that pseudonym for online activities. In particular, the i-th NE is able to sign a message M using its private key _xi and a randomly picked number k, (r=g _m ^k , s=(H(M) _−xi r)k ⁻¹ ). Anyone can verify this signature by checking g _m ^H(M) = pk _π(i) ^r r ^s .

For ease of understanding, the following example describes the verifiable shuffling operation sh(L _j-1 , g _j-1 , e _j , z _j ) of the anonymous server j in the verifiable shuffling technology. As shown in Table 1, in the verifiable shuffling operation sh(L _j-1 , g _j-1 , e _j , z _j ), the input is: e _j , z _j , L _j-1 ,

The output is: L _j ,g _j ,pf _j . Among them, the execution process is: after the anonymous server j receives the certificate pf _j-1 , it can verify the received certificate pf _j-1 , and after the verification is passed, use e _j to encrypt the received list L _j-1 The first column of elements,

Then, decrypt the second column element of L _j-1 to obtain

Next, replace the rows of the result list to obtain a new list L _j ; calculate

And create a proof pf _j to prove that the above operation is correct. Finally, return L _j , g _j , pf _j and end.

Table 1

(2) Byzantine fault tolerance technology

The consensus mechanism in practical byzantine fault tolerance (PBFT) mainly includes the stages of block manufacturing, pre-prepare, prepare and commit.

Among them, in the block manufacturing stage, the confirmed next block maker (leader) is mainly responsible for packaging the next block. In the pre-preparation stage, the master node (leader) sends the manufactured blocks to all consensus nodes. The preparation phase is mainly when the consensus nodes receive the block, they first complete the block verification, and then create and broadcast a prepare (prepare) message to all consensus nodes. When the consensus node receives more than 2f (the system contains 3f+1 consensus nodes) consistent effective prepare (prepare) messages, the node is ready to enter the confirmation phase. The confirmation phase is mainly that if a consensus node starts to enter the confirmation phase, it generates a confirmation (commit) message and announces it to all consensus nodes; at the same time, the consensus node receives confirmation messages from other consensus nodes; when the consensus node receives more than 2f After the consistent valid confirmation message, it will consider the end of the confirmation phase and save the corresponding block as the next block of the blockchain. During the whole process, when the non-leader consensus node perceives that the leader consensus node is doing evil, such as creating an invalid block or timeout, it will trigger a view switch (viewchange) to re-select a new leader consensus node.

Exemplarily, the node pseudonym and trust value management method provided by this solution mainly uses encryption technology (such as verifiable shuffling) to safely manage the pseudonym and trust value of all nodes in the converged network under the condition that they are guaranteed to be unlinkable. This method can be used in intra-domain and inter-domain trust evaluation systems.

Among them, in intra-domain networks, network nodes can trust local operator proxies because they are in the same trusted domain. Therefore, the local operator agent is responsible for evaluating intra-domain node trust and managing intra-domain node pseudonyms and trust values. First, the proxy creates an intra-domain list containing <in-domain pseudonym, trust value> pairs based on the long-term public key of the network node. Then, each network node obtains public information from the proxy to calculate its intra-domain pseudonym, and uses this pseudonym for intra-domain network activities. The data collector senses the trust-related data of the network nodes connected to it, and shares the data with the agent. After receiving the intra-domain trust data, the agent evaluates the intra-domain trust of each network node and updates the intra-domain trust value list. After several rounds of trust evaluation, the agent re-evaluates the trust of each pseudonym in the list according to time decay, maintains the list through trust obfuscation and pseudonym update, to achieve unlinkability of activities within the domain.

In the inter-domain network, operator agents of different networks cooperate to maintain a trust list containing the pair of <inter-domain pseudonym, trust value>. These operator agents reach blockchain consensus on a list generated using a verifiable shuffle to produce the genesis block. In a verifiable shuffle, node pseudonyms appear in the form of a ciphertext that is generated by cooperative encryption of the corresponding node's long-term public key by all operator agents using a chosen ephemeral or ephemeral key. After reaching a consensus on the genesis block, each network node accesses public information from the blockchain to calculate its inter-domain pseudonym, and uses this pseudonym for cross-domain network activities. After that, it is necessary to update the trust value of the nodes in the list in real time according to the network behavior of the nodes.

In addition, in the inter-domain network, the data collector can perceive inter-domain trust data and share these data to the public cloud storage server. By authorizing access to these data, an operator agent (leader in the PBFT consensus mechanism) will evaluate the inter-domain trust of each node, and share the evaluation results with other operator agents for verification through the blocks it creates. In addition, the leader proxy acts as the next block creator, generating and publishing a block that includes the updated inter-domain trust list of the evaluation results. Other operator agents participate in the PBFT consensus mechanism to verify the block and make it the next block of the blockchain. Therefore, after each round of inter-domain trust evaluation, the operator agent will update the trust value corresponding to the pseudonym in the inter-domain list. To prevent attackers from tracking a node's cross-domain activities based on its cross-domain pseudonym, the pseudonym should be changed after several rounds of inter-domain trust evaluation. Each operator agent needs to re-evaluate the trust of each pseudonym in the list based on the trust list in the next block of the backup blockchain according to time decay, and confuse the trust value to prevent attackers from tracking the node by analyzing the trust value Old and new pseudonyms (thus breaking unlinkability). After trust obfuscation, the operator agent performs the reverse operation of shuffling to obtain a list of ciphertexts containing the long-term public key of the node and the obfuscated trust value, and then uses the newly selected temporary key to cooperate with forward shuffling to encrypt the long-term Public key for pseudonym update. Therefore, a new list containing the new pseudonym and obfuscated trust value is successfully created. After generating a new list, each operator proxy should create a block containing this list and consider this block as the next block in the blockchain. Afterwards, each network node can access public information from the blockchain to calculate its new pseudonym, and use the pseudonym for cross-domain network activities, and the inter-domain trust value is later updated according to the behavior corresponding to the new pseudonym.

Exemplarily, Fig. 2a shows an application scenario of an inter-domain network according to an embodiment of the present application. In this scenario, at least two networks may be included, namely the network 100 and the network 200 , and the cloud server 300 . In the network 100, four kinds of entities can be included, namely, a network node (network entity, NE) 110, an access node (access point, AP) 120, and an operator agent (operator agent, OA) 130; in the network 200, it can also include Four entities, namely NE210, AP220 and OA230.

Wherein, in the network 100, the NE110 can use a pseudonym to connect to the AP120 to carry out activities, especially cross-domain activities. NE110 may perform malicious actions and is not trusted. In a converged network, their trust needs to be evaluated and shared to help other network entities make decisions. Exemplarily, the NE may include terminal devices such as mobile phones and computers.

In the network 100, the APs 120 can monitor the NEs 110 connected to them. AP120 can be used as a data collection node to share the perceived intra-domain trust data of each NE to OA130 to help OA130 perform subsequent intra-domain trust evaluation; share cross-domain trust data to the common cloud server 300 of the converged network for subsequent cross-domain Trust assessment. Exemplarily, the security status of AP 120 can be checked by OA 130, or even other OAs, such as through software-defined networking. Exemplarily, the AP may include a base station and the like.

In the network 100, the OA130 is deployed by the network operator, and it is responsible for the NE in the domain (such as the NE110 in the network 100) and/or the NE in the domain (such as the NE210 in the network 200) according to the trust data from the AP120 or the server 130. Trust evaluation; manage the list of <pseudoname, trust value> of all NEs; participate in the PBFT consensus mechanism. OA130 is trusted in its network or domain, but not trusted by OAs of other domains (such as OA230). Exemplarily, there is at least one OA that does not collude with OAs in other domains. In an example, the operator agent OA may also be called an operator server.

The cloud server 300 may also be referred to as a cloud service provider (cloud service provider, CSP), which may be, but not limited to, be located in a common cloud of the Internet and a converged network. It can collect cross-domain trust data provided by different APs (such as AP110 and/or AP210, etc.) from different domains; it allows OAs (such as OA130 and/or OA230) to obtain cross-domain trust data for cross-domain trust evaluation. Exemplarily, the cloud server 300 may honestly execute a predetermined protocol, for example, be interested in sensitive information of each NE, such as real identity, pseudonym of tracking node or network behavior, and so on. In an example, the cloud server 300 may also be called a cloud server.

It can be understood that the NE210 in the network 200 is similar to the NE110 in the network 100 in function or role, the AP220 in the network 200 is similar to the AP120 in the network 100 in function or role, and the OA230 in the network 200 is similar to that in the network 100. The functions or effects of the OA130 are similar, see the description of the NE110, AP120 and OA130 in the network 100 for details, and will not be repeated here.

In one example, each network entity in the network can have a pair of long-term public-private key pairs. Wherein, the network entities in the network may include one or more of a network node NE, an access node AP, an operator agent OA, and the like. In addition, the server 130 may also have a long-term public-private key pair.

In an example, communication can also be performed between the network 100 and the network 200 . Exemplarily, the OA 130 in the network 100 can communicate with the AO 230 in the network 200 .

Exemplarily, Fig. 2b shows another application scenario of an inter-domain network according to an embodiment of the present application. In this scenario, there are three types of networks, namely the cellular mobile communication network, the space-ground integrated network, and the Internet. Each network may include three types of network entities, namely, a network node NE, an access point AP, and an operator proxy AP. In addition, cloud service providers may also be included in the Internet. All networks can communicate with each other.

Exemplarily, FIG. 3 shows a schematic diagram of an inter-domain pseudonym and trust maintenance architecture. In Fig. 3, operator A can be the operator of the network 100 shown in Fig. 2a, the blockchain consensus node 1 can be the operator agent OA130 in the network 100 shown in Fig. 2a, and the data collection node 1 can be is the access point AP120 in the network 100 shown in FIG. 2a, the device 1 may be the network node 110 in the network 100 shown in FIG. 2a; the operator B may be the operator of the network 200 shown in FIG. 2a , the blockchain consensus node 2 can be the operator agent OA230 in the network 200 shown in Figure 2a, the data collection node 2 can be the access point AP220 in the network 200 shown in Figure 2a, and the device 2 can be The network node 210 in the network 200 shown in Fig. 2a; the data storage node 1 may be the cloud server 300 shown in Fig. 2a. In Fig. 3, the data collection node 1 can sense (also called "obtain") the behavior data of the device 1, and upload the perceived data to the data storage node 1, and the data collection node 2 can sense (also called "obtain") the behavior data of the device 1 "Acquire") the behavior data of the device 2, and upload the perceived data to the data storage node 1. Blockchain consensus node 1 and/or blockchain consensus node 2 can obtain the behavior data of device 1 or device 2 from data storage node 1, and can be responsible for generating the pseudonym and trust value of device 1 and/or device 2 and maintenance, and is responsible for reaching a consensus between the blockchain nodes; among them, after the two reach a consensus, at least one block can be generated, which can contain the corresponding relationship between the pseudonym and the trust value, that is, <pseudoname, Trust Values > List. Both device 1 and/or device 2 have a pair of public and private keys (PK _i , SK _i ), and PK _i is the permanent identity ID of the device. Both can obtain a pseudonym from the block, and use the obtained pseudonym for network Activity.

Next, the pseudonym and trust value management method in the inter-domain network provided by this solution is introduced.

Pseudonym and trust value management in the inter-domain network can include inter-domain list generation, trust value update & inter-domain consensus, and inter-domain list maintenance. In the inter-domain list generation process, operator agents OA in different domains collaboratively generate lists through verifiable shuffling to store inter-domain <pseudonym, trust value> pairs. In trust value update & inter-domain consensus, the operator agent OA can perform trust evaluation based on enough cross-domain trust data regularly shared by the access point AP, only update the trust value in the inter-domain list, and update the updated list Reach a consensus. After K ₂ rounds of consensus, the operating agent OA can maintain the inter-domain list through trust confusion and update pseudonyms based on verifiable shuffling to ensure the unlinkability of pseudonyms, that is, perform inter-domain list maintenance.

The following introduces the inter-domain list generation, trust value update & inter-domain consensus, and inter-domain list maintenance. Among them, it can be assumed that each NE in each network has registered and has its own public-private key pair

And all operator agents OA know each NE's long-term public key y _i . Each operator agent OA holds its own public-private key pair

Furthermore, at least one operator generation OA will not collude with other operator generation OAs.

(1) Inter-domain list generation

Inter-domain list generation may include: generation of an initial list L ₀ and generation of a target list L _m .

a) Initial list L ₀ generation

m operator agents OA create a list containing the public keys of n network nodes NE <pseudonym, trust value>, where each network node NE is equipped with a public-private key pair

Different operator agents OA can cooperate to use their respective long-term keys z _j to encrypt the initial trust value, for example, the initial trust value (trust value, TV) of each network node NE can be preset, For example, the initial trust value TV _i =0.01.

In order to avoid the situation that the encryption result is not the ciphertext of TV _i =0.01, each OA can be required to issue a message to prove that its encryption operation is correct, which can be regarded as a verifiable shuffling variant of only the encryption operation. when guaranteed

is correct, then one operator agent OA ₁ among the m operator agents constructs an operator agent consisting of

Form the list L ₀ . Exemplarily, the list L ₀ can be as shown in Table 2, ID in Table 2 can refer to a pseudonym, TV can refer to a trust value; in the initial list L ₀ , the pseudonym can be the public key of the network node NE, and the trust value can be In order to use the public keys of m OAs to encrypt the initial trust value TV _i based on the preset encryption order, the obtained

Table 2

In one example, at least one OA among the m operator agent OAs can use the public keys of the m OAs to encrypt the initial trust value TV _i sequentially based on the preset encryption order, and obtain

And send the obtained result to OA ₁ .

b) target list L _m generation

Combined with Figure 1, and according to Algorithm 1, OA ₁ selects a temporary random number e ₁ , and executes sh(L ₀ , g ₀ , e ₁ , z ₁ ) to obtain the results L ₁ , g ₁ and pf ₁ , where g ₀ =g. OA ₁ broadcasts L ₁ , g ₁ , pf ₁ and a signature

After receiving the information from OA ₁ , OA ₂ verifies the signature and proves pf ₁ , and executes sh(L ₁ , g ₁ , e ₂ , z ₂ ) to obtain the results L ₂ , g ₂ and pf ₂ . Similarly, OA ₂ broadcasts its result and signature, and so on, until the process reaches OA _m . OA _m verifies the received signature and certificate, and executes sh(L _m-1 , g _m-1 , e _m , z _m ) to obtain the information including pk _π(i) , TV _π(i) >, i=1,. .., the list L _m of n,

and pf _m . π(i) is the position of the i-th NE's pseudonym in the list _Lm . Finally, OA _m publishes L _m , g _m and pf _m for public verification of the shuffling. Anyone (including OA) can check the correctness of shuffling. Since at least one OA will not collude with other OAs, an attacker cannot link L ₀ to L _m . It can be understood that g is the record of the global parameter e, which is mainly used to record the random number e of each OA, for example,

After verifying the correctness of shuffling, each OA can calculate the root of the Merkle tree constructed by L _m and g _m . After that, at least one of the OAs can pack the root, L _m and g _m into a block, which is considered as the genesis block of the blockchain. The i-th NE calculates its pseudonym through its private key x _i and g _m obtained from the blockchain

And check whether pk _π(i) exists in L _m by accessing the blockchain. If it exists, the i-th NE can use this pseudonym for cross-domain network activities; if it does not exist, the i-th NE cannot use this pseudonym for cross-domain network activities.

(2) Trust value update & inter-domain consensus

a) Trust value update

The operator agent OA can evaluate and update the trust value of each NE in real time or periodically. Among them, the OA can be based on the trust data of each NE provided by the AP and stored in the server and the trust value recorded in the latest updated L _m

Compute a new trust value for each NE.

In one example, a new trust value for each NE may be calculated based on a preset behavior template. For example, the behavior template P={P _N , _PA } can be used to evaluate the trust value of the monitored network node. Among them, _PN is a normal behavior template set, _PA is an abnormal behavior template set. For the behavior feature set B={B ₁ ,...,B _I } of the i-th network node, if there are I _N behavior features in the behavior feature set B matching the template in P _N , and I _A behavior Matches the template in _PA , then the trust value of the network node is:

where u _π(i) is the sequence number of the last evaluated block in the blockchain. I _A is the number of normal behaviors, I _N is the number of abnormal behaviors, and k is a constant. u is the serial number of the current trust evaluation block, τ is a parameter controlling time decay,

is the trust value of the i-th NE obtained from the last evaluation.

After getting the new trust value, OA can replace the old trust value of each NE in the target list L _m with the new trust value.

b) Inter-domain consensus

Based on the PBFT consensus mechanism, the operator agent OA can agree on the updated list of trust evaluation and trust value. PBFT-based inter-domain consensus can be divided into block manufacturing, PrePrepare, Prepare and Commit stages.

Block manufacturing stage: This stage is mainly completed by the Leader consensus node (that is, the master node). As shown in Table 3, Algorithm 2 shows the process of the Leader consensus node completing the block production. Exemplarily, the consensus node can be understood as an operator agent OA.

table 3

In one example, after other consensus nodes receive the block announced by the Leader consensus node, other consensus nodes can obtain trust data TD _i (i=1,..., _nd ) by accessing the cloud service provider, and Calculate the trust evaluation result, and check whether the calculated trust evaluation result is consistent with the trust result in the list L _m , so as to confirm the correctness of the update of the list L _m and the correctness of the block content.

PrePrepare phase: In this phase, the Leader consensus node can send the blocks it makes to all consensus nodes.

Prepare phase: If the consensus nodes receive the block, they first need to complete the verification of the block, and then create and broadcast a Prepare message to all consensus nodes. When the consensus node receives more than 2f (the system contains 3f+1=m consensus nodes) consistent and effective Prepare messages, the consensus node is ready to enter the Commit phase.

Commit phase: If a consensus node starts to enter the Commit phase, it will generate a Commit message and announce it to all consensus nodes. At the same time, the consensus node receives Commit messages from other consensus nodes. When the consensus node receives more than 2f consistent and effective Commit messages, it considers the end of the Commit phase and saves the corresponding block as the next block of the blockchain.

Similarly, when the consensus node detects the malicious behavior of the Leader consensus node or times out, it will start the viewchange mechanism to re-select a new Leader consensus node.

(3) Inter-domain list maintenance

After several rounds of trust evaluation and consensus (such as K rounds), the old list can be maintained and modified to prevent attackers from tracking the activities of network nodes for a long time. Between maintaining and modifying the old list, only the trust value of the network node can be updated without updating the pseudonym of the network node. Among them, the reason why the old list will not be maintained after each round of trust evaluation is to ensure the efficiency of the entire network system. But K can be set to 1 to ensure the highest degree of unlinkability.

Interdomain list maintenance can consist of three phases: trust obfuscation, pseudonym update, and new list addition. Described below respectively.

Trust confusion: At this stage, when the old list needs to be maintained, if only the pseudonym of the old list is changed, the attacker may link the two pseudonyms of a certain network node in the old and new lists through trust value analysis, which destroys the network node. privacy and list maintenance goals.

In one example, when at least two pseudonyms in the old list have a high probability of having the same trust value, it can make it difficult for an attacker to track NE's network activities or pseudonyms for a long time by analyzing the NE's trust value. Therefore, it can be considered to increase this probability through trust obfuscation, thereby enhancing unlinkability.

Specifically, before trust confusion, due to time decay, the trust value of each network node NE can be re-evaluated:

in,

is the trust value of the i-th NE in the old list, u _π(i) is the serial number of the block obtained from the last evaluation in the blockchain, u is the serial number of the block currently evaluated for trust, and τ is the control time Decay parameters.

After updating the trust value of each NE according to time decay, trust obfuscation can be performed to enhance the unlinkability of old and new pseudonyms.

As a possible implementation manner, at least one interval may be preset. When the number of trust values of network nodes NE falling into a certain interval exceeds the preset value, all trust values in the interval can be adjusted to the same trust value, or most of them can be adjusted to the same trust value. In this way, at least two pseudonyms in the list have the same trust value, which makes it difficult for an attacker to track the network activities or pseudonyms of the NE for a long time by analyzing the trust value of the NE. In addition, when the number of trust values of network nodes NE falling into a certain interval does not reach the preset value, the range of the interval can be adjusted so that the number of trust values of network nodes NE falling in the interval reaches the preset value. set value.

Exemplarily, it is assumed that the interval range of the preset trust value is 0 to 1. If xN _TV ≥ TV _π(i) > (x-1)N _TV , all OAs calculate and change TV _π(i) = (x-1)N _TV to achieve trust confusion. Wherein, N _TV is a new unit greater than the trust value unit (for example, 0.01), and χ is an integer. Then after trust confusion, the probability that a pseudonym has the same trust value as other pseudonyms will increase. Although there may still be a one-to-one correspondence between some trust values and pseudonyms in the trust obfuscated list, after multiple rounds of maintenance, the probability that an attacker can always successfully track NE will be greatly reduced, almost to zero.

It can be understood that, in order to quantify the ability of trust confusion, it can be assumed that the trust value of the network node NE obeys a Gaussian distribution, and an extreme case is considered. Before trust obfuscation, the number of pseudonyms with trust values ranging from 0.09 to 1 is expected to be

where n is the number of pseudonyms in the list waiting to be maintained, and p(t) is the probability density function of the Gaussian distribution. After trust confusion, the new expectation is

because

Anonymity is enhanced. Just make sure by adjusting N _TV

Anonymity can be achieved. After trust obfuscation, some trust values and pseudonyms in the list may still have a one-to-one correspondence with a very small probability. According to K anonymity, the probability of tracking a pseudonym is

However, after R rounds of maintenance, the pseudonym probability that the attacker can always track NE is

Therefore, when N _TV and R are large enough, p will tend to 0, implying that it will be very difficult for an attacker to break pseudonyms or unlinkability of network activities. We reduced the precision of the trust value for stronger unlinkability. It is worth noting that similar results can also be obtained when the trust value obeys other distributions, because the integral interval will become larger after trust confusion.

Pseudonym update: After trust obfuscation, the OA can reversely perform target list L _m generation on the obfuscated trust list to obtain a list containing each NE's long-term public key and corresponding trust value ciphertext

In order to update the pseudonym of each NE, the OA can choose a new ephemeral private key

Then perform target list L _m generation to obtain a new list

the new list

Consists of a new pseudonym and an obfuscated trust value.

New list added: when each OA gets a new list

and new

OA can add it to the blockchain when Specifically, each OA computes

and

The root of the Merkle tree is composed of the hash value of the previous block, the serial number of this block, the root of the Merkle tree,

and the signature on the content of the block are packaged into a block, which is regarded by OA as the next block of the blockchain.

As a result, network nodes can share the trust value when roaming between different operators, and at the same time, can effectively protect the user's privacy, and prevent the user from being attacked to obtain the user's real identity through the trust value.

Compared with related technologies, this solution adopts blockchain technology, which avoids the difficulties faced by related technologies, such as the acquisition of trusted third parties, and the side channel attacks faced by using TEE to protect user privacy. At the same time, by using the trust value to confuse, the attacker can avoid the problem of tracking the user through the continuity of the trust value.

The above is the method for managing pseudonyms and trust values in the inter-domain network. This method can also be applied to the management of pseudonyms and trust values in the intra-domain network, as follows:

In intra-domain management, the local operator agent OA creates a list by shuffling cards to record <pseudoname, trust value> pairs in the domain. This process is called intra-domain list generation. Then, the local operator agent OA performs intra-domain trust value update. Based on the intra-domain trust data provided by the access point AP periodically (for example, every 10 minutes), the local operator agent OA performs trust evaluation, and only updates the trust value of the network nodes in the intra-domain list according to the evaluation result. After K ₁ rounds of trust value update, the local operator agent OA can maintain the list. The local operator agent OA can update the intra-domain pseudonym of the network node through trust confusion and shuffle-based pseudonym update. This stage can be called intra-domain list maintenance. These stages are described below.

(1) In-domain list generation

a) Initial list L ₀ generation

Since the local operator agent OA in the domain is trusted, the local operator agent OA can directly generate the list. The local operator agent OA can create a <pseudoname, trust value> list involving the local n network nodes. The local operator agent OA can use its own long-term key z to encrypt the initial trust value of each network node NE, for example, TV _i =0.01 for each NE, to obtain E _z (TV _i ). Afterwards, the local operator agent OA constructs a list L ₀ consisting of <y _i , E _z (TV _i )>, i=1, . . . , n.

b) target list L ₁ generation

The local operator agent OA can randomly select a transient random number e, and execute Algorithm 1 to obtain and publish the result L ₁ , where g ₁ = ^ge . Since the local operator agent OA is considered trusted in the domain, there is no need for the local operator agent OA to create and issue a message attesting to the correct operation.

Likewise, each network node NE can use its private key and published _g1 to calculate its pseudonym and check whether its pseudonym exists in the list. It can then use the pseudonym for intra-domain network activity.

(2) Trust value update

The local operator agent OA can perform trust evaluation according to the trust data related to the local network node NE provided by the local AP, and update the trust value of the network node in _L1 according to the corresponding pseudonym.

where T _π(i) is the time of the last trust evaluation. I _A is the number of normal behaviors, I _N is the number of abnormal behaviors, and k is a constant. T is the time of the current trust evaluation, τ is a parameter controlling the time decay,

is the trust value of the i-th NE obtained from the last evaluation.

After getting the new trust value, OA can replace the old trust value of each NE in the target list _L1 with the new trust value.

(3) Domain list maintenance

After several rounds of trust evaluation, the local operator agent OA can maintain the list to prevent attackers from tracking network nodes for a long time. Since the trust value decays with time, the local operator agent OA can re-evaluate the trust value of each NE in the list, and perform trust obfuscation, and then reversely execute the generation of the target list L ₁ on the trust obfuscated list to obtain the list containing NE List of public keys and corresponding trust value ciphertexts for

Then, the local operator agent OA selects a temporary random number e ^new and generates it by executing the target list L ₁ to update the pseudonym, the process gets

and the new list

Contains new pseudonym and obfuscated trust values. Local operator agent OA release

and

NE can use

calculate its pseudonym

and check

Does pk _π(i) exist in for intra-domain network activities.

As a result, when a network node conducts network activities between the same operator, it can effectively protect the privacy of the user and prevent the user from being attacked by the user to obtain the user's real identity through the trust value.

Based on the above description, it can be known that this solution has at least the following advantages:

(1) Decentralization

This scheme allows the operator agent to manage the pseudonym-trust value list without relying on any fully trusted third party in the inter-domain. Operations such as shuffling, trust evaluation, trust confusion, and pseudonym update of each agent can be verified by other agents through the blockchain PBFT consensus mechanism, thereby ensuring the consistency of the management list and realizing the decentralization of list management.

(2) Credible information sharing

Applying the blockchain to the inter-domain network, all operator agents store and record the blockchain containing a new list of pseudonyms and trust values, and the information on it can be publicly obtained to allow network nodes to achieve trust by accessing the blockchain Value validation and decision making, such as trusted routing. In the intra-domain network, the local operator agent manages a list containing <pseudonym, trust value>, allowing intra-domain network nodes to access and obtain. Therefore, trusted information sharing is achieved in both intra-domain and inter-domain networks.

(3) Privacy Protection

This scheme allows network nodes to use pseudonyms instead of real identities in network activities within and within domains. By using pseudonyms, anonymous trust assessments can be achieved. At the same time, the present invention can also ensure the unlinkability of pseudonyms or activities.

(4) Application in Converged Network

Each network's operator proxies cooperate to maintain a list containing pseudonyms and corresponding trust values. Specifically, when network nodes have cross-domain behaviors, the collaboration among operator agents can solve the problem caused by distrust between network domains, thereby achieving global anonymous trust evaluation and sharing.

Next, based on the pseudonym and trust value management method of network nodes described above, a block chain-based network node control method provided by the embodiment of this application is introduced. It can be understood that this method is another way of expressing the pseudonym and trust value management method of the network node described above, and the two are combined. This method is proposed based on the pseudonym and trust value management method of network nodes described above, part or all of the content of this method can be found in the above description of the pseudonym and trust value management method of network nodes.

Please refer to FIG. 4 . FIG. 4 is a schematic flowchart of a blockchain-based network node control method provided by an embodiment of the present application. It can be understood that the method can be executed by any device, device, platform, or device cluster that has computing and processing capabilities. In this method, the blockchain includes a first consensus node and a second consensus node, wherein the first consensus node corresponds to the first server in the first network, and the second consensus node corresponds to the second server in the second network, Both the first network and the second network include at least one network node. Exemplarily, the first network may be the network 100 shown in FIG. 2a, the second network may be the network 200 shown in FIG. 2a, and the first consensus node (that is, the first server) may be the network shown in FIG. 2a The operator agent OA130, the second consensus node (that is, the second server) may be the operator agent OA230 shown in FIG. 2a.

As shown in Figure 4, the blockchain-based network node control method may include the following steps:

S401. The first consensus node obtains the first block, the first block includes the first target list, and the first target list includes the first target virtual ID and the first target virtual ID corresponding to each network node in the first network and the second network. Target trust value, wherein the first target virtual identity is used to characterize the identity of the network node, the first target virtual identity is different from the real identity of the network node, and the first consensus node and the second consensus node are based on the real identity of the network node The identification is obtained, and the first target trust value is used to characterize the degree of trust of the network node in the network where it is located.

Specifically, the first consensus node can obtain the first block from the blockchain, and the first block can be the first block in the blockchain, that is, the genesis block, or it can be the first block of the first consensus node The block generated last time can also be the block generated by the second consensus node.

In an example, the first block includes a first target list, and the first target list includes first target virtual identifiers and first target trust values corresponding to network nodes in the first network and the second network, wherein the first A target virtual identifier is used to represent the identity of the network node. The first target virtual identifier is different from the real identity of the network node, and is obtained by the first consensus node and the second consensus node based on the real identity of the network node. The first target trusts The value is used to characterize the degree of trust of the network node in the network in which it is located. Wherein, the first target list may be, but not limited to, generated by the first consensus node and the second consensus node based on the verifiable shuffling algorithm described above (ie, Algorithm 1). Exemplarily, the first target list may be the target list L _m described above. Exemplarily, the first target virtual identifier may be the pseudonym of the network node described above, and the real identity identifier of the network node may be the public key of the network node or the like.

In an example, when obtaining the first block, the first consensus node can determine the first initial list, which includes the real identity of each network node and the first trust value corresponding to each network node, the first The trust value is obtained by encrypting the trust value corresponding to each network node in the first target list by the first consensus node and/or the second consensus node. Exemplarily, the first initial list may be the initial list L ₀ described above, and the real identity of the network node may be the public key of the network node. The first trust value corresponding to each network node can be obtained by sequentially using the public keys of the first consensus node and the second consensus node to encrypt the initial trust value of each network node based on a preset encryption sequence. Exemplarily, the public key of the first consensus node can be

The public key of the second consensus node can be

The initial trust value of each network node is TV _i , then the first trust value of each network node is

Next, the first initial list can be processed between the first consensus node and the second consensus node based on a verifiable shuffling algorithm to obtain the first target list. Specifically, the first consensus node can respectively encrypt the real identity of each network node based on the first key to obtain the first virtual ID corresponding to each network node, and decrypt the first trusted ID corresponding to each network node based on the second key. values to obtain the second trust value corresponding to each network node, where each first virtual identity and the second trust value corresponding to each first virtual identity form a second initial list. Exemplarily, the first key may be a temporary random number generated by the first consensus node. Exemplarily, the second key may also be a temporary random number generated by the first consensus node, or a public key of the first consensus node. Exemplarily, the first consensus node may be OA1 described above.

Then, the first consensus node may send the second initial list to the second consensus node. Afterwards, the second consensus node may respectively encrypt the first virtual identifier corresponding to each network node based on the third key to obtain the first target virtual identifier, and decrypt the second trust value corresponding to each network node based on the fourth key, The first target trust value corresponding to each network node is obtained, wherein each first target virtual identity and the first target trust value corresponding to each first target virtual identity form a first target list. Exemplarily, the third key may be a temporary random number generated by the second consensus node. Exemplarily, the fourth key may also be a temporary random number generated by the second consensus node, or a public key of the second consensus node. Exemplarily, the second consensus node may be the OAm described above.

Then, the second consensus node can send the generated first target list to the first consensus node.

Finally, the first consensus node can generate the first block based on the first target list, and store the first block in the blockchain. Exemplarily, the first consensus node and the second consensus node can calculate the first target list (such as L _m described above), global parameters related to the first consensus node and the second consensus node (such as g _m ) is the root of the constructed Merkle tree. Afterwards, the first consensus node can pack the root, the first target list, and global parameters related to the first consensus node and the second consensus node into a block, that is, the first block is obtained.

S402. When the first consensus node satisfies the first preset condition, update the trust value of each network node in the first target list to obtain the second target list, and generate a second block based on the second target list, wherein, The second block includes a second target list.

Specifically, when the first consensus node satisfies the first preset condition, the trust value of each network node in the first target list is updated to obtain the second target list, and the second block is generated based on the second target list, wherein , the second block includes the second target list. Exemplarily, the first preset condition may be a preset duration.

In an example, the first consensus node can obtain the behavior data of each network node within a preset period of time. Exemplarily, the behavior data of each network node within a preset period of time can be stored on a cloud server (such as the server 300 described above), so that the first consensus node can obtain the preset data of each network node from the cloud server. Behavioral data over time.

Next, the first consensus node can determine the second target trust value corresponding to each network node based on the behavior data corresponding to each network node, the preset time decay coefficient and the first target trust value corresponding to each network node. Exemplarily, the second target trust value corresponding to each network node may be determined based on the "Formula 1" described above. Wherein, the normal behavior template set P _N and the abnormal behavior template set P _A of each network node can be determined based on the behavior template P and the behavior data.

Finally, after determining the latest trust value of each network node, the first consensus node can update the first target trust value in the first target list to the second target trust value, that is, obtain the second target list.

Further, after the first consensus node obtains the second target list, it can package the second target list into a second block based on the block manufacturing process described in "Table 3" above.

S403. The first consensus node sends the second block to the second consensus node.

Specifically, after the first consensus node packs the second target list into a second block, the first consensus node can send the second block to the second consensus node.

S404. The second consensus node acquires the second block, and verifies the second block.

Specifically, after the second consensus node obtains the second block, it can verify the second block. Exemplarily, the second consensus node may recalculate the trust value of each network node, and compare the calculated trust value with the trust value in the second target list contained in the second block to determine whether the two are consistent, Therefore, the correctness of updating the second target list and the correctness of the content in the second block are confirmed.

S405. When the verification passes, the second consensus node sends a first message to the first consensus node, where the first message is used to indicate that the verification of the second block passes.

Specifically, when the second consensus node passes the verification, it may send to the first consensus node a first message indicating that the second block has passed the verification.

S406. The first consensus node stores the second block in the blockchain in response to the acquired first message.

Specifically, after the first consensus node obtains the first message sent by the second consensus node, it can store the second block in the blockchain. In this way, each network node can access the block from the blockchain, and obtain a list of pseudonyms and trust values, and then check whether its real identity exists. , the corresponding network node can use this pseudonym for cross-domain network activities; if it does not exist, the corresponding network node cannot use this pseudonym for cross-domain network activities.

In one example, after the first consensus node stores the second block in the blockchain, the device (such as a mobile phone and other network nodes) can obtain the pseudonym and trust of the device from the blockchain when performing network activities. value. Then, when the device sends a message, it can sign the message with its own private key and carry a pseudonym in the message. Then, nodes on the network side (such as network elements such as base stations and routing devices) can use the pseudonym to verify the signature contained in the message sent by the device, and after verification and confirmation, use the pseudonym to obtain the trust value corresponding to the pseudonym from the blockchain , and conduct further business activities based on the trust value, such as whether to allow the device to use a certain service, etc. Exemplarily, the node on the network side may use the ElGamal algorithm to verify the signature contained in the message sent by the device using a pseudonym.

Therefore, after a consensus node updates the trust value of the network node, another consensus node uses the PBFT consensus mechanism of the blockchain to verify the updated trust value, thereby ensuring the consistency of the management list and realizing the decentralization of list management , so that each consensus node can trust each other, so as to realize global anonymous trust evaluation and sharing. At the same time, each consensus node can record the updated list, so that the network nodes corresponding to each consensus node can realize trust value verification and decision-making by accessing the blockchain.

In one example, when the first consensus node satisfies the second preset condition, the trust values corresponding to at least two network nodes in the second target list can be updated to the third target trust value, and the third target trust value is obtained. target list. Exemplarily, the second preset condition may be after K rounds of trust value updates. Exemplarily, this step can be understood as the trust confusion stage in the inter-domain list maintenance process described above.

Next, the first consensus node can obtain a third initial list based on the third target list. The third initial list includes the real identity and the third trust value corresponding to each network node. The third trust value is based on the first consensus node and/or Or the second consensus node encrypts the trust value corresponding to each network node in the third target list. Exemplarily, the first consensus node may perform reverse processing on the third target list based on a verifiable shuffling algorithm to obtain the third initial list. Exemplarily, the process of obtaining the first target list from the first initial list can be understood as the process of forward processing the first initial list based on the verifiable shuffling algorithm; the process of obtaining the first initial list from the first target list It can be understood as a process of reverse processing the first target list based on a verifiable shuffling algorithm. Exemplarily, the third trust value may be the result of encrypting the trust value in the third target list by using the public keys of the first consensus node and the second consensus node.

Then, the first consensus node can respectively encrypt the real identity of each network node based on the fifth key to obtain the second virtual identity corresponding to each network node, and based on the sixth key, respectively, corresponding to each network node in the third target list The trust value is decrypted to obtain the fourth trust value corresponding to each network node, wherein each second virtual identifier and the fourth trust value form a third initial list. Exemplarily, the fifth key may be a temporary random number generated by the first consensus node. Exemplarily, the sixth key may also be a temporary random number generated by the first consensus node, or a public key of the first consensus node. Exemplarily, the first consensus node may be OA1 described above.

Next, the first consensus node sends the third initial list to the second consensus node.

Next, the second consensus node encrypts the second virtual ID corresponding to each network node based on the seventh key to obtain the second target virtual ID, and, based on the eighth key, respectively trusts each network node in the third initial list. Values are decrypted to obtain the fourth target trust value corresponding to each network node, wherein each second target virtual identity and each fourth target trust value constitute a fourth target list, and at least two trust values in each fourth target trust value The value is the same as the third target trust value. Exemplarily, the seventh key may be a temporary random number generated by the second consensus node. Exemplarily, the eighth key may also be a temporary random number generated by the second consensus node, or a public key of the second consensus node. Exemplarily, the second consensus node may be the OAm described above. Exemplarily, the fourth target list can be as described above

Then, the second consensus node may send the fourth target list to the first consensus node. It can be understood that the second target virtual ID is different from the first target virtual ID, so that the virtual ID can be updated to improve security.

Finally, the first consensus node obtains the fourth target list sent by the second consensus node, can generate a third block based on the fourth target list, and store the third block in the blockchain. Exemplarily, the first consensus node and the second consensus node can calculate the fourth target list (such as the above-described

), global parameters related to the first consensus node and the second consensus node (such as described above

) is the root of the Merkle tree constructed. Afterwards, the first consensus node can relate the hash value of the second block, the serial number of the third block, the root of the calculated Merkle tree, the fourth target list, and the first consensus node and the second consensus node The global parameters of are packed into a block, that is, the third block is obtained.

In an example, the first consensus node updates the trust values corresponding to at least two network nodes in each network node in the second target list to the third target trust value, which may specifically include: the first consensus node determines at least two network nodes The target interval to which the trust value corresponding to the node belongs, and using the lower limit value of the target interval as the third target trust value, and updating the trust values corresponding to at least two network nodes to the third target trust value. Since at least two pseudonyms in the old list have a high probability of having the same trust value, it can make it difficult for an attacker to track network activities or pseudonyms of network nodes for a long time by analyzing the trust value of network nodes. Therefore, it is possible to By updating the trust values of at least two network nodes to the same trust value for trust obfuscation, the unlinkability between pseudonyms (ie, virtual identities) and trust values in the list is enhanced to improve security.

Exemplarily, the target interval can be set in advance. When the number of trust values of the network nodes NE falling into the target interval exceeds the preset value, all trust values in the interval can be adjusted to the same trust value, or most of them can be adjusted to the same trust value. In this way, at least two pseudonyms in the list have the same trust value, which makes it difficult for an attacker to track the network activities or pseudonyms of the NE for a long time by analyzing the trust value of the NE.

In one example, before the first consensus node updates the trust values corresponding to at least two of the network nodes in the second target list to the third target trust value, the first consensus node may base on the preset time decay coefficient and the trust value of each network node in the second target list, and re-determine the trust value of each network node. Therefore, before the trust is confused, the trust value of each network node can be re-evaluated to reduce the impact of time decay on the trust value and improve data security. Therefore, as an example, the first consensus node may re-determine the trust value of each network node based on the "Formula 2" described above.

Based on the methods in the foregoing embodiments, an embodiment of the present application further provides a chip. Please refer to FIG. 5 . FIG. 5 is a schematic structural diagram of a chip provided by an embodiment of the present application. As shown in FIG. 5 , a chip 500 includes one or more processors 501 and an interface circuit 502 . Optionally, the chip 500 may further include a bus 503 . in:

The processor 501 may be an integrated circuit chip and has signal processing capability. In the implementation process, each step of the above method may be completed by an integrated logic circuit of hardware in the processor 501 or instructions in the form of software. The above-mentioned processor 501 may be a general-purpose processor, a digital communicator (DSP), an application-specific integrated circuit (ASIC), a field programmable gate array (FPGA) or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components . Various methods and steps disclosed in the embodiments of the present application may be implemented or executed. A general-purpose processor may be a microprocessor, or the processor may be any conventional processor, or the like. The interface circuit 502 can be used for sending or receiving data, instructions or information. The processor 501 can use the data, instructions or other information received by the interface circuit 502 to process, and can send the processing completion information through the interface circuit 502 .

Optionally, the chip further includes a memory, which may include a read-only memory and a random access memory, and provides operation instructions and data to the processor. A portion of the memory may also include non-volatile random access memory (NVRAM). Optionally, the memory stores executable software modules or data structures, and the processor can execute corresponding operations by calling operation instructions stored in the memory (the operation instructions can be stored in the operating system).

Optionally, the interface circuit 502 may be used to output the execution result of the processor 501 .

It should be noted that the corresponding functions of the processor 501 and the interface circuit 502 can be realized by hardware design, software design, or a combination of software and hardware, which is not limited here.

It should be understood that each step in the foregoing method embodiments may be implemented by logic circuits in the form of hardware or instructions in the form of software in the processor. Wherein, the chip can be applied to the operator agent OA described in FIG. 2a above, so as to realize the method provided in the embodiment of the present application.

It can be understood that the processor in the embodiments of the present application may be a central processing unit (central processing unit, CPU), and may also be other general processors, digital signal processors (digital signal processor, DSP), application specific integrated circuits (application specific integrated circuit, ASIC), field programmable gate array (field programmable gate array, FPGA) or other programmable logic devices, transistor logic devices, hardware components or any combination thereof. A general-purpose processor can be a microprocessor, or any conventional processor.

The method steps in the embodiments of the present application may be implemented by means of hardware, or may be implemented by means of a processor executing software instructions. The software instructions can be composed of corresponding software modules, and the software modules can be stored in random access memory (random access memory, RAM), flash memory, read-only memory (read-only memory, ROM), programmable read-only memory (programmable rom) , PROM), erasable programmable read-only memory (erasable PROM, EPROM), electrically erasable programmable read-only memory (electrically EPROM, EEPROM), register, hard disk, mobile hard disk, CD-ROM or known in the art any other form of storage medium. An exemplary storage medium is coupled to the processor such the processor can read information from, and write information to, the storage medium. Of course, the storage medium may also be a component of the processor. The processor and storage medium can be located in the ASIC.

In the above embodiments, all or part of them may be implemented by software, hardware, firmware or any combination thereof. When implemented using software, it may be implemented in whole or in part in the form of a computer program product. The computer program product includes one or more computer instructions. When the computer program instructions are loaded and executed on the computer, the processes or functions according to the embodiments of the present application will be generated in whole or in part. The computer can be a general purpose computer, a special purpose computer, a computer network, or other programmable devices. The computer instructions may be stored in or transmitted via a computer-readable storage medium. The computer instructions may be transmitted from one website site, computer, server, or data center to another website site by wired (such as coaxial cable, optical fiber, digital subscriber line (DSL)) or wireless (such as infrared, wireless, microwave, etc.) , computer, server or data center for transmission. The computer-readable storage medium may be any available medium that can be accessed by a computer, or a data storage device such as a server or a data center integrated with one or more available media. The available medium may be a magnetic medium (such as a floppy disk, a hard disk, or a magnetic tape), an optical medium (such as a DVD), or a semiconductor medium (such as a solid state disk (solid state disk, SSD)), etc.

It can be understood that the various numbers involved in the embodiments of the present application are only for convenience of description, and are not used to limit the scope of the embodiments of the present application.

Claims

A block chain-based network node control method, characterized in that the block chain includes a first consensus node and a second consensus node, the first consensus node corresponds to the first server in the first network, so The second consensus node corresponds to a second server in the second network, and both the first network and the second network include at least one network node;

The methods include:

The first consensus node obtains a first block, and the first block includes a first target list, and the first target list includes the network nodes corresponding to the first network and the second network. A first target virtual identifier and a first target trust value, wherein the first target virtual identifier is used to characterize the identity of the network node, and the first target virtual identifier is different from the real identity of the network node, and Obtained by the first consensus node and the second consensus node based on the real identity of the network node, the first target trust value is used to characterize the trustworthiness of the network node in the network where it is located ;

When the first consensus node satisfies the first preset condition, update the trust value of each network node in the first target list to obtain a second target list, and generate a second zone based on the second target list block, wherein the second target list is included in the second block;

The first consensus node sends the second block to the second consensus node, so that the second consensus node verifies the second block;

The first consensus node obtains the first message sent by the second consensus node, and stores the second block in the block chain, and the first message is used to indicate that the second block Verification passed.
The method according to claim 1, wherein the obtaining of the first block by the first consensus node specifically comprises:

The first consensus node determines a first initial list, the first initial list includes the real identity of each of the network nodes and the first trust value corresponding to each of the network nodes, and the first trust value is passed through the Obtained by encrypting the trust value corresponding to each of the network nodes in the first target list by the first consensus node and/or the second consensus node;

The first consensus node respectively encrypts the real identity of each of the network nodes based on the first key to obtain the first virtual identity corresponding to each of the network nodes, and decrypts the corresponding virtual identity of each of the network nodes based on the second key. to obtain a second trust value corresponding to each of the network nodes, wherein each of the first virtual identities and the second trust value corresponding to each of the first virtual identities form a second initial list;

The first consensus node sends the second initial list to the second consensus node, so that the second consensus node encrypts the first virtual identifier corresponding to each of the network nodes based on the third key, and obtains The first target virtual identifier, and respectively decrypting the second trust value corresponding to each of the network nodes based on the fourth key to obtain the first target trust value corresponding to each of the network nodes, wherein each of the first Target virtual identities and first target trust values corresponding to each of the first target virtual identities constitute the first target list;

The first consensus node obtains the first target list sent by the second consensus node, and generates the first block based on the first target list, and stores the first block in the in the blockchain.
The method according to claim 1 or 2, wherein the first consensus node updates each network node in the first target list to obtain a second target list, which specifically includes:

The first consensus node obtains the behavior data of each of the network nodes within a preset time period;

The first consensus node determines a second target trust value corresponding to each of the network nodes based on the behavior data corresponding to each of the network nodes, the preset time decay coefficient, and the first target trust value corresponding to each of the network nodes ;

The first consensus node updates the first target trust value in the first target list to the second target trust value to obtain the second target list.
The method according to any one of claims 1-3, wherein the method further comprises:

When the first consensus node satisfies the second preset condition, update the trust values corresponding to at least two of the network nodes in the second target list to the third target trust value, and obtain third target list;

The first consensus node obtains a third initial list based on the third target list, and the third initial list includes real identities and third trust values corresponding to each of the network nodes, and the third trust value Obtained by encrypting the trust value corresponding to each of the network nodes in the third target list based on the first consensus node and/or the second consensus node;

The first consensus node respectively encrypts the real identity of each of the network nodes based on the fifth key to obtain the second virtual identity corresponding to each of the network nodes, and based on the sixth key, respectively encrypts the third target list Decrypting the trust value corresponding to each of the network nodes, to obtain a fourth trust value corresponding to each of the network nodes, wherein each of the second virtual identifiers and the fourth trust value constitute a third initial list;

The first consensus node sends the third initial list to the second consensus node, so that the second consensus node encrypts the second virtual identifier corresponding to each of the network nodes based on the seventh key, to obtain The second target virtual identifier, and respectively decrypting the trust values corresponding to each of the network nodes in the third initial list based on the eighth key to obtain a fourth target trust value corresponding to each of the network nodes, wherein, Each of the second target virtual identifiers and each of the fourth target trust values constitute the fourth target list, and at least two trust values in each of the fourth target trust values are the same as the third target trust value ;

The first consensus node obtains the fourth target list sent by the second consensus node, and generates a third block based on the fourth target list, and stores the third block in the block in the chain.
The method according to claim 4, wherein the first consensus node updates the trust values corresponding to at least two of the network nodes in the second target list to the third target Trust value, including:

The first consensus node determines the target interval to which the trust values corresponding to the at least two network nodes belong, and uses the lower limit value of the target interval as the third target trust value, and sets the at least two The trust values corresponding to each of the network nodes are all updated to the third target trust value.
The method according to claim 4 or 5, wherein the first consensus node updates the trust values corresponding to at least two of the network nodes in the second target list to the first Before the three-target trust value, it also includes:

The first consensus node re-determines the trust value of each of the network nodes based on the preset time decay coefficient and the trust value of each of the network nodes in the second target list.
A block chain-based network node control method, characterized in that the block chain includes a first consensus node and a second consensus node, the first consensus node corresponds to the first server in the first network, so The second consensus node corresponds to a second server in the second network, and both the first network and the second network include at least one network node;

The methods include:

The second consensus node obtains the second block sent by the first consensus node, the second block includes a second target list, and the second target list is the first consensus node that satisfies the first It is obtained by updating the trust value of each network node in the first target list contained in the first block under preset conditions, and the first target list includes each network node in the first network and the second network A corresponding first target virtual ID and a first target trust value, wherein the first target virtual ID is used to characterize the identity of the network node, and the first target virtual ID is different from the real identity of the network node , and obtained by the first consensus node and the second consensus node based on the real identity of the network node, the first target trust value is used to characterize the trustworthiness of the network node in its network Any degree;

The second consensus node verifies the second block, and when the verification is passed, sends a first message to the first consensus node, the first message is used to indicate that the second block Block verification passed.
The method according to claim 7, wherein, before the second consensus node obtains the second block sent by the first consensus node, further comprising:

The second consensus node obtains the second initial list sent by the first consensus node, the second initial list includes the first virtual identifier and the second trust value of each of the network nodes, and the first virtual identifier is obtained by encrypting the real identity of the network node in the first initial list by the first consensus node based on the first key, and the second trust value is obtained by encrypting the real identity of the network node in the first initial list by the first consensus node based on the second key. Decrypting the first trust value corresponding to the network node in the first initial list, the first initial list includes the real identity of each of the network nodes and the first trust value corresponding to each of the network nodes, The first trust value is obtained by encrypting the trust value corresponding to each of the network nodes in the first target list by the first consensus node and/or the second consensus node;

The second consensus node respectively encrypts the first virtual ID corresponding to each of the network nodes based on the third key to obtain the first target virtual ID, and decrypts the corresponding virtual ID of each of the network nodes based on the fourth key. The second trust value is to obtain the first target trust value corresponding to each of the network nodes, wherein each of the first target virtual identifiers and the first target trust value corresponding to each of the first target virtual identifiers constitute the first target list;

The second consensus node sends the first target list to the first consensus node.
The method according to claim 7 or 8, characterized in that the method further comprises:

The second consensus node obtains the third initial list sent by the first consensus node, the third initial list includes the second virtual identifier and the fourth trust value corresponding to each of the network nodes, the second virtual The identification is obtained by encrypting the real identity of the network node based on the fifth key by the first consensus node, and the fourth trust value is based on the sixth key of the first consensus node in the third target list. The third trust value corresponding to the network node is decrypted, and the third target list includes the real identity and the third trust value corresponding to each of the network nodes, and the third trust value is based on the first consensus node and /or the second consensus node encrypts the trust value corresponding to each of the network nodes in the third target list, wherein the third target list is obtained by the first consensus node meeting the second preset condition is obtained by updating the trust values corresponding to at least two of the network nodes in the second target list to the third target trust value;

The second consensus node encrypts the second virtual identifier corresponding to each of the network nodes based on the seventh key to obtain the second target virtual identifier, and, based on the eighth key, respectively encrypts the second virtual identifier corresponding to each of the network nodes in the third initial list Decrypt the trust value corresponding to the network node to obtain the fourth target trust value corresponding to each of the network nodes, wherein each of the second target virtual identifiers and each of the fourth target trust values constitute the fourth target list , and at least two of the fourth target trust values are the same as the third target trust value;

The second consensus node sends the fourth target list to the first consensus node, so that the first consensus node generates a third block based on the fourth target list, and the third block Blocks are stored into the blockchain.
A device control method, characterized in that it is applied to a first device, the method comprising:

The first device obtains the target virtual identifier corresponding to the first device based on the target block in the blockchain, and the target block is the second target block obtained based on the method described in any one of claims 1-9. block;

The first device sends a target message to the second device, and the target message includes the target virtual identifier and a target signature, and the target signature is that the first device bases its own private key on the target message Signed to get.
A device control method, characterized in that it is applied to a second device, the method comprising:

The second device obtains the target message sent by the first device, the target message includes a target virtual ID and a target signature, the target virtual ID is the virtual ID of the first device, and the first device can obtain The target block in the block chain obtains the virtual identification of the first device, the target block is the second block obtained based on the method described in any one of claims 1-9, and the target signature is the first Obtained by a device signing the target message based on its own private key;

The second device uses the target pseudonym to verify the target signature, and uses the target pseudonym to obtain a target trust value corresponding to the target pseudonym from the blockchain after the verification is passed , and conduct business activities based on the target trust value.
An equipment control device, characterized in that it comprises:

at least one memory for storing programs;

At least one processor for executing the program stored in the memory, when the program stored in the memory is executed, the processor is used for performing the method as claimed in claim 10, or, as described in claim 11 method.
A consensus node, characterized in that it includes:

at least one memory for storing programs;

At least one processor, configured to execute the program stored in the memory, when the program stored in the memory is executed, the processor is configured to execute the method as claimed in any one of claims 1-6, or, as claimed in any one of claims The method described in any one of 7-9.
A block chain-based network node control system, characterized in that the block chain includes a first consensus node and a second consensus node, the first consensus node corresponds to the first server in the first network, so The second consensus node corresponds to a second server in the second network, and both the first network and the second network include at least one network node;

Wherein, the first consensus node is configured to execute the method according to any one of claims 1-6, and the second consensus node is configured to execute the method according to any one of claims 7-9.
A computer-readable storage medium, the computer-readable storage medium stores a computer program, and when the computer program runs on an electronic device, the electronic device executes the method according to any one of claims 1-6 , or, the method according to any one of claims 7-9, or, the method according to claim 10, or, the method according to claim 11.
A computer program product, characterized in that, when the computer program product is run on an electronic device, the electronic device is made to execute the method according to any one of claims 1-6, or, according to claims 7-9 Any method as described, or, the method as claimed in claim 10, or, the method as described in claim 11.