Cooperative authentication processing method, system, equipment and medium

Abstract

The invention relates to a cooperative authentication processing method, system, device and medium, and the method comprises the steps: selecting at least two target verification nodes from a main chain node pool of a smart home system according to the request type of a network node request in the smart home system, and then carrying out the verification of at least two target verification nodes through each target verification node, and performing independent verification on the network node request to obtain verification result information of each target verification node, and performing weighted verification based on the verification result information of each target verification node in combination with the voting weight corresponding to each target verification node to obtain a cooperative authentication result corresponding to the network node request, therefore, whether the network node request passes verification can be determined subsequently based on the cooperative authentication result, stable operation of the smart home system is ensured, the problem of high risk of a centralized gateway due to the fact that the smart home system adopts a single gateway to control all devices in the prior art is solved, and the demand of a user for smart home security is met.

Description

Technical Field

[0001] This application relates to the field of smart home IoT security technology, and in particular to a collaborative authentication processing method, system, device and medium. Background Technology

[0002] With the rapid development of smart home systems, more and more devices are adding intelligent functions to achieve interconnection of devices in smart home scenarios, providing users with a comfortable, safe, high-quality and pleasant home living space.

[0003] However, existing smart home systems primarily control all devices through a single gateway, enabling interconnected control between devices. Because of this centralized gateway, if it is compromised by hackers or malfunctions, the entire system will lose control, and the interconnection and security features of all devices will fail, failing to meet users' core needs for smart home security.

[0004] It is evident that existing smart home systems rely on a single gateway for global control, which makes it difficult to meet users' needs for smart home security. Summary of the Invention

[0005] In view of this, this application provides a collaborative authentication processing method, system, device and medium to solve the problems of high risk of centralized gateway and inability of edge devices to verify the legitimacy of other devices caused by the use of a single gateway to control all devices in smart home systems in the prior art.

[0006] Firstly, this application provides a collaborative authentication processing method, including: Obtain network node requests from the smart home system; Based on the request type of the network node request, at least two target verification nodes are selected from the main chain node pool of the smart home system; The network node request is independently verified through each of the target verification nodes to obtain the verification result information of each target verification node. Based on the verification results of each target verification node, and combined with the voting weights of each target verification node, a weighted verification is performed to obtain the collaborative authentication result corresponding to the network node request.

[0007] Optionally, based on the request type of the network node request, at least two target verification nodes are selected from the main chain node pool of the smart home system, including: The request type is determined based on the request command parameters carried by the network node request; The preset node verification process corresponding to the request type is determined as the target node verification process; According to the target node verification process, at least two target verification nodes are selected from the main chain node pool.

[0008] Optionally, the step of selecting at least two target verification nodes from the main chain node pool according to the target node verification process includes: In the case that the target node verification process is a leaf node verification process, based on the network topology of the smart home system, at least two non-adjacent main chain nodes are selected from the main chain node pool. The selected non-adjacent main chain nodes are determined as the target verification nodes corresponding to the network node request.

[0009] Optionally, the step of independently verifying the network node request through each of the target verification nodes to obtain verification result information for each target verification node includes: Based on the leaf node verification process, the verification task corresponding to the network node request is distributed to each target verification node, wherein the verification task is used to trigger the target verification node to independently execute the verification work corresponding to the network node request; The verification result information generated by each target verification node is determined as the verification result information, which includes the result information generated by the target verification node after completing the verification work.

[0010] Optionally, the step of performing weighted verification based on the verification result information of each target verification node, combined with the voting weight of each target verification node, to obtain the collaborative authentication result corresponding to the network node request includes: Obtain the current reputation score information for each of the target verification nodes; The voting weight of each target verification node is determined based on its current reputation score. Based on the voting weights of each target verification node, and combined with the result score corresponding to the verification result information of each target verification node, the total verification score corresponding to the network node request is calculated. The collaborative authentication result is generated using the total verification score.

[0011] Optionally, the step of calculating the total verification score corresponding to the network node request based on the voting weights of each target verification node and the result score corresponding to the verification result information of each target verification node includes: For each target verification node, the voting score corresponding to the target verification node is determined by multiplying the result score and the verification voting weight. The total verification score is obtained by summing the votes for each target verification node.

[0012] Optionally, the step of selecting at least two target verification nodes from the main chain node pool according to the target node verification process includes: In the case where the target node verification process is the main chain node verification process, the main chain node where the network node request is currently located is taken as the main chain node, and the number of broadcast nodes corresponding to the main chain node is determined based on the number of main chain nodes in the network topology, wherein the number of broadcast nodes is less than the number of main chain nodes. Based on the neighbor status information of the master node, select non-adjacent nodes corresponding to the number of broadcast nodes from the main chain node pool; The selected non-adjacent nodes and the master node are determined as the target verification nodes.

[0013] Optionally, the step of independently verifying the network node request through each of the target verification nodes to obtain verification result information for each target verification node includes: Determine the request command corresponding to the network node request; The master node sends consensus messages corresponding to the request command to each of the non-adjacent main chain nodes; wherein, the consensus messages are used to trigger the non-adjacent nodes to perform security verification on the request command. The security verification result returned by each of the non-adjacent nodes is determined as the verification result information.

[0014] Optionally, determining the number of broadcast nodes corresponding to the master node based on the number of master chain nodes in the network topology includes: The number of main chain nodes is obtained by counting all main chain nodes in the network topology. The number of broadcast nodes is determined by using the square root of the number of master nodes.

[0015] Optionally, the step of performing weighted verification based on the verification result information of each target verification node, combined with the voting weight of each target verification node, to obtain the collaborative authentication result corresponding to the network node request includes: The security verification result fed back by each of the non-adjacent nodes is used to determine the vote corresponding to each of the non-adjacent nodes, and the vote is divided into affirmative votes and negative votes; If the number of affirmative votes reaches the threshold of the number of votes corresponding to the number of broadcast nodes, the collaborative authentication result is generated based on the authorization token information corresponding to the request command.

[0016] Optionally, the method further includes: in response to the collaborative authentication result, sending the authorization token information to each network node in the smart home system, wherein the network node is used to execute the request command based on the authorization token information.

[0017] Secondly, this application provides a collaborative authentication processing system, comprising: a ring main chain core verification layer constructed based on a smart home system, wherein the ring main chain core verification layer includes main chain nodes, and the main chain nodes are configured to implement the collaborative authentication processing method as described in any one of the first aspects above.

[0018] Thirdly, this application provides an electrical device, including: a processor, a communication interface, a memory, and a communication bus, wherein the processor, the communication interface, and the memory communicate with each other through the communication bus; the memory is used to store computer programs; and the processor, when executing the program stored in the memory, implements the steps of the collaborative authentication processing method as described in any one of the first aspects of this application.

[0019] Fourthly, this application also provides a computer storage medium storing a computer program thereon, which, when executed by a processor, implements the collaborative authentication processing method as described in any one of the first aspects of this application.

[0020] The collaborative authentication processing method, system, device, and medium provided in this application are applicable to collaborative authentication of smart devices in smart home scenarios. By acquiring network node requests from the smart home system, at least two target verification nodes are selected from the main chain node pool of the smart home system based on the request type. Then, each target verification node independently verifies the network node request. This verification results from each target verification node enable the edge device corresponding to the target verification node to verify the legitimacy of network node requests sent by other devices. Subsequently, based on the verification results from each target verification node and their corresponding voting weights, a weighted verification is performed to obtain the collaborative authentication result corresponding to the network node request. This allows subsequent determination of whether the network node request passes verification based on the collaborative authentication result, ensuring the stable operation of the smart home system. This solves the problem of high risk associated with centralized gateways in existing smart home systems that use a single gateway to control all devices, thus meeting users' security needs for smart homes. Attached Figure Description The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with the invention and, together with the description, serve to explain the principles of the invention.

[0021] To more clearly illustrate the technical solutions in the embodiments of the present invention or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, for those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0022] One or more embodiments are illustrated by way of example with reference numerals in the accompanying drawings. These illustrations do not constitute a limitation on the embodiments. Elements with the same reference numerals in the drawings are denoted as similar elements. Unless otherwise stated, the figures in the drawings are not to be limited by scale.

[0023] Figure 1 This application provides a schematic flowchart of a collaborative authentication processing method. Figure 2 A schematic diagram of a device-level interleaved verification topology provided as an example of this application; Figure 3 A schematic diagram illustrating a leaf node verification process, as an example of this application; Figure 4 A schematic diagram of a sensor-reported data verification process is provided as an application example of this application; Figure 5 A schematic diagram of an attack interception verification process provided as an application example of this application; Figure 6 A schematic diagram illustrating a main chain node verification process, provided as an example of this application; Figure 7 This is a schematic diagram illustrating the process of malicious identification and self-repair through the main chain node in one example of this application; Figure 8 This is a schematic diagram of the structure of a collaborative authentication processing system provided in an embodiment of this application; Figure 9 This is a schematic diagram of the structure of an electrical device provided in an embodiment of this application. Detailed Implementation

[0024] To make the objectives, technical solutions, and advantages of the embodiments of this application clearer, the technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0025] The following disclosure provides numerous different embodiments or examples for implementing various structures of the invention. To simplify the disclosure, specific examples of components and arrangements are described below. These are merely examples and are not intended to limit the scope of the invention. Furthermore, reference numerals and / or letters may be repeated in different examples. Such repetition is for simplification and clarity and does not in itself indicate a relationship between the various embodiments and / or arrangements discussed.

[0026] With the rapid development of smart homes, interconnection of multi-brand smart devices has become a trend, but significant deficiencies remain in device security authentication and malicious node handling. For example, existing smart home systems control all devices through a single gateway, leaving edge devices unable to verify the legitimacy of other devices. This results in high risks associated with centralized gateways and a lack of mutual checks and balances between devices. Specifically, existing smart home systems often employ a "single gateway controlling all devices" architecture, establishing communication links between master and slave devices to verify their legitimacy. However, due to gateway centralization, a breach of the gateway leads to system-wide loss of control, rendering all device linkage and security protection functions ineffective. Furthermore, the traditional star topology means that edge devices such as temperature and humidity sensors and smart bulbs can only communicate unidirectionally with the master device (i.e., the gateway), unable to verify the legitimacy of other devices. Therefore, this fails to meet users' security needs for smart homes.

[0027] To meet users' security needs for smart homes, this application provides a collaborative authentication processing method, system, device, and medium. By acquiring network node requests from the smart home system, and selecting at least two target verification nodes from the main chain node pool of the smart home system based on the request type, the network node request is then independently verified through each target verification node. Verification result information for each target verification node is obtained. Based on the verification result information of each target verification node and its corresponding voting weight, a weighted verification is performed to obtain the collaborative authentication result corresponding to the network node request. This collaborative authentication result allows subsequent determination of whether the network node request passes verification, enabling edge devices to verify the legitimacy of other devices.

[0028] Edge devices refer to devices with edge computing capabilities, which may include, but are not limited to, devices in smart home systems such as smart speakers, routers, and smart TVs. This application does not impose specific restrictions on the types of edge devices.

[0029] In practical implementation, devices used in smart home scenarios can be used as network nodes in the smart home physical network. The network topology of the smart home system can be built based on the network nodes, and data can be transmitted based on this network topology, such as sending network node requests. Here, a network node request refers to a request sent by a network node.

[0030] Figure 1 This is a flowchart illustrating the steps of a collaborative authentication processing method provided in an embodiment of this application. The collaborative authentication processing method provided in this embodiment is applicable to collaborative authentication of smart devices in smart home scenarios, such as smart home scenarios with interconnected multi-brand devices and collaborative edge computing nodes, to solve the problems of establishing trust between devices and isolating malicious nodes. Figure 1 As shown, the collaborative authentication processing method provided in this application embodiment may specifically include the following steps: Step 110: Obtain network node requests from the smart home system; In this embodiment, network nodes in a smart home system can be divided into main chain nodes and leaf nodes based on device power consumption and / or device security level, to construct a hierarchical verification structure in the smart home system. This hierarchical verification structure may include a ring main chain and a star-shaped extension layer; wherein the ring main chain, as the core verification layer of the hierarchical verification structure, can specifically be composed of highly reliable main chain nodes, forming a closed-loop verification network; the star-shaped extension layer, as the leaf node access layer, can specifically be used to access leaf nodes.

[0031] For example, such as Figure 2 As shown, to achieve a device-level interleaved verification topology, network nodes corresponding to devices with edge computing capabilities, such as smart speakers, routers, smart TVs, Network Access Servers (NAS) devices, and home servers, can be used as main chain nodes. A "two-way verification channel" can be established based on the main chain nodes to form a ring-shaped main chain core verification layer, avoiding single-point dependence. Network nodes corresponding to low-power or low-security devices, such as smart sockets, temperature and humidity sensors, smart light bulbs, and cameras, can be used as leaf nodes of the star-shaped expansion layer. Each leaf node is connected to multiple main chain nodes, so leaf node verification can be achieved through at least two main chain nodes.

[0032] Step 120: Based on the request type of the network node request, select at least two target verification nodes from the main chain node pool of the smart home system. The network node request type can refer to the type of network node request itself. For example, based on the type of network node, request types can be divided into main node request types and leaf node request types. A main node request type can refer to the type of request from the main chain node, specifically used to characterize a main chain node request. Similarly, a leaf node request type can refer to the type of request from the leaf node, specifically used to characterize a leaf node request. The main chain node pool of the smart home system can refer to the node pool built by the smart home system based on various smart home devices, specifically containing one or more main chain nodes. The target verification node can refer to the main chain node currently selected from the main chain node pool in response to the network node request, specifically used to verify the legitimacy of the network node, serving as the verification node for the network node request.

[0033] Specifically, embodiments of this application can pre-set different node verification processes for different types of network node requests to achieve dynamic verification of network node requests based on the node verification process. Therefore, after obtaining a network node request, embodiments of this application first determine the request type of the currently obtained network node request, and then determine which type of node verification process should be used to verify the network node request based on the request type. Subsequently, at least two target verification nodes can be selected from the main chain node pool of the smart home system according to the node verification process, so that the network node request can be verified through the target verification nodes later.

[0034] In an optional implementation, step 120 may specifically include: determining the request type based on the request command parameters carried by the network node request; subsequently, determining the preset node verification process corresponding to the request type as the target node verification process; and then selecting at least two target verification nodes from the main chain node pool according to the target node verification process. Here, the request command parameters may refer to parameters related to the request command, which may be the command requested by the network node request.

[0035] As can be seen, after obtaining a network node request, this embodiment can determine the command requested by the network node request based on the request command parameters carried by the network node request. Then, it can determine the type of the network node request based on the command requested by the network node request, i.e., determine the request type of the network node request. Subsequently, based on the currently determined request type, the corresponding preset node verification process can be determined as the target node verification process. For example, if the request type is a leaf node request type, the preset leaf node verification process corresponding to the leaf node request type is determined as the target node verification process; or, if the request type is a main node request type, the preset leaf node verification process corresponding to the main node request type is determined as the target node verification process. According to the target node verification process, two or more target verification nodes are randomly selected from the main chain node pool of the smart home system. Then, the network node request can be cross-verified through at least two target verification nodes to achieve device-level cross-verification, enabling edge devices in the smart home scenario to verify the legitimacy of other devices.

[0036] Step 130: Independently verify the network node request through each of the target verification nodes to obtain the verification result information of each target verification node; Specifically, in this embodiment of the application, after selecting the target verification node, the verification task corresponding to the network node request can be distributed to each target verification node. The verification task triggers each target verification node to independently execute the verification work corresponding to the network node request. The verification work result information generated by each target verification node can be determined as the verification result information, thereby obtaining the verification result information of each target verification node. This allows for weighted verification based on the verification result information of each target verification node.

[0037] Step 140: Based on the verification result information of each target verification node, and combined with the voting weight of each target verification node, a weighted verification is performed to obtain the collaborative authentication result corresponding to the network node request.

[0038] Specifically, after obtaining the verification result information of each target verification node, this application embodiment can determine the voting weight of each target verification node according to the preset weighted verification rules and the corresponding reputation score of each target verification node. Based on the verification result information of each target verification node and the corresponding voting weight of each target verification node, weighted verification is performed to obtain the collaborative authentication result corresponding to the network request. Then, the collaborative authentication result can be used to determine whether the network node request passes the verification, ensuring the stable operation of the smart home system and meeting the user's needs for smart home security.

[0039] The preset weighted verification rules refer to rules pre-set for weighted verification, which stipulate that the voting weight of each target verification node is dynamically determined by its reputation score. For example, taking a reputation score range of zero to 1, the preset weighted verification rules can stipulate that: target verification nodes with a reputation score greater than or equal to 0.8 have a voting weight of 1.0; target verification nodes with a reputation score not less than 0.8 and greater than or equal to 0.5 have a voting weight of 0.5; and target verification nodes with a reputation score less than 0.5 have a voting weight of 0, so that target verification nodes with a reputation score less than 0.5 do not participate in verification. For example, ... Figure 2 As shown, the reputation score of the smart speaker is 0.9, and its corresponding voting weight is 1.0; the reputation score of the router is 0.8, and its corresponding voting weight is also 1.0; the reputation score of the smart TV is 0.8, and its corresponding voting weight is 1.0; the reputation score of the NAS device is 0.9, and its corresponding voting weight is 1.0; and the reputation score of the home server is 0.7, and its corresponding voting weight is 0.5.

[0040] In addition, a pass score threshold can be specified in the weighted verification rules. This pass score threshold can be used to determine whether a network node request passes the final verification. For example, if the total verification score corresponding to a network node request exceeds the pass score threshold, the network node request is considered to have passed the weighted verification; while if the total verification score corresponding to a network node request does not exceed the pass score threshold, the network node request is considered to have failed the weighted verification.

[0041] In specific implementations, the reputation score corresponding to the target verification node can be used to characterize the credibility of the target verification node. For example, the higher the credibility of the main connection node, the higher its corresponding reputation score. Optionally, in the weighted verification process of this application embodiment, the current reputation score information of the target verification node can be obtained to determine the reputation score of the target verification node in real time based on the current reputation score information. Then, the voting weight corresponding to the target verification node can be determined based on the reputation score. Based on the verification result information of each target verification node and the corresponding voting weight of each target verification node, weighted verification is performed to obtain the collaborative authentication result corresponding to the network node request. This allows the subsequent determination of whether the network node request passes verification based on the collaborative authentication result, ensuring the stable operation of the smart home system.

[0042] In summary, the collaborative authentication processing method provided in this application obtains network node requests from the smart home system. Based on the request type of the network node request, at least two target verification nodes are selected from the main chain node pool of the smart home system. Then, the network node request is independently verified through each target verification node. By using each target verification node to verify the currently obtained network node request, the verification result information of each target verification node is obtained. This enables the edge device corresponding to the target verification node to verify the legality of network node requests sent by other devices. Subsequently, based on the verification result information of each target verification node and the voting weight of each target verification node, a weighted verification can be performed to obtain the collaborative authentication result corresponding to the network node request. This allows subsequent determination of whether the network node request passes verification based on the collaborative authentication result, ensuring the stable operation of the smart home system. This solves the problem of high risk of centralized gateways caused by the use of a single gateway to control all devices in the existing technology, thereby meeting users' security needs for smart homes.

[0043] In an optional implementation, step 140 above, based on the verification result information of each target verification node and combined with the voting weight corresponding to each target verification node, performs weighted verification to obtain the collaborative authentication result corresponding to the network node request. Specifically, this may include the following sub-steps: Sub-step 1401: Obtain the current reputation score information for each of the target verification nodes; Sub-step 1402: Determine the voting weight corresponding to each target verification node based on the current reputation score information of each target verification node; Sub-step 1403: Based on the voting weights of each target verification node, and combined with the result score corresponding to the verification result information of each target verification node, calculate the total verification score corresponding to the network node request. Sub-step 1404: The collaborative authentication result is generated using the total verification score.

[0044] In this embodiment of the application, the current reputation score information of the target verification node may refer to information related to the current reputation score of the target verification node, such as the current reputation score information of the target verification node may include, but is not limited to, the online status and security level of the target verification node. This embodiment of the application does not limit this.

[0045] Specifically, in this embodiment of the application, after obtaining the current reputation score information of the target verification node, the current reputation score of the target verification node can be determined in real time based on the current reputation score information. Weight mapping can be performed based on the current reputation score to determine the weight corresponding to the current reputation score. Then, the mapped weight can be used as the voting weight corresponding to the target verification node. Based on the voting weight corresponding to each target verification node, combined with the result score corresponding to the verification result information of each target verification node, the total verification score corresponding to the network node request is calculated to obtain the total verification score.

[0046] As an example of this application, taking the selection of two target verification nodes as an example, if two high-reputation mainchain nodes are selected as target verification nodes, such as two mainchain nodes with a current reputation score greater than 0.8, then through weight mapping, it can be determined that the voting weight of both target verification nodes is 1; if one high-reputation mainchain node and one medium-reputation mainchain node are selected as target verification nodes, such as one mainchain node with a current reputation score greater than 0.8 and one mainchain node with a current reputation score of 0.5, then through weight mapping, it can be determined that the voting weight corresponding to the mainchain node with a current reputation score greater than 0.8 is 1, while the voting weight corresponding to the mainchain node with a current reputation score of 0.5 is 0.5.

[0047] In this embodiment of the application, the verification result information can be divided into verification failure result information and verification success result information; wherein, the verification failure result information can be used for network node requests that fail verification, and its corresponding result score can be set to a relatively low score, such as zero; the verification success result information can be used for network node requests that pass verification, and its corresponding result score can be set to a relatively high score, such as 1.

[0048] After determining the voting weight corresponding to the target verification node, this embodiment of the application can calculate the voting score corresponding to the target verification node based on the voting weight and the result score corresponding to the verification result information of the target verification node. Then, by accumulating the voting scores corresponding to each target verification node, the total verification score corresponding to the network node request can be obtained. Optionally, this embodiment of the application calculates the total verification score corresponding to the network node request based on the voting weight corresponding to each target verification node and the result score corresponding to the verification result information of each target verification node. Specifically, this can include: for each target verification node, multiplying the result score and the verification voting weight to determine the voting score corresponding to the target verification node; accumulating the voting scores corresponding to each target verification node to obtain the total verification score, so that a collaborative authentication result corresponding to the network node request can be generated based on the total verification score, thus completing the final adjudication of the network node request.

[0049] For example, with a preset pass score threshold of 1.5, let's take the selection of two target verification nodes to verify a network node request as an example. Assume both target verification nodes consider the network node request to pass verification, meaning their verification results each have a score of 1. If both target verification nodes currently have a reputation score greater than 0.8, then their voting weight is 1. Calculation shows the total verification score for the network node request is 2, which is greater than the pass score threshold. Therefore, the network node request is considered to have passed the final verification, generating a final verification pass result as the collaborative authentication result for the network node request. If a high-reputation mainchain node and a medium-reputation mainchain node are selected as target verification nodes, such as a mainchain node with a current reputation score greater than 0.8 and a mainchain node with a current reputation score of 0.5, calculation shows the total verification score for the network node request is 1.5, which equals the pass score threshold. In this case, the network node request is also considered to have passed the final verification, allowing subsequent operations based on this final verification pass result.

[0050] In some optional embodiments of this application, to implement the device and interleaved verification topology of the smart home system, a hierarchical verification structure of the smart home system can be used to configure each leaf node request to have its behavior verified by at least two non-adjacent main chain nodes, preventing collusion attacks. Here, a leaf node request can refer to a request that a leaf node needs to send. For example, when a leaf node needs to perform any operation that requires interaction with other parts of the network or changes its state, it can initiate a leaf node request to obtain authorization from the main chain nodes.

[0051] Non-adjacent main chain nodes refer to main chain nodes that are not adjacent. In this embodiment, for leaf node requests, two non-adjacent main chain nodes with no direct connection can be randomly selected from the main chain node pool as verifiers. These two selected non-adjacent main chain nodes serve as the target verification nodes for the node request. This avoids collusion attacks caused by illegal network node requests using two adjacent main chain nodes for verification, effectively preventing merge attacks and ensuring the stable operation of the smart home system.

[0052] Optionally, in this embodiment of the application, at least two target verification nodes are selected from the main chain node pool according to the target node verification process. Specifically, this may include: when the target node verification process is a leaf node verification process, at least two non-adjacent main chain nodes are selected from the main chain node pool based on the network topology of the smart home system; the selected non-adjacent main chain nodes are determined as the target verification nodes corresponding to the network node request, so that the leaf node request can be independently verified using the currently selected at least two non-adjacent main chain nodes to obtain the verification result information generated by each target verification node.

[0053] Specifically, in this embodiment of the application, after determining that the request type of the currently acquired network node request is a leaf node request type, a leaf node verification process can be triggered to perform leaf node verification according to the leaf node verification process. For example, based on the verification process and security mechanism, the leaf node verification process mainly occurs after the request is initiated, such as... Figure 3 As shown, two non-adjacent nodes are selected as target verification nodes to independently verify the request. Then, based on the verification results of each target verification node and their voting weights, a weighted verification is performed. The total verification score corresponding to the network node request is determined through weighted verification. Whether the network node request passes the final verification is then determined by checking if the total verification score exceeds a preset passing score threshold. If the total verification score exceeds the preset passing score threshold, the verification is considered successful, and collaborative authentication pass information is generated as the collaborative authentication result for the network node request. Based on this collaborative authentication pass information, the operation corresponding to the network node request can be executed, i.e., the operation is performed to complete the network node request. If the total verification score does not exceed the preset passing score threshold, the verification is considered unsuccessful, and collaborative authentication rejection information is generated as the collaborative authentication result for the network node request. Based on this collaborative authentication rejection information, the operation corresponding to the network node request can be refused, i.e., the request is blocked.

[0054] In one optional implementation, to meet the verification requirement that leaf node verification must obtain cross-validation from at least two non-adjacent main chain nodes, the leaf node verification process can specifically include two verification steps: non-adjacent node selection and weighted verification based on weighted verification rules. The non-adjacent node selection step mainly involves randomly selecting two validators with no direct connection from the main chain node pool, i.e., selecting two non-adjacent main chain nodes as the target verification nodes for the network node request, to prevent collusion attacks. The weighted verification step based on weighted verification rules mainly involves dynamically determining the voting weight of each target verification node based on its current reputation score. Based on the voting weights of each target verification node and the result scores corresponding to the verification results of each target verification node, a total verification score for the network node request is calculated. Then, by judging whether the total verification score exceeds a preset passing score threshold, the network node request is determined to pass the final verification, thus completing the final decision on the network node request.

[0055] As an application example of this application, in a normal verification case, such as Figure 4 As shown, taking sensor data reporting as an example, the request for sensor data reporting can be treated as a leaf node request in the smart home system. Based on the request type of this leaf node request, a gateway and a speaker can be selected from the main chain node pool of the smart home system as target verification nodes for verification using the gateway and speaker (gateway + speaker verification). If both the gateway and the speaker deem the sensor data reporting request to have passed independent verification, the verification score is calculated based on the voting weights of the gateway and the speaker. For example, if the voting weights of both the gateway and the speaker are 1.0, the total verification score corresponding to the leaf node request can be determined to be 2, i.e., total verification score 2 = 1.0 + 1.0 > 1.5. Therefore, the total verification score corresponding to this leaf node request is greater than the preset passing score threshold of 1.5, and thus the leaf node request is considered to have passed the final verification, generating a final verification result. Based on this final verification result, the sensor data reporting will be uploaded, completing the operation corresponding to the leaf node request after successful data upload.

[0056] For example, in an attack interception case, such as Figure 5As shown, a malicious socket's request to send instructions can be treated as a leaf node request in the smart home system. Based on the request type of this leaf node request, a gateway and a speaker can be selected from the main chain node pool of the smart home system as target verification nodes for verification. If the gateway rejects the requested instruction, and the speaker considers the leaf node request to have only partially passed verification, then the verification results for each target verification node are: gateway rejected + speaker partially passed. Subsequently, based on the voting weights of the gateway and the speaker, the total verification score corresponding to the network node request can be calculated. For example, if the voting weights of both the gateway and the speaker are 1.0, since the gateway's verification result is "gateway rejected," the gateway's verification result can be considered as... The result corresponding to the fruit information is 0, while the speaker's verification result is "partially passed". Therefore, the result corresponding to the speaker's verification result is considered to be 0.5. Through calculation, the total verification score corresponding to the leaf node request is determined to be 0.5, that is, the total verification score 0.5 = 1.0 * 0 + 1.0 * 0.5. It can be seen that the total verification score of 0.5 corresponding to the leaf node request is less than the preset passing score threshold of 1.5. Therefore, it is considered that the total verification score does not meet the standard, and the leaf node request has not passed the final verification. Subsequently, the verification failure result can be used as the collaborative authentication result to intercept the instructions carried by the leaf node request based on the verification failure result. That is, the instructions sent by the malicious socket are intercepted, thereby achieving the interception of malicious node attacks and ensuring the stable and secure operation of the system.

[0057] Optionally, this application implements independent verification of the network node request through each of the target verification nodes to obtain verification result information for each target verification node. Specifically, this may include: based on the leaf node verification process, distributing the verification task corresponding to the network node request to each target verification node, wherein the verification task is used to trigger the target verification node to independently execute the verification work corresponding to the network node request; subsequently, the verification work result information generated by each target verification node can be determined as the verification result information for each target verification node, and weighted verification can be performed using the result score corresponding to the verification result information of the target verification node to obtain the collaborative authentication result corresponding to the network node request. The verification work result information of the target verification node includes the result information generated by the target verification node after completing the verification work, which can be used to determine whether the currently obtained leaf node request passes verification.

[0058] In summary, after obtaining a leaf node request from the smart home system, this application embodiment can determine the preset leaf node verification process corresponding to the leaf node request type as the target node verification process according to the leaf node request type. In accordance with the leaf node verification process, at least two target verification nodes are selected from the main chain node pool as verifiers of the leaf node request, so that the leaf node request can be verified by the verifiers of the leaf node request in accordance with the leaf node verification process.

[0059] To facilitate understanding of the embodiments of this application, the leaf node verification process of the embodiments of this application will be further explained below with reference to the accompanying drawings and specific smart home scenarios, taking "data reporting request" as an example. However, this example does not constitute a limitation on the embodiments of this application.

[0060] A data reporting request refers to a request generated in response to data reporting, specifically used to request data reporting. For example, taking a temperature and humidity sensor as a leaf node in the network topology, when the sensor initiates a data reporting action, a data reporting request can be generated and sent to the smart home system's authentication system. The authentication system then randomly selects two non-adjacent main chain nodes with no direct connection from the main chain node pool as verifiers for this data reporting request. In other words, two non-adjacent main chain nodes are selected from the pool as target verification nodes corresponding to the node request. These two selected non-adjacent main chain nodes are then used to independently verify the currently obtained leaf node request, obtaining the verification result information generated by each target verification node.

[0061] Specifically, after using the temperature and humidity sensor as a leaf node in the smart home system, the data reporting request from the temperature and humidity sensor can be used as the data reporting request of the leaf node. For example, if the temperature and humidity sensor requests to report the data {"temperature":25℃, "humidity":60%}, a corresponding data reporting request can be generated based on the reported data {"temperature":25℃, "humidity":60%}. When the sensor reports data, the data reporting request can be sent to the main chain node through the Internet of Things, so that the main chain node can verify the data reporting request.

[0062] The main chain nodes can include network nodes corresponding to various highly trusted devices in the smart home system. Each main chain node can perform independent verification work on requests from leaf nodes, and the voting weight of each main chain node can be dynamically determined based on its current reputation score. For example, if the highly trusted devices in the smart home system include a home gateway, smart speaker, NAS device, and smart TV, the voting weight of the main chain node corresponding to each highly trusted device can be determined based on its current reputation score. For instance, the home gateway has the highest credibility, so the voting weight of the first main chain node corresponding to the home gateway can be determined as 1.0; the smart speaker also has relatively high credibility, so the voting weight of the second main chain node corresponding to the smart speaker can also be determined as 1.0; since the NAS device has generally low credibility, its credibility can be determined based on its current reputation score, and the voting weight of the third main chain node corresponding to it can be determined as 0.6; and the smart TV has relatively low credibility, so the voting weight of the fourth main chain node corresponding to the smart TV can be determined as 0.4.

[0063] In an optional example of this application, the leaf node verification process may include the following steps: Step 1: Selection of Non-Adjacent Verifiers. For example, verification can be triggered by uploading data from a sensor. Specifically, a temperature and humidity sensor sends a data packet and its digital signature to the network to request the upload of the required temperature and humidity sensor data. Then, the system's scheduling module randomly selects two non-adjacent main chain nodes as target verification nodes. When the scheduling module receives a data reporting request corresponding to the sensor's uploaded data, it can randomly select two verifiers from the currently online main chain node list as the target verification nodes for that data reporting request. Specifically, after randomly selecting the home gateway and NAS device, the scheduling module can check whether the home gateway and NAS device are adjacent nodes on the ring main chain based on the smart home system's network topology. If the check determines that the home gateway and NAS device are not adjacent nodes on the ring main chain, then the currently selected home gateway and NAS device meet the preset verifier selection criteria. Therefore, the home gateway and NAS device can be used as the target verification nodes for the data reporting request, allowing for subsequent weighted verification using these target verification nodes. The scheduling module can be a small module responsible for scheduling within the system, such as a scheduling module running on a main chain node. This application example does not impose such restrictions. The preset conditions for selecting validators can stipulate that the two selected validators cannot be directly adjacent main chain nodes, i.e., there is no direct verification channel on the circular main chain. This is to prevent the two validators from being easily controlled and colluding by the same local attacker, thereby achieving the purpose of preventing collusion attacks.

[0064] The second step is weighted verification execution, which may include: distributing verification tasks, independent verification, and making voting decisions. Distributing verification tasks involves the scheduling module sending the data packet from the temperature and humidity sensor and the corresponding data reporting request to two selected verifiers: the home gateway and the NAS device. Subsequently, these two verifiers, the home gateway and the NAS device, can independently perform the verification work to achieve independent verification of the data reporting request by the target verification node. They will check multiple aspects, such as verifying identity authenticity and behavioral rationality, which are not limited in this embodiment. In a specific implementation, identity authenticity verification can use the sensor's public key to verify the digital signature, confirming that the data packet corresponding to the data reporting request indeed comes from the temperature and humidity sensor and has not been tampered with, thus verifying the authenticity of the sender of the data reporting request. Behavioral rationality verification can compare the data reporting request with a pre-stored behavioral feature database to verify the behavioral rationality of the data reporting request based on the comparison results.

[0065] For example, a check via the home gateway revealed that the temperature and humidity sensor last reported data 58 seconds ago. This means the upload frequency of the current data reporting request from the sensor is greater than the threshold of 1 time per second, indicating that the sensor's data reporting request is normal. Furthermore, a check via the NAS device showed that the data format of the reported data is correct. If the data in the request includes temperature and humidity fields with values ​​within a reasonable range, the request is considered normal. Subsequently, a permission check can be performed to determine if the temperature and humidity sensor has the authority to perform the "report data" operation, allowing for subsequent voting decisions based on the permission check results.

[0066] In one optional implementation of the voting decision, each verifier can make a binary decision of "pass" or "reject" based on the inspection result, and generate corresponding verification result information based on the binary decision result. For example, based on the "pass" decision, the preset result score of 1 corresponding to "pass" is used as the verification result information; or based on the "reject" decision, the preset result score of 0 corresponding to "reject" is determined as the verification result information. For example, if both the home gateway and the NAS device believe that the data reporting request passes the inspection, both the home gateway and the NAS device can cast a "pass" vote, so that subsequent weighted scoring can be performed based on the result scores corresponding to the verification result information.

[0067] Step 3: Weighted scoring and final decision, which may include the following sub-steps: Sub-step S31: Calculate the weighted total score, which involves querying the current reputation scores of the two verifiers and mapping them to weights. For example, if the home gateway's current reputation score is 0.9 and the NAS device's current reputation score is 0.6, through weight mapping, the voting weight corresponding to the home gateway can be determined to be 1.0. Since the NAS device's current reputation score of 0.6 is greater than or equal to 0.5 and less than 0.8, meaning the NAS device's current reputation score of 0.6 is within the range of reputation scores mapped to a voting weight of 0.5, the NAS device's corresponding voting weight is 0.5. Subsequently, based on the corresponding voting weights of each validator and the result scores corresponding to the verification result information, a weighted total score for this verification can be calculated. For example, based on the product of the home gateway's result score of 1 and its voting weight of 1.0, the home gateway's voting score can be calculated to be 1.0; similarly, based on the product of the NAS device's result score of 1 and its voting weight of 0.5, the NAS device's voting score can be calculated to be 1.0. Then, by summing, the total verification score corresponding to this data reporting request can be calculated to be 1.5, i.e., total score = 1.0 + 0.5 = 1.5.

[0068] Sub-step S32 applies a threshold rule to determine whether the data reporting request passes the final verification. Taking the system's preset pass score threshold of 1.5 as an example, when the total verification score corresponding to the network node request is greater than or equal to 1.5, the network node request can be considered to have passed the final verification. As mentioned above, the total verification score corresponding to the data reporting request is 1.5, which just meets the threshold, and thus it can pass the final verification. Sub-step S33 can then be executed to complete the operation corresponding to the data reporting request. If the total verification score corresponding to the network node request is less than 1.5, the network node request can be considered to have failed the final verification, and thus the operation corresponding to the data reporting request can be rejected to ensure the stable operation of the system.

[0069] Sub-step S33 involves executing an action: after the scheduling module collects the verification results from each target verification node, it can determine whether the data reporting request has passed the final verification. If the data reporting request has passed the final verification, it authorizes the data packet corresponding to the data reporting request to be uploaded to the cloud or sent to the designated application to complete the data reporting. At the same time, this successful verification may slightly improve the reputation score of the temperature and humidity sensor to prove that the temperature and humidity sensor is reliable. It may also slightly improve its reputation score because the NAS device made a correct judgment. This application embodiment does not impose specific limitations on this.

[0070] In another attack scenario example of this application, suppose the same temperature and humidity sensor mentioned above is hacked and begins to frantically report data at an extremely high frequency of 10 times per second, attempting to exhaust network resources, such as a DoS attack. First, through the step of randomly selecting verifiers, the scheduling module can randomly select a smart speaker with a current reputation score of 1.0 and a smart TV with a current reputation score of 0.4 as target verification nodes. Subsequently, by distributing verification tasks, the smart speaker and smart TV can independently verify the received leaf node requests. For example, if the pre-set reporting behavior policy for data reporting is that the interval between data reporting requests is greater than 1 second, the smart speaker can determine whether the data reporting request violates the reporting behavior policy by checking the reporting frequency. For example, if the smart speaker finds that the time interval between the current data reporting request and the previous request is only 0.1 seconds, since 0.1 seconds is less than the time interval corresponding to 1 time / second in the preset reporting behavior policy, it can be considered that the data reporting request seriously violates the behavior policy, and therefore a rejection vote is cast. That is, the smart speaker uses the result score of 0 corresponding to the rejection vote as the verification result information. In addition, since the smart TV and other devices have a current reputation score of 0.4, If the voting weight is less than the reputation score threshold of 0.5 corresponding to voting rights, the smart TV's voting weight can be determined to be 0 through weight mapping. This means the smart TV is not qualified to participate in verification. In this case, the scheduling module will reselect another qualified verifier. Assuming the NAS device with a voting weight of 0.5 is selected this time, the NAS device can detect the reporting frequency corresponding to the data reporting request. If the NAS device also detects an abnormal frequency, it can cast a rejection vote, and the result score of 0 for the rejection vote will be used as the NAS device's verification result information. Then, through weighted scoring, the total verification score corresponding to the data reporting request can be determined to be 0. Since the total verification score corresponding to the data reporting request is 0, which is less than the pass score threshold of 1.5, verification failure can be used as the final ruling for the data reporting request. The data reporting request will be handled according to the final ruling. For example, based on the verification failure ruling, the sensor's data reporting request is immediately rejected, and the system can record this abnormal behavior, significantly reducing the reputation score of the temperature and humidity sensor. Furthermore, since the smart speaker and NAS device correctly identified the attack, their reputation scores will be maintained or slightly improved.

[0071] Optionally, in order to promptly detect and clean up malicious device nodes and perform network topology reconfiguration, this application embodiment can pre-set a reputation score threshold for malicious device nodes. When the reputation score of a network node in the smart home system is lower than the preset reputation score threshold of 0.3, it is identified as an abnormal node and isolated. This completely isolates abnormal nodes with reputation scores lower than the preset reputation score threshold of 0.3, thereby enhancing the ability to identify and process malicious device nodes and realizing abnormal node processing.

[0072] In this embodiment of the application, the leaf node request may include not only data reporting requests, but also other types of leaf node requests, such as, but not limited to, instruction execution requests, active behavior requests, state change requests, etc. This embodiment of the application does not limit this.

[0073] In this context, an instruction execution request refers to a request generated in response to an instruction received from the network. For example, when a smart light bulb receives an "turn on the light" instruction from a mobile app, its request is an instruction execution request to "request to execute the 'turn on the light' operation." During the verification phase, two main chain nodes (such as a gateway and a speaker) can be randomly selected as target verification nodes for this instruction execution request. These nodes verify whether the instruction execution request originates from a legitimate controller (e.g., verifying the app signature), and can also verify the correctness of the instruction format and whether turning on the light is permitted at the current time. For instance, during the day, the light might be automatically refused to turn on to save energy. Furthermore, by randomly selecting two non-adjacent main chain nodes as target verification nodes to verify the behavior of the instruction execution request, malicious control of the device by forged instructions can be prevented. For example, it can prevent forged instructions from suddenly turning on a speaker late at night and disturbing the user's rest, or from forged instructions frequently switching the light bulb on and off, causing it to become unusable. Similarly, when a smart door lock receives an "unlock" instruction, its corresponding request is a door lock operation request to "request to execute the 'unlock' operation." In response to this door lock operation request, the verification node will perform more stringent checks during the verification process. For example, it will also verify whether the unlocking command comes from an authorized user's mobile phone and whether the unlocking time is within a preset safe time window, in order to verify whether the door lock operation request is legal and ensure the legality of the door lock operation.

[0074] Active action requests can be requests initiated proactively by leaf nodes. For example, when a smoke sensor detects dense smoke, its request is an "emergency request to execute the 'whole house alarm' protocol." When the target verification node receives this active action request, it can prioritize processing it. To avoid panic caused by false alarms from a single sensor and to ensure the authenticity of critical safety alarms, it not only needs to verify the sensor's identity but also cross-verify other relevant data. For instance, while detecting the smoke alarm data carried in the active action request uploaded by the smoke sensor, it can also detect whether the carbon monoxide sensor is also alarming at the same time, whether the kitchen camera has seen an open flame, and other relevant data before deciding whether to trigger the alarm. This can avoid panic caused by false alarms from a single sensor, ensure the authenticity of critical safety alarms, and prevent "boy who cried wolf" deception attacks.

[0075] For example, if a smart curtain motor determines that it is already daylight based on its built-in light sensor, its request would be an active request to "execute the 'open curtain' operation." When the target verification node receives this request, it can first check if the time is within a reasonable time range of early morning, and then determine whether to automatically open the window based on the homeowner's global preference settings. For instance, if the homeowner's global preference setting is "automatically open windows at 7:30 on weekdays," and the current time is 7:30 on a non-weekday, the active request to "execute the 'open curtain' operation" would be considered invalid, and the verification would fail. However, if the current time is 7:30 on a weekday, the active request to "execute the 'open curtain' operation" would be considered valid, and the verification would pass.

[0076] A state change request can be a request to request a state change. For example, a low-power temperature and humidity sensor needs to synchronize its time with a network time server every so often. Its request would be a state change request to "request communication with the time server ntp.pool.org". Considering that many Internet of Things (IoT) devices in smart home scenarios should not directly access the external network, the target verification node can determine whether the temperature and humidity sensor's state change request to "request communication with the time server ntp.pool.org" is legitimate by checking whether the temperature and humidity sensor has permission to communicate with the external network and whether the domain name it requests is on the whitelist. This prevents infected devices from becoming members of a "botnet", leaking data to the external network or external servers, and prevents them from arbitrarily accepting state change commands sent from the external network. For example, when a device has low battery and needs to enter a special energy-saving mode, its request is to "request to change its own status to 'energy-saving mode' (e.g., extend the reporting interval from 1 second to 1 minute)". After the target verification node verifies the status change request, it can approve the status change based on the verification result and notify other devices in the network through the target verification node. The data update frequency of the device's sensor will be reduced to avoid misjudging it as offline.

[0077] Of course, in addition to verifying leaf node requests, this application embodiment can also verify main chain node requests, so as to realize intelligent device collaborative authentication and abnormal node handling based on the interleaved verification topology, thereby building a decentralized, highly fault-tolerant node network to ensure that the system can still operate normally even if some nodes are attacked or fail.

[0078] In one optional implementation of this application, to avoid security issues caused by single-point dependence, each main chain node establishes a "two-way verification channel" with at least three non-adjacent nodes in the smart home system. This allows requests from the main chain node in the smart home system to be verified through at least three non-adjacent nodes. This enables collaborative authentication of smart devices and handling of abnormal nodes based on an interleaved verification chain topology, thereby strengthening the ability to identify and handle malicious device nodes, promptly detecting and cleaning up malicious device nodes, and reorganizing the network topology.

[0079] For example, when a main chain node needs to perform a significant operation that changes the network topology, security policy, or affects the overall trustworthiness of the system, it can initiate a main chain node request to start the main chain node verification process. In one alternative implementation, based on the main chain node verification process, main chain node verification can be achieved through Byzantine Fault Tolerance (BFT) consensus, such as when the main chain node requests and obtains... After obtaining the consent of n neighboring nodes, the main chain node's request is considered to have passed the final verification. Here, n is the total number of current main chain nodes.

[0080] Among them, the main chain node request refers to the request of the main chain node, which may include, but is not limited to: network topology management and self-healing request, global security policy update request, critical resource sharing and scheduling request, system-level upgrade and batch processing request, etc. This application embodiment does not limit this.

[0081] Network topology management and self-healing requests refer to requests related to network topology management and self-healing. For example, a new smart home hub (with high computing power) is powered on and wants to join the network and become a main chain node to improve the network's reliability and performance; its request would be "apply to join the ring main chain". Another example is an existing main chain node, a smart TV, that has repeatedly voted against consensus or failed to respond within timeouts, causing its reputation score to drop to an extremely low level, such as less than 0.2; its request would be "propose to remove the smart TV node from the main chain and replace it with a backup device, a smart refrigerator".

[0082] A global security policy update request refers to a request related to updating global security policies. For example, in a smart home scenario, a homeowner issues a new global rule via a mobile app: "After 11 p.m. every night, all indoor cameras will enter physical blocking (sleep) mode." The corresponding global security policy update request generated would be "Install and activate a new global privacy policy." Similarly, when the system detects a new type of spoofing attack targeting smart locks, the global security policy update request generated by a main chain node would be "Revoke the communication certificates of all smart locks and uniformly reissue new certificates."

[0083] A critical resource sharing and scheduling request refers to a request generated based on a critical resource sharing and scheduling request. For example, when a home NAS device is performing a large file backup with extremely high CPU and bandwidth usage, the home server needs to start a real-time video analysis task that requires a lot of computing resources. The request sent by the home server is a critical resource sharing and scheduling request that "proposes prioritizing the scheduling of the NAS's idle computing resources to the home server's task and suspending the low-priority backup process".

[0084] System-level upgrade and batch processing requests can refer to requests generated based on system-level upgrades and batch processing. For example, if a device manufacturer releases a core firmware security patch for all its smart devices, the request generated by the main chain node for the core firmware security patch released by the device manufacturer is a system-level upgrade and batch processing request that says "Approve and start the firmware batch upgrade process, with the upgrade order as follows: main chain node first, leaf node second".

[0085] Optionally, in this embodiment of the application, according to the target node verification process, at least two target verification nodes are selected from the main chain node pool. Specifically, this may include: when the target node verification process is a main chain node verification process, the main chain node where the network node request is currently located is taken as the main node, and based on the number of main chain nodes in the network topology, the number of broadcast nodes corresponding to the main node is determined, where the number of broadcast nodes is less than the number of main chain nodes; based on the neighbor status information of the main node, non-adjacent nodes corresponding to the number of broadcast nodes are selected from the main chain node pool; the selected non-adjacent nodes and the main node are determined as the target verification nodes. Here, the number of main chain nodes in the network topology refers to the total number of main chain nodes in the network topology; the number of broadcast nodes corresponding to the main node can refer to the number of main chain node requests that the main node needs to broadcast to neighboring nodes. For example, if the number of main chain nodes in the network topology is denoted as n, then... The number of broadcast nodes corresponding to the master node, in order to obtain Once the neighboring nodes agree, the main chain node's request can be considered to have passed the main chain node's verification, and a final authorization token can be generated.

[0086] Specifically, in this embodiment of the application, when a network node request is received as a main chain node request, a request command can be automatically generated for the main chain node request. Based on the request command, and following the main chain node verification process, the preset consensus triggering condition corresponding to the main chain node can be automatically triggered. This consensus triggering condition can be specified as follows: after receiving the command, the main chain node broadcasts it to... The most recently active neighboring nodes are selected to initiate consensus by making the main chain node the master node. The request command can be generated in any of the following three ways: generated by the main chain node itself (self-decision), triggered by external instructions (user or cloud instructions), or upgraded from a leaf node request (certain privileged operations). This application embodiment does not limit this.

[0087] As an example of this application, taking the upgrade of a leaf node request to a main chain node request as an example, if the operation requested by the leaf node request is a highly sensitive or important operation that exceeds the scope of rapid verification, it is necessary to upgrade the security verification level to the main chain consensus. For example, if a smart lock in a leaf node initiates an unlocking request, but the gateway and speaker consider the operation to be of extremely high risk (such as an unlocking request initiated by a user outside of normal home hours), they will not approve it directly. Instead, they will report it and convert it into a command that requires the main chain consensus to "approve this special unlocking." Based on this command, a corresponding main chain node request can be generated. Then, a request command can be generated for this main chain node request. According to the main chain node verification process, the main chain node where the main chain node request is currently located is taken as the main node. Based on the number of main chain nodes in the network topology, it can be determined whether the main chain node request needs to be broadcast to multiple neighboring nodes of the main node for independent verification, that is, the number of broadcast nodes corresponding to the main node can be determined.

[0088] Optionally, in this embodiment of the application, the number of broadcast nodes corresponding to the main nodes is determined based on the number of main chain nodes in the network topology. Specifically, this includes: counting all main chain nodes in the network topology to obtain the number of main chain nodes; and using the arithmetic square root of the number of main chain nodes to determine the number of broadcast nodes.

[0089] For example, suppose there are 9 nodes in the main chain of a smart home scenario, that is, there are 9 nodes in the ring main chain of the smart home system, and the number of main chain nodes is 9. When the home gateway node receives a "update firewall rules" command from the mobile APP, the home gateway node, as the main node, needs to initiate consensus. According to the consensus triggering condition, following the improved Practical Byzantine Fault Tolerance (PBFT) algorithm, the arithmetic square root of 9 is determined as the number of broadcast nodes. That is, the home gateway node needs to contact the 3 most recent active neighbor nodes to generate the final authorization token requested by the main chain node when at least 3 main chain nodes reach a consensus.

[0090] In an optional embodiment of this application, the broadcast process in the main chain node verification process may specifically include the following steps: Step 1: Each main chain node maintains a dynamic neighbor state table locally. This neighbor state table records static information such as the Internet Protocol (IP) address and public key of other main chain nodes, as well as dynamic indicators. These dynamic indicators may include, but are not limited to, parameters such as: last active timestamp, response latency, reputation score, and active status identifier. The last active timestamp refers to the time when the node's heartbeat or message was last received; the response latency refers to the average round-trip time of historical communication; the reputation score refers to the node's current reputation value; the active status identifier can be divided into online, offline, and sub-healthy identifiers. In the specific implementation, the node's active status identifier can be determined based on the last active timestamp, response latency, and reputation score. If the node's active status identifier is online, it means the node is online; if the node's active status identifier is offline, it means the node is offline; if the node's active status identifier is sub-healthy, it means the node is in a sub-healthy state.

[0091] Step 2: When a main chain node (such as a home gateway node) needs to broadcast, it acts as the main node. The specific execution process is as follows: First, exclude nodes that are clearly offline or have too low a reputation score (e.g., exclude nodes with a reputation score less than 0.5) from the entire main chain node list. If the number of chain nodes is n, exclude the other (n-1) neighbor nodes recorded in the locally maintained neighbor status table. Assuming one neighbor node is excluded, the remaining (n-2) neighbor nodes are considered as candidate nodes. Then, sort the remaining candidate nodes in descending order by their "last active timestamp". The more recent the last active time, the more active the node is currently. Finally, select the first node from the sorted list. One node is selected as the target verification node to which the broadcast needs to be sent.

[0092] Step 3: The master node (such as the home gateway node) no longer needs to broadcast to (n-1) nodes, but only to the selected nodes. The optimal node sends a consensus message to avoid network-wide broadcasting, thereby improving the PBFT process, increasing the verification efficiency of the main chain node, and reducing the amount of broadcast data. This consensus message, serving as a preparatory message to trigger the target verification node's request to verify the main chain node, may include complete command content (such as updating firewall rules), the main node's own digital signature (proving the source's credibility), current view number, sequence number, and other PBFT standard information, etc. This application embodiment does not impose limitations on these aspects.

[0093] Step 4: Handle dynamic changes in the network. For example, if the home gateway fails to send a message to the first node or times out, it can automatically select the next node (such as the 4th) from the previously sorted candidate list to replace it, ensuring that all 3 nodes successfully receive the broadcast message and participate in consensus.

[0094] As can be seen, in step 3 of the broadcast process, the main node (such as a home gateway) in this application embodiment has already sent a targeted broadcast. If the three optimal adjacent main chain nodes selected are a NAS device, a smart speaker, and a home server, consensus messages can be sent to these three optimal adjacent main chain nodes. This will trigger the NAS device, smart speaker, and home server to independently verify the requests of the main chain nodes, thereby obtaining the verification result information generated by each target verification node in response to the network node request.

[0095] Optionally, this application implements independent verification of the network node request through each of the target verification nodes to obtain verification result information of each target verification node. Specifically, this may include: determining the request command corresponding to the network node request; sending consensus messages corresponding to the request command to each of the non-adjacent main chain nodes through the master node; wherein the consensus messages are used to trigger the non-adjacent nodes to perform security verification of the request command; and determining the security verification results fed back by each of the non-adjacent nodes as the verification result information of the target verification node, so that subsequent weighted verification can be performed based on the verification result information of each target verification node and the voting weight corresponding to each target verification node to obtain the collaborative authentication result corresponding to the network node request.

[0096] Specifically, when a neighboring node receives a consensus message broadcast by the master node, it does not immediately agree. Instead, it verifies the consensus message according to the verification process initiated by the neighboring node after receiving the broadcast. This verification process may include the following steps: Step 1: Perform protocol-level verification, such as basic message format and identity verification. Specifically, this may include digital signature verification, message integrity verification, and view and sequence number checks. The following example, "updating firewall rules," illustrates the verification process after a neighboring node receives a broadcast. For instance, during digital signature verification, the NAS device can use the home gateway's known public key to decrypt and verify the digital signature attached to the message, confirming that the message legitimately originates from the home gateway and is not maliciously impersonated by a hacker. Subsequently, message integrity verification can be performed, calculating the hash value of the received message and comparing it with the hash digest contained in its signature to confirm that the message has not been tampered with during transmission. During the view and sequence number check, the view number and sequence number in the message can be checked to ensure they are within the expected range, preventing repeated attacks and ensuring the consensus state machine progresses correctly. If any of these three steps fails, the NAS device discards the message and records a misbehavior of the home gateway.

[0097] Step 2: Perform business logic verification, i.e., request content legality verification, verifying whether the operation (updating firewall rules) itself is permitted. Specifically, firstly, permission verification can be performed, such as the NAS device checking whether the home gateway node has permission to initiate the "update firewall rules" operation. During systemization, network management permissions for each main chain node are initialized. For example, the router and home gateway have network management permissions, while the smart TV does not; if the smart TV initiates such a request, it will be rejected. Secondly, semantic verification is performed. The NAS device parses the specific content of the firewall rules and then performs blacklist checks, such as determining whether the rule attempts to block a known security update server IP. Subsequently, a reasonableness check is performed, such as verifying the rule's syntax format, whether the port used is reasonable (e.g., commonly used 80, 443) and not a high port that is permissible; and a conflict check is performed, such as comparing with existing rules to see if the new rule conflicts with existing core security policies. Finally, context verification is performed. The NAS device combines context information to determine whether the update request was triggered during a low-traffic period at night. Triggering during a low-traffic period is more reasonable. If it occurs during a high-risk period when a known network attack is underway, the request may be considered malicious.

[0098] Step 3: Perform local state verification. After completing the checks in the previous two steps, the NAS device can compare its local records to determine if the current firewall version is newer, or if other nodes have sent similar content that contradicts the current request. After determining whether it is updated, a final confirmation is made. Only when all three layers of verification pass will the NAS device consider the request legitimate, enter the preparation phase, and broadcast a "preparation" message to other consensus group members. In addition to the NAS device, the other three main chain nodes—the smart speaker, home server, and home gateway—can also perform independent verification according to the three steps in the post-broadcast verification process. After obtaining the verification result information generated by each target verification node in response to the network node request, a weighted verification is performed based on the verification result information of each target verification node and the corresponding voting weight of each target verification node to obtain the collaborative authentication result corresponding to the network node request.

[0099] In summary, after selecting target verification nodes according to the main chain node verification process, this application embodiment can independently verify the network node request through each target verification node based on the preset consensus triggering conditions corresponding to the main chain node verification process, so as to obtain the verification result information generated by each target verification node for the network node request. Then, based on the verification result information of each target verification node and the voting weight corresponding to each target verification node, weighted verification can be performed to obtain the collaborative authentication result corresponding to the network node request.

[0100] Optionally, in this embodiment, based on the verification result information of each target verification node and combined with the voting weight corresponding to each target verification node, a weighted verification is performed to obtain the collaborative authentication result corresponding to the network node request. Specifically, this may include: using the security verification result fed back by each of the non-adjacent nodes, determining the vote corresponding to each of the non-adjacent nodes, wherein the vote is divided into affirmative votes and negative votes; when the number of affirmative votes reaches the voting number threshold corresponding to the number of broadcast nodes, generating the collaborative authentication result based on the authorization token information corresponding to the request command. Here, an affirmative vote can represent the "agree" vote cast by a target verification node when a network node request passes independent verification; a negative vote can represent the "reject" vote cast by a target verification node when a network node request fails independent verification.

[0101] In one optional implementation of this application, for main chain node requests, based on the improved Practical Byzantine Fault Tolerance (PBFT) process, the main chain node verification process can be divided into: a pre-preparation phase, a preparation phase, and a submission phase. The pre-preparation phase can be used to initiate a node broadcast request, which can be accompanied by a digital signature so that the legality of the node broadcast request can be verified subsequently based on the digital signature. The preparation phase can be used to verify the legality of the node's request by checking parameters such as permissions and data formats to determine the legality of the main chain node request. The submission phase can determine whether to generate a final authorization token by counting whether the number of signing nodes is greater than or equal to the number of broadcast nodes. Specifically, a final authorization token is generated when the number of affirmative votes reaches the threshold corresponding to the number of votes from the broadcast nodes. This final authorization token serves as the authorization token information corresponding to the request command, so that the collaborative authentication result corresponding to the main chain node request can be generated subsequently based on this authorization token information.

[0102] For example, after a main chain node initiates the main chain node verification process in response to a main chain node request, it can achieve main chain node verification through Practical Byzantine Fault Tolerance (PBFT) consensus. Specifically, after the main chain node initiates PBFT consensus based on preset consensus triggering conditions in response to the main chain node request, such as... Figure 6 As shown, for the currently obtained main chain node request, the corresponding request command can be broadcast to... Each node, to pass Each node undergoes a three-phase verification process, which allows for determination of whether a node has been verified after each phase. Each node agrees to execute the main chain node's request in order to obtain the main chain node's request. Once the neighboring nodes agree, an authorization token can be generated, which can then be used to execute the corresponding operations requested by the main chain node; otherwise, if the main chain node does not grant the authorization token... If neighboring nodes agree, consensus can fail, and it can be concluded that the current main chain node's request has not passed the final collaborative authentication.

[0103] Specifically, during the main chain node verification process, if the main chain node collects enough valid "commit" stage "agreement" votes, it can generate an aggregate signature, create a multi-signature transaction, or generate a digital certificate or token file containing the signatures of all voting nodes. Subsequently, by encapsulating the token, a final authorization token is generated and broadcast throughout the network as the authorization token information corresponding to the request command. For example, after a home gateway receives valid "agreement" votes from NAS devices, smart speakers, and home servers, it can determine the number of "yes" votes by counting the number of valid "agreement" votes. If the number of "agreement" votes reaches the threshold corresponding to the number of broadcast nodes, the home gateway is considered to have collected enough "agreement" votes. The home gateway will then generate an aggregate signature, create a multi-signature transaction, or generate a digital certificate or token file containing the signatures of all voting nodes. By encapsulating the token, it broadcasts the encapsulated token as the final authorization token throughout the network, allowing other nodes in the network to receive the final authorization token broadcast by the home gateway. The final authorization token can include information such as operation instructions (e.g., "execute the following firewall rule: xxx"), consensus proof, serial number, master node signature, etc. The consensus proof can be used to represent the node ID and its signature set that agree to this operation. The serial number serves as a unique number for this consensus and can prevent replay. The master node signature can be used to represent that the master node has made a final signature on the entire token content, ensuring that the proof itself has not been tampered with.

[0104] Specifically, after receiving the final authorization token, network nodes in the network can verify its validity. Only after the final authorization token passes verification can they execute the operation requested by the network node, ensuring the secure and stable operation of the smart home system. Optionally, to ensure the secure and stable operation of the smart home system, the collaborative authentication processing method provided in this application, after obtaining the coordinated verification corresponding to the network node request, further includes the following step: in response to the collaborative authentication result, sending the authorization token information to each network node in the smart home system, so that each network node in the smart home system can execute the request command based on the authorization token information, thereby completing the operation requested by the network node. The network node is used to execute the request command based on the authorization token information.

[0105] For example, after the home gateway generates a token for updating the firewall, it can send this token as the final authorization token to the router. Upon receiving the token, the router can verify the home gateway's signature based on the token and check the node list in the token to confirm if there is a node greater than or equal to... Each trusted mainchain node participates in the vote. Optionally, the validity of several signatures in the list can be randomly checked to determine the token's validity. After successful verification, the router can directly apply the new firewall rules. Even if a malicious node later informs the router "don't trust that token," the router will reject it based on its own verification results. If a network node in the smart home system frequently opposes legitimate requests, its reputation score can be lowered according to the dynamic verification protocol, potentially leading to its exclusion from the consensus group. For example, dynamic weight adjustments can reduce the weight of low-reputation nodes, limiting their destructive power and thus enabling the handling of malicious behavior.

[0106] Optionally, in scenarios involving malicious detection and self-repair in smart home systems, such as... Figure 7 As shown, behavior monitoring can be used to monitor the behavior of each network node in a smart home system. Based on the behavior monitoring results, and according to the corresponding preset dynamic verification protocol of the smart home system, the reputation score of each network node is updated. This means that the reputation score of a network node is updated in real time based on the behavior monitoring results. It can also determine whether the reputation score of a network node is lower than a preset isolation score threshold. If the reputation score of a network node is lower than the preset isolation score threshold, the network node is considered to need to be isolated, and thus the devices associated with that network node are isolated, achieving automatic device isolation. For example, when the preset isolation score threshold is 0.3, after updating the reputation score of a network node, it can be determined whether the reputation score of that network node is lower than the isolation score threshold of 0.3. If the current reputation score of a network node is lower than the isolation score threshold of 0.3, the network node can be isolated, and the devices associated with that network node can be isolated. If the current reputation score of a network node is not lower than the isolation score threshold of 0.3, monitoring can continue to monitor the behavior of the network node.

[0107] When an abnormal behavior is detected in a network node, that node can be identified as an abnormal network node. Anomaly detection can then be performed to determine the fault type of the abnormal network node. For example, the handling method can be determined based on the number of devices with the fault type. For instance, when there is only one device with the fault type (i.e., a single device), a path switch can be performed within a preset device switching time of 3 seconds to achieve network topology reorganization. However, if there are many devices with the fault type, it can be determined that the fault type is a main chain intrusion. A backup device can be activated within a preset main chain switching time of 30 seconds to achieve network topology reorganization. This allows the construction of a decentralized, highly fault-tolerant node network, ensuring that the system can still operate normally even if some nodes are attacked or fail.

[0108] It should be noted that, for the sake of simplicity, the method embodiments are described as a series of actions. However, those skilled in the art should know that the embodiments of this application are not limited to the described order of actions, because according to the embodiments of this application, some steps may be performed in other orders or simultaneously.

[0109] Figure 8 This is a schematic diagram of the structure of a collaborative authentication processing system provided in an embodiment of this application. Figure 8 As shown, the collaborative authentication processing system 800 provided in this embodiment includes: a ring main chain core verification layer 810 built based on a smart home system, wherein the ring main chain core verification layer 810 includes a main chain node 811, and the main chain node is configured to implement the collaborative authentication processing method provided in any of the foregoing embodiments of this application.

[0110] In one optional embodiment of this application, the main chain node may be equipped with a collaborative authentication processing device. This device is configured to implement the collaborative authentication processing method provided in any of the foregoing embodiments of this application. After obtaining a network node request from the smart home system, the main chain node can select at least two target verification nodes from the main chain node pool of the smart home system based on the request type. Then, it independently verifies the network node request through each target verification node. This allows the verification result information of each target verification node to be obtained. Subsequently, based on the verification result information of each target verification node and its corresponding voting weight, a weighted verification is performed to obtain the collaborative authentication result corresponding to the network node request. This allows subsequent determination of whether the network node request passes verification based on the collaborative authentication result, ensuring the stable operation of the smart home system.

[0111] In practical implementation, smart home appliances with intelligent functions can be used as network nodes in the smart home system. These network nodes can be used to form a hierarchical verification structure in the smart home system. This allows for collaborative authentication of smart devices and handling of abnormal nodes based on device-level interleaved verification topology, ensuring the stable operation of the smart home system. This solves the problem of high risk of centralized gateways caused by the use of a single gateway to control all devices in existing technologies, and meets users' security needs for smart homes.

[0112] like Figure 9As shown, this application embodiment provides an electrical device, including a processor 111, a communication interface 112, a memory 113, and a communication bus 114. The processor 111, communication interface 112, and memory 113 communicate with each other via the communication bus 114. The memory 113 stores computer programs. When the processor 111 executes the program stored in the memory 113, it implements the collaborative authentication processing method provided in any of the aforementioned method embodiments, including: obtaining network node requests in a smart home system; selecting at least two target verification nodes from the main chain node pool of the smart home system according to the request type of the network node requests; independently verifying the network node requests through each target verification node to obtain verification result information for each target verification node; and performing weighted verification based on the verification result information of each target verification node and the voting weight corresponding to each target verification node to obtain the collaborative authentication result corresponding to the network node request.

[0113] In specific implementations, the electrical equipment in the embodiments of this application may include, but is not limited to, refrigeration equipment such as air conditioners and refrigerators, and may also include other types of electrical equipment such as washing machines. The embodiments of this application do not impose specific limitations on this.

[0114] This application also provides a computer-readable storage medium storing a computer program thereon, which, when executed by a processor, implements the collaborative authentication processing method provided in any of the foregoing method embodiments.

[0115] The system, device, and medium embodiments described above are merely illustrative. The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the modules can be selected to achieve the purpose of this embodiment according to actual needs.

[0116] Through the above description of the embodiments, those skilled in the art can clearly understand that each embodiment can be implemented by means of software plus a general-purpose hardware platform, and of course, it can also be implemented by hardware. Based on this understanding, the above technical solutions, in essence or the parts that contribute to the related technology, can be embodied in the form of a software product. This computer software product can be stored in a computer-readable storage medium, such as ROM / RAM, magnetic disk, optical disk, etc., and includes several instructions to cause a computer device (which may be a personal computer, server, or electrical device, etc.) to execute the methods described in the various embodiments or some parts of the embodiments.

[0117] It should be understood that the terminology used herein is for the purpose of describing particular exemplary embodiments only and is not intended to be limiting. Unless the context clearly indicates otherwise, the singular forms “a,” “an,” and “described” as used herein may also include the plural forms. The terms “comprising,” “including,” “containing,” and “having” are inclusive and therefore indicate the presence of the stated features, steps, operations, elements, and / or components, but do not exclude the presence or addition of one or more other features, steps, operations, elements, components, and / or combinations thereof. The method steps, processes, and operations described herein are not construed as requiring them to be performed in a particular order described or illustrated unless the order of performance is explicitly indicated. It should also be understood that additional or alternative steps may be used.

[0118] The above description is merely a specific embodiment of the present invention, enabling those skilled in the art to understand or implement the invention. Various modifications to these embodiments will be readily apparent to those skilled in the art, and the general principles defined herein may be implemented in other embodiments without departing from the spirit or scope of the invention. Therefore, the present invention is not to be limited to the embodiments shown herein, but is to be accorded the widest scope consistent with the principles and novel features claimed herein.

Claims

1. A collaborative authentication processing method, characterized in that, include: Obtain network node requests from the smart home system; Based on the request type of the network node request, at least two target verification nodes are selected from the main chain node pool of the smart home system; The network node request is independently verified through each of the target verification nodes to obtain the verification result information of each target verification node. Based on the verification results of each target verification node, and combined with the voting weights of each target verification node, a weighted verification is performed to obtain the collaborative authentication result corresponding to the network node request.

2. The method according to claim 1, characterized in that, Based on the request type of the network node request, at least two target verification nodes are selected from the main chain node pool of the smart home system, including: The request type is determined based on the request command parameters carried by the network node request; The preset node verification process corresponding to the request type is determined as the target node verification process; According to the target node verification process, at least two target verification nodes are selected from the main chain node pool.

3. The method according to claim 2, characterized in that, The step of selecting at least two target verification nodes from the main chain node pool according to the target node verification process includes: In the case that the target node verification process is a leaf node verification process, based on the network topology of the smart home system, at least two non-adjacent main chain nodes are selected from the main chain node pool. The selected non-adjacent main chain nodes are determined as the target verification nodes corresponding to the network node request.

4. The method according to claim 3, characterized in that, The step of independently verifying the network node request through each of the target verification nodes to obtain the verification result information of each target verification node includes: Based on the leaf node verification process, the verification task corresponding to the network node request is distributed to each target verification node, wherein the verification task is used to trigger the target verification node to independently execute the verification work corresponding to the network node request; The verification result information generated by each target verification node is determined as the verification result information, which includes the result information generated by the target verification node after completing the verification work.

5. The method according to any one of claims 1 to 4, characterized in that, The weighted verification, based on the verification result information of each target verification node and the voting weight of each target verification node, yields the collaborative authentication result corresponding to the network node request, including: Obtain the current reputation score information for each of the target verification nodes; The voting weight of each target verification node is determined based on its current reputation score. Based on the voting weights of each target verification node, and combined with the result score corresponding to the verification result information of each target verification node, the total verification score corresponding to the network node request is calculated. The collaborative authentication result is generated using the total verification score.

6. The method according to claim 5, characterized in that, The total verification score for the network node request is calculated based on the voting weights of each target verification node and the result score corresponding to the verification result information of each target verification node, including: For each target verification node, the voting score corresponding to the target verification node is determined by multiplying the result score and the verification voting weight. The total verification score is obtained by summing the votes for each target verification node.

7. The method according to claim 2, characterized in that, The step of selecting at least two target verification nodes from the main chain node pool according to the target node verification process includes: In the case where the target node verification process is the main chain node verification process, the main chain node where the network node request is currently located is taken as the main chain node, and the number of broadcast nodes corresponding to the main chain node is determined based on the number of main chain nodes in the network topology, wherein the number of broadcast nodes is less than the number of main chain nodes. Based on the neighbor status information of the master node, select non-adjacent nodes corresponding to the number of broadcast nodes from the main chain node pool; The selected non-adjacent nodes and the master node are determined as the target verification nodes.

8. The method according to claim 7, characterized in that, The step of independently verifying the network node request through each of the target verification nodes to obtain the verification result information of each target verification node includes: Determine the request command corresponding to the network node request; The master node sends consensus messages corresponding to the request command to each of the non-adjacent main chain nodes; wherein, the consensus messages are used to trigger the non-adjacent nodes to perform security verification on the request command. The security verification result returned by each of the non-adjacent nodes is determined as the verification result information.

9. The method according to claim 7, characterized in that, The determination of the number of broadcast nodes corresponding to the main chain nodes based on the network topology includes: The number of main chain nodes is obtained by counting all main chain nodes in the network topology. The number of broadcast nodes is determined by using the square root of the number of master nodes.

10. The method according to claim 8, characterized in that, The weighted verification, based on the verification result information of each target verification node and the voting weight of each target verification node, yields the collaborative authentication result corresponding to the network node request, including: The vote corresponding to each non-adjacent node is determined by using the security verification result fed back by each non-adjacent node, and the vote is divided into affirmative votes and negative votes; When the number of affirmative votes reaches the voting threshold corresponding to the number of broadcast nodes, the collaborative authentication result is generated based on the authorization token information corresponding to the request command.

11. A collaborative authentication processing system, characterized in that, include: A ring-shaped main chain core verification layer is constructed based on a smart home system. The ring-shaped main chain core verification layer includes main chain nodes, which are configured to implement the collaborative authentication processing method as described in any one of claims 1 to 10.

12. An electrical appliance, characterized in that, include: The processor, communication interface, memory, and communication bus are connected, with the processor, communication interface, and memory communicating with each other via the communication bus. Memory, used to store computer programs; When a processor executes a program stored in memory, it implements the steps of the collaborative authentication processing method as described in any one of claims 1-10.

13. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by the processor, it implements the collaborative authentication processing method as described in any one of claims 1-10.

Images