Key update method, network device, system and storage medium

Abstract

The present application provides a key update method, network device, system and storage medium, which are applied to a Bluetooth Mesh network. The Bluetooth Mesh network includes at least two network nodes. The configuration node is a network node in the Bluetooth Mesh network. The configuration node is used to configure the network key of the Bluetooth Mesh network. The configuration node determines a first network node from the network nodes of the Bluetooth Mesh network. The network key locally maintained by the first network node is inconsistent with the first network key of the current Bluetooth Mesh network. Therefore, the configuration node encrypts the first network key using the device key of the first network node to obtain a first ciphertext, and sends a first message carrying the first ciphertext, so that the first network node obtains the first network key. In this way, the latest key can be provided to the first network node that missed the key update process, and the user does not need to manually restore the network key, thereby improving the efficiency of network key recovery.

Description

Technical Field

[0001] The present application relates to the field of communication technology, and in particular to a key updating method, network device, system and storage medium. Background Art

[0002] As a wireless multi-hop interconnection technology for low-power and low-consumption devices, Bluetooth has entered the application environment of smart homes as a networking method for the Internet of Things (IoT) together with Wi-Fi technology and ZigBee technology. Bluetooth Mesh networking is also gradually being applied to the IoT field.

[0003] In a wireless network built using Bluetooth Mesh networking technology (hereinafter referred to as Bluetooth Mesh network), each Mesh node stores a network key (Netkey). When Mesh nodes communicate with each other, they encrypt information through Netkey before exchanging information. In order to prevent trash-can attacks, whenever a Mesh node is deleted in the Bluetooth Mesh network, the Netkey needs to be updated in the entire Bluetooth Mesh network.

[0004] However, if the Mesh node misses the key update process for some reason, then the Mesh node will not be able to obtain the latest Netkey, resulting in the Mesh node being unable to communicate with other Mesh nodes in the Bluetooth Mesh network. Summary of the invention

[0005] The present application provides a key update method, a network device, a system and a storage medium, which are used to provide the latest key for a network node that has missed a key update process.

[0006] In a first aspect, the present application provides a key update method, which is applied to a Bluetooth Mesh network, wherein the Bluetooth Mesh network includes at least two network nodes, and the configuration node is a network node in the Bluetooth Mesh network. The configuration node is used to configure the network key of the Bluetooth Mesh network. The method includes: the configuration node determines a first network node from the network nodes of the Bluetooth Mesh network, and the network key locally maintained by the first network node is inconsistent with the first network key of the current Bluetooth Mesh network. Thus, the configuration node uses the device key of the first network node to encrypt the first network key to obtain a first ciphertext, and then, the configuration node sends a first message (that is, message 1 in the subsequent specific implementation method) so that the first network node obtains the first network key, and the first message carries the first ciphertext.

[0007] In other words, when the first network node misses the key update process, the network key locally maintained by the first network node is inconsistent with the first network key. At this time, the configuration node sends a first message to it so that it obtains the first network key. The first message carries a first ciphertext obtained by encrypting the first network key by the configuration node using the device key of the first network node, so that only the configuration node and the first network node in the entire Bluetooth Mesh network can decrypt the first message, thereby ensuring communication security.

[0008] Through the solution provided in this embodiment, a method for recovering the network key is provided for the first network node that missed the key update process, without the need for the user to manually re-add the first network node to the Mesh network, thereby improving the efficiency of network key recovery.

[0009] In the embodiment of the present application, the Bluetooth Mesh network may include long power nodes and low power nodes (Low Power Node, LPN) nodes. Among them, the long power node generally has no sleep state; while the LPN node has a sleep state and a wake-up state to reduce the power consumption of the LPN node. Alternatively, the long power node can also be understood as other network nodes in the Bluetooth Mesh network except the LPN node.

[0010] On the one hand, after switching from the sleep state to the awake state, the LPN node can send a second message to the configuration node based on its own situation (the method shown in the subsequent second aspect is described in detail and is not explained here in detail) to actively request the update and synchronization of the network key.

[0011] In a possible embodiment, the configuration node determines the first network node from the network nodes of the Bluetooth Mesh network, including: the configuration node receives a second message (i.e., message 2 in the subsequent specific implementation), the second message is used to request synchronization of the network key; when the network node indicated by the requester identifier carried by the second message is not a deleted node, the configuration node determines the network node indicated by the requester identifier carried by the second message as the first network node. In other words, any network node in the Bluetooth Mesh network can actively request synchronization of the network key from the configuration node, and accordingly, the configuration node regards it as the first network node and sends the first message to it, so that it obtains the first network key of the current Bluetooth Mesh network and realizes synchronization of the network key.

[0012] On the other hand, the long power supply node does not have a dormant state. Therefore, for the long power supply node whose key update fails as recorded by the configuration node, the configuration node can actively restore the key after the key update process is completed.

[0013] In a possible embodiment, the configuration node determines the first network node from the network nodes of the Bluetooth Mesh network, including: the configuration node determines each long power supply node in the update failure list as the first network node; wherein the update failure list is used to record all network nodes in the Bluetooth Mesh network that have failed to update the secret key and are not deleted nodes; the long power supply node is other network nodes in the Bluetooth Mesh network except low-power nodes. In other words, the configuration node can actively perform secret key recovery processing on all long power supply nodes in the update failure list, that is, the configuration node sends a first message to all long power supply nodes in the update failure list (at this time as the first network node).

[0014] In addition, the configuration node can send the first message to multiple first network nodes respectively, and the first messages sent by the configuration node to different first network nodes are different. This is because any first network node has a unique device key, that is, the device keys of multiple first network nodes are different. Then, the first ciphertexts obtained by encrypting the first network key with different device keys are also different. In other words, the first ciphertexts carried in the first messages of different first network nodes are different, and the first messages sent by the configuration node to different first network nodes are different.

[0015] In one possible design, the key method provided in the embodiment of the present application can be applied to the key update process and executed in conjunction with the key update process. For example, when a new network node joins or a network node exits the Bluetooth Mesh network, the key update process can be started; and for the network node that missed the key update process, it can be used as the first network node, and the configuration node executes the aforementioned key update method so that the first network node obtains the first network key. In this way, a method for recovering keys can be provided for network nodes that missed the key update, without the user having to manually re-add the first network node to the Mesh network, thereby improving the efficiency of network key recovery.

[0016] Furthermore, the configuration node can also maintain an update failure list after the key update process is completed. Specifically, the method also includes: determining that the network node that has not received the first notification is an update failure node, and obtaining an update failure list, wherein the first notification is used to notify the configuration node that the network node has successfully received the first network key.

[0017] In an embodiment of the present application, the configuration node is a Mesh gateway in a Bluetooth Mesh network; or, the configuration node is other long power supply nodes.

[0018] In an embodiment of the present application, the first message is a broadcast frame, and the first message carries the identifier of the first network node. Specifically, the first message can be a configuration broadcast frame, that is, a configuration Beacon. Exemplarily, the identifier of the first network node can be a media access control (MAC) address of the first network node.

[0019] In one embodiment of the present application, the aforementioned second message, that is, message 2 in the subsequent specific implementation, may also be a configuration broadcast frame (configuration Beacon), and carry the identifier of the configuration node. Exemplarily, the identifier of the configuration node may be the MAC address of the configuration node.

[0020] In a second aspect, the present application provides a key update method, which is applied to a Bluetooth Mesh network, wherein the Bluetooth Mesh network includes at least two network nodes, the configuration node is a network node in the Bluetooth Mesh network, the configuration node is used to configure the network key of the Bluetooth Mesh network, and the first network node is any network node other than the configuration node, and the method includes: the first network node sends a second message to the configuration node, and the second message is used to request synchronization of the network key; after the configuration node receives the second message, the first network node sends a first message to the first network node, and the first network node receives the first message from the configuration node, and the first message carries a first ciphertext, and the first ciphertext is obtained by encrypting the first network key of the Bluetooth Mesh network using the device key of the first network node. The network key locally maintained by the first network node is inconsistent with the first network key; the first network node decrypts the first ciphertext using the device key of the first network node to obtain the first network key; the first network node updates the locally maintained network key to the first network key.

[0021] Through the solution provided by this embodiment, the first network node can actively request the configuration node to synchronize the network key, and use the device key of the first network node to decrypt the first ciphertext carried in the first message from the configuration node, so as to obtain the first network key of the current Bluetooth Mesh network and realize key synchronization. In this process, the device key of the first network node is only known by the configuration node and the first network node, which is beneficial to the security of the first message during the message transmission process, and through this method, a method for recovering the network key is provided for the first network node that misses the key update process, and the user does not need to manually re-add the first network node to the Mesh network, thereby improving the efficiency of network key recovery.

[0022] In a possible embodiment, after completing the aforementioned key update process, the first network node may further send a third message to the configuration node, where the third message is used to indicate that the first network node has successfully synchronized the first network key.

[0023] In a possible embodiment, after the first network node completes the aforementioned key update process, the first network node may also use the first network key to update the entire network encryption index (IV Index), update the application key (APP Key) or reset the local sequence number (SegNum).

[0024] In a possible embodiment, when the first network node fails to establish friendship multiple times after being awakened, the first network node may send a second message to the configuration node.

[0025] Specifically, when the first network node switches from a dormant state to an awake state, the first network node sends a fourth message to a second network node; wherein the second network node has established a friend relationship with the first network node (in this embodiment, the second network node is a friend node of the first network node), and the second network node is used to temporarily store messages for the first network node while the first network node is in a dormant state; the fourth message is used to request to obtain the message temporarily stored by the second network node for the first network node. Exemplarily, the fourth message may be a Friend Poll message.

[0026] If no feedback message is received from the second network node within a preset first time period, the first network node may intermittently (for example, periodically) send a fourth message to the second network node until feedback is received from the second network node, or the number of times the fourth message is sent reaches a preset first threshold.

[0027] Then, when the number of times the fourth message is sent reaches a preset first threshold and no feedback message is received from the second network node, the first network node broadcasts a fifth message, the fifth message being used to request to establish a friend relationship. Exemplarily, the fifth message may be a Friend Request message.

[0028] When the number of times the fifth message is sent reaches a preset second threshold and no feedback message is received from other network nodes, the first network node sends the second message (ie, message 2) to the configuration node.

[0029] In a third aspect, the present application provides a network device, comprising: at least one processor and a memory; the memory stores computer-executable instructions; the at least one processor executes the computer-executable instructions, so that the network device executes a method as described in any one of the embodiments of the first aspect or the second aspect.

[0030] In a fourth aspect, the present application provides a network system comprising: at least two network nodes, wherein a configuration node is a network node in the Bluetooth Mesh network, the configuration node is used to configure a network key of the Bluetooth Mesh network, and is used to execute a method as described in any one of the embodiments of the first aspect; any other network node except the configuration node is used to execute the method as described in any one of the embodiments of the second aspect.

[0031] In a fourth aspect, the present application provides a computer-readable storage medium, wherein the computer-readable storage medium stores computer-executable instructions. When a processor executes the computer-executable instructions, the method described in the first aspect or the second aspect is implemented.

[0032] In a fifth aspect, the present application provides a computer program, which, when executed by a computer, is used to execute the method described in the first aspect or the second aspect.

[0033] In one possible design, the program in the fifth aspect may be stored in whole or in part on a storage medium packaged together with the processor, or may be stored in whole or in part on a memory not packaged together with the processor.

[0034] In summary, the key update method, network device, system and storage medium provided in the embodiments of the present application, in each node of the Bluetooth Mesh network, use the device key of the first network node to encrypt the first network key of the current Bluetooth Mesh network, wherein the network key locally maintained by the first network node is inconsistent with the first network key of the current Bluetooth Mesh network, so that the configuration node sends the first ciphertext obtained by encrypting the first network key to it, so that the first network node can synchronize the first network key, and can provide a method for synchronizing the latest network key for the first network node that missed the key update process, and only the configuration node and the first network node in the entire Bluetooth Mesh network can decrypt the first message, thereby ensuring the communication security of the key update process. BRIEF DESCRIPTION OF THE DRAWINGS

[0035] Figure 1 A schematic diagram of the architecture of a Bluetooth Mesh network provided for this application;

[0036] Figure 2 A schematic diagram of a Bluetooth Mesh network applied to a smart home application scenario provided in an embodiment of the present application;

[0037] Figure 3 A message interaction diagram of a key update method in the prior art;

[0038] Figure 4 A message interaction diagram of a key update method provided by this application;

[0039] Figure 5 A message interaction diagram of a key recovery method provided by this application;

[0040] Figure 6 A message interaction diagram of another key recovery method provided by this application;

[0041] Figure 7 A message interaction diagram of another key recovery method provided by this application;

[0042] Figure 8 A message interaction diagram of another key recovery method provided by this application;

[0043] Fig. 9 A message interaction diagram of another key recovery method provided in this application. DETAILED DESCRIPTION

[0044] Hereinafter, the implementation of this embodiment will be described in detail with reference to the accompanying drawings.

[0045] In the present application, "at least one" means one or more, and "plurality" means two or more. "And / or" describes the association relationship of associated objects, indicating that three relationships may exist. For example, A and / or B can mean: A exists alone, A and B exist at the same time, and B exists alone, where A and B can be singular or plural. The character " / " generally indicates that the previous and next associated objects are in an "or" relationship. "At least one of the following" or similar expressions refers to any combination of these items, including any combination of single or plural items. For example, at least one of a, b, or c can mean: a, b, c, ab, ac, bc, or abc, where a, b, c can be single or multiple.

[0046] The embodiments of the present application can be applied to any Bluetooth Mesh network.

[0047] Among them, the Bluetooth Mesh network is a many-to-many network (Many to Many). In a Bluetooth Mesh network, multiple network nodes may be included. A network node is also a node of a Bluetooth Mesh network. A network node may also be referred to as: a node, a Mesh node, a device node, a Mesh device, etc. The present application embodiment has no special restrictions on its naming. In a Bluetooth Mesh network, each network node can communicate freely with other network nodes, and a relay node can relay and forward received messages. In this way, in a Bluetooth Mesh network, a message can be relayed and forwarded by one or more Mesh nodes to reach the receiving end, which greatly expands the transmission range of the message and the coverage of the Mesh network.

[0048] For example, Figure 1 A schematic diagram of a Bluetooth Mesh network provided in an embodiment of the present application is shown. Figure 1 The Bluetooth Mesh network 100 shown includes multiple network nodes, including a gateway node (or Mesh gateway, Mesh gateway node, etc.). The Mesh gateway is used to realize the communication between the Bluetooth Mesh network and other networks. For example, the Bluetooth Mesh network can communicate with wireless fidelity (Wireless-Fidelity, WiFi) network, ZigBee (ZigBee protocol) network and other networks through the Mesh gateway. Figure 1 Specific instructions.

[0049] A Bluetooth Mesh network 100 may include a Mesh gateway. In addition, the Bluetooth Mesh network may also include other Mesh nodes. Figure 1 As shown, the Bluetooth Mesh network 100 includes: a Mesh gateway 110 and a plurality of Mesh nodes: Mesh node 111 - Mesh node 117 .

[0050] In a Bluetooth Mesh network, other Mesh nodes may be directly connected to the Mesh gateway 110, or may be indirectly connected to the Mesh gateway 110 through one or more other Mesh nodes. Figure 1 As shown, Mesh node 111 is directly connected to Mesh gateway 110 , Mesh node 112 and Mesh node 113 are connected to Mesh gateway 110 via Mesh node 114 , and Mesh node 115 and Mesh node 116 are connected to Mesh gateway 110 via Mesh node 117 .

[0051] It should be understood that Figure 1The number and connection relationship of the Mesh nodes included in the Bluetooth Mesh network shown are only examples, and the embodiments of the present application are not limited thereto. For example, the Bluetooth Mesh network can also include more or fewer Mesh nodes, and for another example, one or more of the Mesh nodes 111 to 117 can be connected to more Mesh nodes.

[0052] Mesh nodes can be divided according to whether they are in a dormant state. Specifically, the Mesh nodes in the Bluetooth Mesh network 100 can be divided into long power nodes and low power nodes (LPN). Among them, long power nodes generally have no dormant state; while LPN nodes have dormant state and awake state to reduce the power consumption of LPN nodes.

[0053] In an exemplary embodiment, the Mesh node directly connected to the power supply can be a long power supply node, and the Mesh node powered by a battery or other mobile power supply (or device) can be an LPN node. For example, the long power supply node can be an electronic device such as a TV or computer connected to a power supply. These long power supply nodes can communicate with other Mesh nodes through a Bluetooth module; while the LPN node can be an electronic device such as a mobile phone with Bluetooth function, a Bluetooth headset, a Bluetooth speaker, etc. These LPN nodes are generally not connected to the power supply for a long time, and can be powered by a battery, etc., and communicate with other Mesh nodes.

[0054] In a Bluetooth Mesh network, the Mesh gateway is a long power node. Other Mesh nodes except the Mesh gateway include long power nodes and LPN nodes. The LPN node can be directly connected to the Mesh gateway, or indirectly connected to the Mesh gateway through one or more other Mesh nodes (long power nodes).

[0055] For example, in Figure 1 In the Bluetooth Mesh network 100 shown, the Mesh gateway 110 is a long power supply node. In addition, Mesh node 114 and Mesh node 117 can be long power supply nodes, and other nodes, such as Mesh node 111 to Mesh node 113, Mesh node 115 to Mesh node 116, can be LPN nodes. Among them, the LPN node (such as Mesh node 111) can be directly connected to the Mesh gateway 110; or, the LPN node (such as Mesh node 112 to Mesh node 113, Mesh node 115 to Mesh node 116) can be connected to the Mesh gateway 110 through a long power supply node, and the long power supply node acts as a relay node or a friend node.

[0056] When dividing Mesh nodes according to their functional roles, Bluetooth Mesh networks can include the following: Mesh gateway nodes (or called: Bluetooth Mesh gateway), Bluetooth relay nodes (Mesh Relay node), proxy nodes (Proxynode), friend nodes (Friend node) and Bluetooth LPN nodes.

[0057] The Mesh gateway is used to connect the Bluetooth Mesh network to other networks, such as the following Figure 1 In the scenario shown, the Bluetooth Mesh network and the WiFi router can be connected through the Mesh gateway, and then connected to other networks, which will be described in detail later.

[0058] In addition, the Mesh gateway can also serve as a provisioner and / or configuration client. The provisioner is responsible for accessing Mesh nodes in the full Bluetooth Mesh network, and the configuration client is responsible for the full network configuration, including but not limited to the configuration of Netkey.

[0059] It should be noted that in actual scenarios, the Mesh gateway generally serves as a network access manager and a configuration client. However, in actual scenarios, the embodiments of the present application do not specifically limit whether the configuration client and the network access manager are Mesh gateways.

[0060] Specifically, the configuration client and the network manager can be implemented through one or more long power supply nodes. For ease of explanation, the Mesh node responsible for the whole network configuration function described in the configuration client will be referred to as the configuration node. Figure 1 In the Bluetooth Mesh network 100 shown, the Mesh gateway 110 (a long power supply node) can be used as a configuration client and a network access manager to assume the configuration function of the Netkey of the entire network (Bluetooth Mesh network) and the network access management function of the entire network. Alternatively, the Mesh node 114 (a long power supply node) is used as a configuration client to assume the configuration function of the Netkey of the entire network, and the Mesh node 117 (another long power supply node) can be used as a network access manager to assume the network access management function of the entire network.

[0061] Bluetooth Mesh Relay nodes are usually long-powered nodes that are responsible for forwarding network messages. Figure 1 In the Bluetooth Mesh network 100 shown, the Mesh node 114 can be used as a Bluetooth relay node, which can be used to forward network messages between the Mesh gateway 110 and the Mesh node 112, and can also be used to forward network messages between the Mesh gateway 110 and the Mesh node 112.

[0062] The proxy node is generally a long-powered node, which is responsible for acting as a proxy for non-Bluetooth Mesh network BLE devices to access the Bluetooth Mesh network. Figure 1 In the Bluetooth Mesh network 100 shown, Mesh nodes 114 and Mesh nodes 117 can act as proxy nodes to perform proxy processing for BLE devices that are not in the current Bluetooth Mesh network system to access the network. The proxy process will not be elaborated in detail here.

[0063] A friend node is a long-powered node that can be used to temporarily store messages for a dormant node (i.e., a dormant LPN node) with which a friend relationship has been established. In this way, when the dormant LPN node wakes up, it can obtain messages during its dormancy by interacting with the friend node. Figure 1 In the Bluetooth Mesh network 100 shown, Mesh node 117 can serve as a friend node of Mesh node 115 and Mesh node 116, and Mesh node 117 can temporarily store messages for Mesh node 115 or Mesh node 116 during the period when Mesh node 115 or Mesh node 116 is in sleep mode; Mesh node 114 can serve as a friend node of Mesh node 112 and Mesh node 113, and Mesh node 114 can temporarily store messages for Mesh node 112 or Mesh node 113 during the period when Mesh node 112 or Mesh node 113 is in sleep mode.

[0064] In an exemplary embodiment, when the Mesh node 112 wakes up after sleeping, it can send a friend poll message to its friend node, that is, the Mesh node 114. The friend poll message is used to request the friend node for network messages during its own sleep period. Therefore, when the Mesh node 114 receives the friend poll message and stores the temporary messages of the Mesh node 112 during its sleep period, the Mesh node 114 can feed back a response message of the friend poll message to the Mesh node 112. The response message carries the messages temporarily stored by the Mesh node 114 for the Mesh node 112 during its sleep period.

[0065] In a possible embodiment, in order to maximize the coverage area of ​​the Mesh network, the long power supply node is used as a relay node, a proxy node, and a friend node at the same time. In this case, the long power supply node can be called a Mesh Relay, Proxy & Friend node. For example, Figure 1 In the system shown, the Mesh node 114 can be a Mesh Relay, Proxy & Friend node.

[0066] As mentioned above, the embodiments of the present application can be applied to any Bluetooth Mesh network, and the Bluetooth Mesh network can also communicate with other networks.

[0067] For example, the Bluetooth Mesh network can be further applied to smart home scenarios. Figure 2 , Figure 2 FIG. 1 is a schematic diagram showing a Bluetooth Mesh network provided by an embodiment of the present application and applied to a smart home application scenario. Figure 2 As shown, the communication system includes a Bluetooth Mesh network 100, which is exemplary. Figure 2 The Bluetooth Mesh network shown includes a Mesh gateway 110 and a Mesh node 111. It is understood that the Bluetooth Mesh network 100 may also include more Mesh nodes, such as Figure 1 As shown, the description is not expanded here.

[0068] like Figure 2 As shown, the Mesh gateway 110 can be connected to the WiFi router 310 and communicate with the WiFi network (or device) and other networks (or network devices) through the WiFi router 310.

[0069] In an exemplary embodiment, Figure 2 A ZigBee (ZigBee protocol) network 200 is shown, and the ZigBee network 200 includes: a ZigBee gateway 210 and a ZigBee device 220. In this scenario, the Mesh node 111 is connected to the WiFi router 310 through the Mesh gateway 110, and the ZigBee device 220 is connected to the WiFi router 310 through the ZigBee gateway 210, so that the Mesh node 111 and the ZigBee device 220 can communicate through the WiFi router 310.

[0070] In another exemplary embodiment, Figure 2 The WiFi device 320 is further shown. In this scenario, the Mesh node 111 is connected to the WiFi router 310 via the Mesh gateway 110, and the WiFi device 320 is also connected to the WiFi router 310, so that the Mesh node 111 and the WiFi device 320 can communicate through the WiFi router 310.

[0071] In another exemplary embodiment, Figure 2 A terminal is further shown. Figure 14 shows two forms of terminals: tablet computer 410 and mobile phone 420. In the embodiment of the present application, the terminal may also have other forms, for example, the terminal may also include: laptop computer, PDA, mobile internet device (mobile internet device, MID), smart speaker, smart TV and other terminals with WiFi access function. In this scenario, the terminal can communicate with WiFi router 310, so that Mesh node 111 can communicate with mobile phone 420 and tablet computer 410 through Mesh gateway 110 and WiFi router 310.

[0072] In another exemplary embodiment, Figure 2 A smart home cloud 500 is further shown. Figure 2 As shown, the smart home cloud 500 can communicate with the terminal and the WiFi router 310. Therefore, the Mesh node 111 can communicate with the smart home cloud 500 through the Mesh gateway 110 and the WiFi router 310.

[0073] In a possible smart home cloud scenario, the Mesh network 100, the ZigBee network 200, the terminals (410, 420, etc.), the smart home cloud 500, and the WiFi device 320 can achieve global communication through the WiFi router 310. Figure 2 In the smart home scenario shown, in the embodiment of the present application, the terminal can communicate with the smart home cloud 500 through a WiFi router 310 or mobile data.

[0074] It should be understood that Figure 2 The number and type of electronic devices included in the communication system shown are only examples, and the embodiments of the present application are not limited thereto. For example, more Mesh nodes 110 for communicating with the terminal may be included, which are not described one by one in the accompanying drawings for the sake of simplicity; for another example, core network nodes or devices for carrying virtualized network functions may also be included, which are obvious to those skilled in the art and are not described one by one here.

[0075] In the aforementioned Bluetooth Mesh network 100, each Mesh node encrypts information through a network key (Netkey) before communicating. Specifically, each Mesh node can store a Netkey separately. As mentioned above, the configuration client is responsible for the configuration of the entire network, which may include but is not limited to the configuration of the Netkey, and the Netkey is generally configured by the configuration client (or configuration node) and synchronized throughout the network. For each Mesh node (including the Mesh gateway), the Netkey of the Mesh node needs to be consistent with the global Netkey in order to communicate normally with other Mesh nodes.

[0076] According to the Bluetooth Mesh 1.0 specification, when the NetKey and / or the application key (AppKey) are at risk of leakage, for example, when a Mesh node is deleted from the Bluetooth Mesh network, the NetKey and AppKey of the entire network can be updated through the Key Refresh procedure. Before the key update process, the Configuration Client can add the Mesh node with leakage risk to the blacklist (or called: update key blacklist), where the Mesh nodes in the blacklist cannot learn the new key (including: Netkey, in addition, it may also include other keys, such as APPkey).

[0077] For reference, please refer to Figure 3 The message interaction diagram of the key update process in the prior art shown in the figure mainly involves the message interaction between the configuration client and each Mesh node outside the blacklist. Figure 3 In the configuration, the client is specifically configured as a Mesh gateway. Figure 3 The schematic diagram shows the message interaction process when the Netkey is updated between the Mesh gateway and a Mesh node.

[0078] like Figure 3 As shown in the figure, when updating the Netkey of the entire network, the key update process includes the following steps:

[0079] S302, the Mesh gateway sends a key update message to the Mesh node, wherein the key update message carries the encrypted new network key.

[0080] The key update message carries the second ciphertext, which is obtained by using a double encryption mechanism, using the original network key (original Netkey, which can also be recorded as the second network key) and the device key (Devkey) of the Mesh node to double encrypt the first network key (i.e., the new network key). Specifically, in the key update message, the original Netkey is used for encryption at the network layer, and the Devkey of the Mesh node is used for encryption at the Model layer.

[0081] exist Figure 3 In the key update process shown, the Mesh gateway can send a key update message encrypted with the Devkey of the Mesh node and the original Netkey to each Mesh node not in the blacklist.

[0082] In a Bluetooth Mesh network, a key update message can reach a Mesh node in one or more hops. Figure 1 In the Bluetooth Mesh network shown, the Mesh gateway 110 can send the new Netkey directly to the Mesh node 114 (one-hop arrival); and when the Mesh gateway 110 sends the new Netkey to the Mesh node 112, it can be forwarded by the Mesh node 114 (two-hop arrival).

[0083] Specifically, the key update message can be sent through a configuration model (Config Model). It can be understood that the key update message is used to update the Netkey of the Bluetooth Mesh network, and the embodiment of the present application has no special limitation on its naming method. Exemplarily, the key update message can be a Config Network Key Update message.

[0084] In addition, the Mesh gateway also sends the Mesh node a Config Key Refresh Phase Set message of the Config Model with a Transaction value of 2. When the Transaction value of the Config Key Refresh Phase Set message is 2, the message is used to indicate that the Mesh node can use the new Netkey to encrypt and send messages, and the Mesh node can use the new Netkey or the original Netkey to decrypt messages.

[0085] It should be noted that the meaning of the Config Key Refresh Phase Set message is different depending on the Transaction value carried in the message. The Config Key Refresh Phase Set message with a Transaction value of 3 will be discussed in detail later.

[0086] S304, the Mesh node decrypts the key update message.

[0087] As mentioned above, the key update message is sent after the new Netkey is double encrypted using the original Netkey and the Devkey of the Mesh node. Therefore, after receiving the key update message, the Mesh node can use the original Netkey and its own Devkey to decrypt the second ciphertext carried in the key update message. That is, when the Mesh node receives the key update message, it uses the original Netkey to decrypt the key update message at the network layer and uses its own Devkey to decrypt it at the Model layer. It can be understood that if both decryptions are successful, the Mesh node can obtain the new Netkey.

[0088] S306, when the decryption is successful, the Mesh node sends a first notification to the Mesh gateway, where the first notification is used to notify the Mesh gateway that it has successfully received the new network key.

[0089] At this point, the Mesh node has learned the new Netkey, and the original Netkey has not been abolished. At this stage, in the Bluetooth Mesh network, the sending Mesh node can use the new Netkey to encrypt data and send it, while the receiving Mesh node can use the new Netkey or the original Netkey for decryption.

[0090] Specific implementation Figure 3 In the key update process shown, the first notification is sent through the Config Model. Specifically, the first notification is a Config NetKey States message.

[0091] S308, when receiving the first notification from all non-blacklisted Mesh nodes, the Mesh gateway sends a second notification to the entire network, where the second notification is used to notify the entire network to abolish the original network key.

[0092] Specifically, before each Mesh node receives the second notification, each Mesh node can use the original Netkey or the new Netkey to communicate with other Mesh nodes; after each Mesh node receives the second notification, each Mesh node can delete the original Netkey and only use the new Netkey to communicate with other Mesh nodes.

[0093] The second notification is also sent through the Config Model. Specifically, the second notification is a Config Key Refresh Phase Set message with a Transaction value of 3. When the Transaction value of the Config Key Refresh Phase Set message is 3, the message (i.e., the second notification) is used to indicate that the Mesh node can only use the new Netkey for communication. In other words, the original Netkey is abolished.

[0094] Furthermore, after receiving the Config Key Refresh Phase Set message with a Transaction value of 3, each Mesh node can also feedback a Config Key Refresh Phase States message to the Mesh gateway. The ConfigKey Refresh Phase States message is used to indicate that the Mesh node has completed the key update setting.

[0095] by Figure 1 Taking the Bluetooth Mesh network 100 shown in FIG. 1 as an example, the key update process is described. Figure 1 In the illustrated embodiment, the Mesh gateway 110 acts as a configuration client and distributes key update messages to the Mesh nodes 111 to 117. Therefore, for any one of the Mesh nodes 111 to 117, taking the Mesh node 111 as an example, the Mesh node 111 receives the key update message, decrypts the key update message using the original Netkey stored in itself, and obtains the new Netkey after the decryption is successful. After that, the Mesh node 111 sends the Config NeKey States message (i.e., the first notification) to the Mesh gateway 110.

[0096] In addition, the Mesh gateway 110 can also send a Config Key Refresh Phase Set message with a Transaction value of 2 to each Mesh node. Taking Mesh node 111 as an example, after receiving the Config Key Refresh Phase Set message with a Transaction value of 2, Mesh node 111 sends a Config Key Refresh Phase States message to the Mesh gateway. In this stage, when Mesh node 111 sends a message to other Mesh nodes, it uses the new Netkey to encrypt the message before sending it; when receiving a message from other Mesh nodes, Mesh node 111 uses the new Netkey or the original Netkey to decrypt it.

[0097] Until the Mesh gateway 110 receives the Config Key Refresh Phase States messages from all Mesh nodes, that is, when the Mesh gateway 110 receives the Config Key Refresh Phase States messages from the Mesh nodes 111 to 117, the Mesh gateway 110 sends the Config Key Refresh Phase Set message (second notification) with the Transaction value of 3 to the Mesh nodes 111 to 117 to cancel the original Netkey. In this way, the whole network update of Netkey is realized.

[0098] It should be noted that in Figure 3 In the key update process shown, before executing step S308, the Mesh gateway needs to determine that all Mesh nodes not in the blacklist have successfully received the new Netkey, that is, after receiving the first notification from all Mesh nodes not in the blacklist, it will send the second notification to the entire network.

[0099] Based on this, when a Mesh node that is not in the blacklist fails to successfully send the first notification to the Mesh gateway for some reason, this causes the Mesh gateway to be unable to receive the first notification from the Mesh node.

[0100] For ease of explanation, in the subsequent description, this Mesh node (or Mesh node) that is not in the key update blacklist and fails to successfully send the first notification during the key update process is referred to as the first network node (or first network node). Among them, the first network node may fail to successfully send the first notification to the Mesh gateway due to one or more reasons such as being in a dormant state, battery problems, self-failure, communication interference, or being moved out of the coverage area of ​​the Bluetooth Mesh network. The situation where the first network node fails to successfully send the first notification may include: the first network node fails to successfully receive the key update message, and / or the first network node is unable to send the first notification to the outside.

[0101] In this case, the Mesh gateway may continue to wait until receiving the first notification from all non-blacklisted Mesh nodes, and then the Mesh gateway executes S308 to complete the key update process.

[0102] by Figure 1 Taking the Bluetooth Mesh network 100 shown as an example, if the Mesh node 113 is unable to send the first notification (Config NeKey States) after receiving the key update message due to communication interference, the Mesh gateway 110 will not be able to receive the first notification from the Mesh node 113, and the Mesh gateway 110 will continue to wait until the communication of the Mesh node 113 is restored, and the Mesh node 113 sends the first notification to the Mesh gateway 110. In this way, the Mesh gateway 110 can receive the first notifications from the Mesh nodes 111 to 117 respectively, and the Mesh gateway 110 will issue the second notification to the entire network to realize the key update.

[0103] However, in a Bluetooth Mesh network, the key update process is generally initiated based on the risk of key leakage. For example, the key update process is initiated when a Mesh node moves out of the network. For another example, the key update process can also be initiated when a new Mesh node joins the network. Figure 3 The key update process shown in the figure. Therefore, the longer the Mesh gateway waits during the key update process, the greater the chance that the Bluetooth Mesh network will be attacked by Trash-can, and the higher the security risk.

[0104] Even in some possible cases, the first network node may not be able to solve the fault problem. In this way, the first network node cannot successfully send the first notification to the Mesh gateway. Then, if the Mesh gateway keeps waiting, the key update process may not be completed, which greatly affects the security of the Bluetooth Mesh network.

[0105] In addition to the aforementioned key update method, currently, the first network node can also be configured (provisioning) by maintenance personnel so that the first network node can re-enter the network, so that the latest network key can be obtained after it re-enters the network. However, this key update method requires manual participation of maintenance personnel, and the process of re-configuring the network is cumbersome and complicated, and there is a problem of poor timeliness, which also poses certain security risks.

[0106] The technical solutions of the embodiments of the present application are described in detail below with specific embodiments. Through these technical solutions, the updated network key can be obtained for the Mesh nodes that missed the key update, which is beneficial to improve the security of the Bluetooth Mesh network. The following specific embodiments can be combined with each other, and the same or similar concepts or processes may not be repeated in some embodiments. The embodiments of the present application will be described below in conjunction with the accompanying drawings.

[0107] An embodiment of the present application provides a key update method, which can be applied to a Bluetooth Mesh network to implement a key update for the Bluetooth Mesh network.

[0108] In the embodiment of the present application, the configuration client can be undertaken by a long power supply node in the Bluetooth Mesh network. For the sake of convenience, the Mesh node that undertakes the whole network configuration function is referred to as a configuration node. As mentioned above, the configuration node can be specifically a Mesh gateway in the Bluetooth Mesh network, or the configuration node can be specifically other long power supply nodes other than the Mesh gateway. For example, Figure 1 In the illustrated scenario, the configuration node may be the Mesh gateway 110 , or the configuration node may be the Mesh node 117 or the Mesh node 114 .

[0109] For ease of explanation, this solution is described below using a configuration node and a Mesh node other than the configuration node as an example.

[0110] In the embodiment of the present invention, the key update process of the Bluetooth Mesh network can refer to Figure 4 , which may specifically include the following steps:

[0111] S402, the configuration node sends a key update message to the Mesh node, wherein the key update message carries the encrypted new network key.

[0112] Specifically, the key update message is obtained by encrypting the new Netkey using the original Netkey and the Devkey of the Mesh node. The network layer of the key update message is encrypted using the original Netkey, while the model layer is encrypted using the Devkey of the Mesh node.

[0113] It can be understood that in actual scenarios, the configuration node can send a key update message to each Mesh node except the configuration node.

[0114] S404, after receiving the key update message, the Mesh node decrypts the key update message.

[0115] That is, the Mesh node uses the original Netkey and the Mesh node's own Devkey to decrypt the key update message.

[0116] S406, when the decryption is successful, the Mesh node sends a first notification to the configuration node, where the first notification is used to notify the configuration node that it has successfully received the new network key.

[0117] Figure 4 For the implementation of S402~S406, please refer to Figure 3 The relevant descriptions of S302 to S306 in the above will not be repeated here.

[0118] S408, when the timing duration reaches a preset duration, or the current time reaches a preset time, the configuration node sends a second notification to the entire network, and the second notification is used to notify the entire network to abolish the original network key.

[0119] The starting point of the timing duration is the moment when the configuration node sends the key update message in S402.

[0120] In other words, Figure 4 In the embodiment shown, after the configuration node sends the key update message, the timing can be started. When the timing duration reaches the preset duration (or called: waiting duration, timeout duration), or the current time reaches the preset time, the configuration node sends a second notification to the outside to notify the entire network to abolish the original network key. In this way, through the timing processing on the configuration node side, regardless of whether all Mesh nodes have received the new Netkey, the key update process can be completed within the preset duration (or preset time), reducing the security risk caused by the configuration node continuously waiting for the feedback of the Mesh node.

[0121] However, in Figure 4 In the key update process shown in FIG. 1 , there may be a Mesh node, that is, a first network node, that fails to successfully send the first notification to the configuration node for some reason. Figure 4 On the basis of the key update process shown, a key recovery process for the first network node is further provided.

[0122] Among them, the first network node involved in the embodiment of the present application refers to some Mesh nodes in the Bluetooth Mesh network, whose locally maintained network keys are inconsistent with the first network key of the current Bluetooth Mesh network after the key update process.

[0123] It should be understood that the "key recovery process" is actually the key update process for the first network node. This name is only used to distinguish the key update process for all mesh nodes in the Bluetooth Mesh network. In actual implementation scenarios, the key recovery process for the first network node can be regarded as part of the key update process. Figure 4 The key update process for all Mesh nodes (not in the blacklist and all Mesh nodes except the configuration node) shown is referred to as the key update process; the key update process for the first network node is referred to as the key recovery process.

[0124] Specifically, when the key recovery is performed for the first network node, the first network node may acquire a new network key through message interaction between the first network node and the configuration node.

[0125] Among them, when the first network node and the configuration node exchange messages, the device key (Devkey) of the first network node can be used to encrypt the Config Model message. Among them, each Mesh node has a unique Devkey, and the Devkey of the Mesh node can only be obtained by the Mesh node itself and the configuration node. Therefore, the Config Model message is encrypted using the Devkey of the first network node, and only the first network node itself and the configuration node can successfully decrypt the message, which is conducive to improving the security of message interaction during the key recovery process.

[0126] Specifically, the key recovery process may be triggered by the configuration node based on the update failure list; or, the first network node may send a key recovery request to the configuration node, so that the configuration node responds to the received key recovery request.

[0127] The following describes how to implement these two key recovery processes.

[0128] In the first key recovery method, the configuration node actively triggers the aforementioned key recovery process based on the update failure list.

[0129] The update failure list is used to record the Mesh nodes that failed to update during the key update process. Specifically, the update failure list can record the node identification of the Mesh node that failed to update. The node identification can include but is not limited to: MAC address, Mesh address, custom number, etc., wherein the custom number can be a combination of one or more ways of text, characters, and numbers, which will not be repeated here.

[0130] Therefore, this key update method can be used Figure 4 The key update process shown is then implemented.

[0131] The update failure list can be recorded and maintained by the configuration node. In the Bluetooth Mesh network, the configuration node is responsible for the configuration of the entire network. Therefore, the configuration node can know which Mesh nodes are included in the current Bluetooth Mesh network. On this basis, the configuration node can determine which Mesh nodes have not responded to the first notification in time based on the first notification received during the key update process.

[0132] Based on this, in a possible embodiment, the configuration node executes Figure 4 In addition to the key update process shown, the identifiers of the Mesh nodes that did not promptly feedback the first notification can also be obtained, and the identifiers of these Mesh nodes are recorded in the update failure list. In this embodiment, the update failure list records all Mesh nodes (including long power supply nodes and LPN nodes) that failed to update in the entire Bluetooth Mesh network.

[0133] Since the update failure list is for all Mesh nodes (including long power supply nodes and LPN nodes), the configuration node obtains all long power supply nodes in the update failure list and uses all long power supply nodes in the update failure list as the first network nodes. Thus, the key recovery is performed for each first network node.

[0134] In the embodiment of the present application, for the long power supply node, the configuration node actively recovers the key for it, and for the LPN node that missed the key update, the configuration node can be implemented in a way that responds to the key recovery request from the LPN node, which will be described in detail later. In this way, the long power supply node and the LPN node that missed the key update process are distinguished and processed, avoiding the possibility that the LPN node is in a dormant state and misses the key recovery process initiated by the configuration node, which is conducive to shortening the duration of the key recovery process, improving the key recovery efficiency, and saving system resources.

[0135] In this scenario, the configuration node can determine the first network node (or target node, target Mesh node) based on the update failure list, so that the first network key can be encrypted using the Devkey of the first network node to obtain the first ciphertext, where the first network key is the current network key of the Bluetooth Mesh network. Then, the configuration node sends message 1 to the first network node so that the first network node can decrypt the first ciphertext carried in message 1, so that the first network node can obtain the first network key. In the Bluetooth Mesh network, message 1 can reach the first network node in one hop or through multi-hop relay forwarding by other Mesh nodes, and message 1 can be carried in the Beacon frame.

[0136] For example, please refer to Figure 5 The key recovery process may include but is not limited to the following steps:

[0137] S502: The configuration node encrypts the current network key using the device key of the first network node to obtain a key recovery message.

[0138] like Figure 5 The key recovery process shown in Figure 4 The key update process shown in the figure is executed after that to recover the key of some Mesh nodes that failed to update Netkey during the key update process. At this time, all the long power supply nodes in the Mesh nodes that failed to update Netkey are used as the first network nodes to execute Figure 5 The key recovery process shown in Figure 1. At this point, the current network key mentioned in this step can be specifically Figure 4 The new network key in .

[0139] At this time, the current network key of the Bluetooth Mesh network is the first network key, and the key recovery message carries the first ciphertext, which is obtained by encrypting the first network key using the Devkey of the first network node.

[0140] S504: The configuration node sends a key recovery message to the first network node.

[0141] In specific implementation, the key recovery message is the message 1 mentioned above. In the embodiment of the present application, the configuration node can send the key recovery message to the outside in the form of broadcast. At this time, the key recovery message (that is, message 1) carries the first network node identifier, so that in the Bluetooth Mesh network, the key recovery message can reach the first network node within one hop, or it can also reach the first network node through multi-hop relay forwarding through other Mesh nodes.

[0142] S506: The first network node receives a key recovery message (ie, message 1).

[0143] S508: The first network node decrypts the key recovery message using the device key of the first network node to obtain the current network key.

[0144] The current network key is also the first network key. When this step is implemented specifically, the first network node uses its own Devkey to decrypt the first ciphertext carried in the message 1 to obtain the first network key of the current Bluetooth Mesh network.

[0145] S510: The first network node updates a locally maintained network key based on the current network key.

[0146] Since the first network node missed the key update process, the network key locally maintained by the first network node is inconsistent with the current network key of the Bluetooth Mesh network. Thus, when executing this step, the first network node updates the locally maintained network key to the current network key of the Bluetooth Mesh network.

[0147] For example, the network key maintained locally by the first network node is key 1, and the first network node runs out of power and cannot communicate with the Bluetooth Mesh network, thus missing the Bluetooth Mesh network key update process. During this period, the Bluetooth Mesh network network key has undergone three updates, in the following order: key 1 → key 2 → key 3 → key 4. When the first network node replaces the battery, the current network key of the Bluetooth Mesh network in the Bluetooth Mesh network is key 4. Figure 5 When the above process is implemented, the first network node can decrypt the key recovery message based on its own Devkey to obtain key 4, and replace the locally maintained key 1 with key 4 to implement key update.

[0148] Figure 5 The schematic diagram of the interaction process between a first network node and a configuration node is only schematically shown. In actual scenarios, there may be multiple first network nodes in the Bluetooth Mesh network. In this case, the following operations may be performed for each first network node. Figure 5 The key recovery process shown in FIG. 1 realizes the key recovery of each first network node. In other words, Figure 5 The key recovery process shown is implemented for a single first network node. When there are multiple first network nodes, it is only necessary to execute the key recovery process multiple times.

[0149] It can be understood that when there are multiple first network nodes, the Devkey of each first network node is different, and the first ciphertext obtained in this step is different, that is, the information (first ciphertext) carried by the key recovery message is different.

[0150] It should be noted that Figure 5The interaction diagram shown is for illustration only. When the key recovery method is actually applied to a Bluetooth Mesh network, multi-hop forwarding may be required to achieve interaction between the two.

[0151] For example, Figure 6 A key recovery method for a long power supply node is shown. Specifically, Figure 6 for Figure 5 The key recovery method shown is applied to Figure 1 A schematic diagram of an implementation of a Bluetooth Mesh network is shown. Figure 6 The Mesh node 112 (first network node), the Mesh node 114 and the Mesh gateway 110 (configuration node) are schematically shown. At this time, the key recovery message sent by the Mesh gateway 110 to the Mesh node 112 needs to be forwarded by the Mesh node 114 before it can reach the Mesh node 112.

[0152] In another exemplary embodiment, Figure 1 In the Bluetooth Mesh network shown, the configuration node may be Mesh node 117, that is, Mesh node 117 is responsible for the configuration function of the entire network.

[0153] Then, if the first network node is the Mesh gateway 110, the Mesh node 117 may send a message 1 (key recovery message) externally, and the key recovery message carries the identifier of the Mesh gateway 110. At this time, the key recovery message reaches the first network node in one hop.

[0154] Alternatively, if the first network node is Mesh node 114, Mesh node 117 sends message 1 (key recovery message) externally, which carries the identifier of Mesh node 114. Then the key recovery message can be relayed by Mesh gateway 110 to reach Mesh node 114. This is not exhaustive.

[0155] In the aforementioned key recovery method, each broadcast message, such as the key recovery message (i.e., message 1) and message 2 mentioned later, also carries a receiver identifier. The receiver identifier is used to uniquely indicate the receiver of the broadcast message. Specifically, the receiver identifier may include, but is not limited to, the physical (Media Access Control, MAC) address of the receiver.

[0156] Thus, in a Bluetooth Mesh network, for any Mesh node, after receiving a key recovery message, the Mesh node can determine whether it is the receiver of the key recovery message based on the receiver identifier (MAC address) carried in the message. If the MAC address carried in the key recovery message is consistent with its own MAC address, it is the receiver of the key recovery message; otherwise, if the two are inconsistent, it is not the receiver of the key recovery message.

[0157] Therefore, when the Mesh node itself is not the receiver of the key recovery message, if the Mesh node is a relay node, it forwards the key recovery message; if the Mesh node is not a relay node, it discards the key recovery message; when it is the receiver of the key recovery message, it uses its own Devkey to decrypt the key recovery message. For example, Figure 6 In the key recovery process shown, after the Mesh node 114 receives the key recovery message, it determines that it is not the receiver of the key recovery message, and forwards the key recovery message to the Mesh node 112 when it is a relay node; and after the Mesh node 112 receives the key recovery message, it determines that it is the receiver of the key recovery message, then decrypts the key recovery message to obtain the current Bluetooth Mesh network key, and then updates the locally maintained network key to complete the key recovery.

[0158] In the embodiment of the present application, the key recovery message (message 1) may be specifically a configuration broadcast frame (Beacon). At this time, the configuration broadcast frame carries a first ciphertext encrypted by using the Devkey of the first network node to encrypt the current Netkey.

[0159] In addition, it should be noted that, in a scenario where the configuration node actively recovers the key for the first network node, the configuration node may send the key recovery message to the first network node multiple times.

[0160] In an exemplary embodiment, the configuration node may intermittently, such as periodically, send a key recovery message to the first network node until a heartbeat from the first network node is received. The "heartbeat" of the first network node refers to a message sent by the first network node to notify other nodes that it is active. The message type of the "heartbeat" may be a broadcast message, or it may be a unicast message; the "heartbeat" may not carry data, for example, the content carried in the message is empty, or other existing messages may be used as "heartbeats", such as the first notification or other information request message sent by the first network node to the configuration node.

[0161] In another exemplary embodiment, the configuration node may also periodically send a key recovery message to the first network node until the number of transmissions reaches a preset number threshold or a heartbeat is received. The number threshold may be preset as needed and there is no particular restriction on this.

[0162] The second key recovery method is implemented by the first network node sending a key recovery request to the configuration node, and accordingly, the configuration node responds to the received key recovery request.

[0163] In this implementation, the configuration node does not need to actively perform key recovery for the first network node, but the first network node actively requests it. This implementation is applicable to the key recovery process of the LPN node. That is, the first network node is the LPN node. This is in consideration of the fact that the LPN node may be in a dormant state, and the implementation method of the LPN node actively requesting key recovery is more conducive to saving system resources. The following is a detailed description.

[0164] Now combined Figure 7 The processing flow shown illustrates the process of recovering the secret key of the LPN node (ie, the first network node).

[0165] As mentioned above, LPN nodes switch between sleep state and wake state. LPN nodes can wake up (enter wake state) or fall asleep (enter sleep state) at regular intervals. For example, Figure 7 In the process, LPN nodes can enter the awakening state from the dormant state at regular intervals.

[0166] Each LPN node has a friend node, that is, a node with which the two have established a friend relationship. The friend node is a long-powered node in the Bluetooth Mesh network, which is used to temporarily store messages for the LPN node when the LPN node is in a dormant state. For ease of explanation, the node that has currently established a friend relationship with the LPN node (which can be recorded as the first network node) is recorded as a friend node.

[0167] So, if Figure 7 As shown, when the LPN node switches from the sleep state to the awake state, that is, after the LPN node wakes up, it can send a message acquisition request (that is, the fourth message) to the friend node, and the message acquisition request is used to request to obtain the message temporarily stored by the friend node for it during its own sleep period. Exemplarily, the message acquisition request can be specifically a Friend Poll message.

[0168] It should be noted that when an LPN node sends a message acquisition request, it needs to use the locally maintained network key to encrypt the message acquisition request. When a friend node receives the message acquisition request, it can decrypt it using the locally maintained network key.

[0169] If the decryption is successful, the friend node sends the message that it has temporarily stored for the LPN node. The LPN node can successfully receive the message from the friend node. At this time, the network key maintained locally by the LPN node is the same as the network key of the friend node, and there is no need to start the key recovery process. Then, after receiving the message temporarily stored by the friend node, the LPN node can process the message or perform other data processing processes. The embodiment of the present application has no special restrictions on this. Figure 7 Indicated as “working”. In addition, the LPN node can also switch from the awake state to the dormant state (timing sleep) at a predetermined time or according to a preset cycle.

[0170] However, if the network keys maintained by the LPN node and the friend node are inconsistent, decryption will fail, and the friend node will not respond to the message acquisition request, that is, the friend node will not feedback the message temporarily stored for it to the LPN node. At this time, the LPN node cannot receive feedback for the message acquisition request.

[0171] In this case, if the LPN node has not received any feedback message from the friend node within the preset first time period, the LPN node may try to send a message acquisition request to the friend node multiple times. For example, when no feedback message from the friend node has been received within a preset first time period after the fourth message is sent, the LPN node periodically sends a message acquisition request to the friend node until a feedback message from the friend node is received, or the number of transmissions reaches a preset first threshold.

[0172] If the LPN node has not received any message from the friend node after multiple attempts, there may be two situations: the network key maintained locally by the LPN node has expired; or the friend node has failed. For example, the friend node may be moved out of the coverage of the Bluetooth Mesh network, or the friend node missed the key update process, or the friend node communication failed, etc.

[0173] In this case, the LPN node can try to establish a friend relationship with other long power supply nodes. That is, the LPN node selects other long power supply nodes as its friend nodes.

[0174] Then, when the number of times the fourth message is sent reaches the preset first threshold and no feedback message is received from the friend node, the LPN node broadcasts a friend establishment request (fifth message). The friend establishment request is used to request to establish a friend relationship with the network node. Exemplarily, the friend establishment request can be specifically a Friend Request message. It should be noted that the Friend Request message cannot be forwarded by a relay node, and only a network node within the wireless coverage range of the LPN node can process the Friend Request message.

[0175] Similarly, when an LPN node sends a friendship request, it needs to use the locally maintained network key to encrypt the friendship request. When receiving the friendship request, the long power supply node around the LPN node can decrypt it using the locally maintained network key.

[0176] If the decryption is successful, the long power supply node can establish a friend relationship with the LPN node, wherein the establishment of the friend relationship is an existing technology and will not be repeated here. Then, after the friend relationship is established, the long power supply node becomes a friend node of the LPN node. After that, the LPN node can perform the work after awakening until the predetermined time is reached or according to the preset cycle, and switch from the awake state to the dormant state (timing to sleep).

[0177] If the network keys maintained by the LPN node and the long power supply node are inconsistent, decryption will fail, and the LPN node cannot establish a friendly relationship with the long power supply node.

[0178] In this case, if the LPN node has not received any feedback message from other network nodes within the preset second time period, the LPN node may try to establish a friendship relationship with other network nodes multiple times until the friendship relationship is successfully established, or the number of times the fifth message is sent reaches a preset second threshold.

[0179] If after multiple attempts, the LPN node has not received any message from other long power supply nodes, that is, when the number of times the fifth message is sent reaches the preset second threshold, and no feedback message is received from other network nodes, it means that the network key maintained locally by the LPN node may have expired. In this case, the LPN node can actively start the key recovery process. That is, the LPN node sends message 2 to the configuration node to request the recovery of the network key (or request to synchronize the current network key). Figure 8 Specific instructions.

[0180] After the LPN node recovers the network key from the configuration node, it can communicate normally with other Mesh nodes and work or wait. Figure 7The specific processing content of the LPN node in the awake state is not specifically shown. Afterwards, the LPN node can switch from the awake state to the dormant state (timing sleep) at a predetermined time or according to a preset cycle.

[0181] In this way, LPN nodes follow Figure 7 The method shown can realize active recovery of the network key when the network key itself is in the awake state.

[0182] Figure 8 The diagram shows the message interaction diagram of the key recovery process of the LPN node. Figure 8 In the embodiment shown, except for Figure 5 In addition to steps S502 to S510 in the illustrated embodiment, Figure 8 As shown, before S502, the method further includes the following steps:

[0183] S5012: When the number of failures in establishing the friendship relationship reaches a preset second threshold, the first network node sends a key recovery request to the configuration node.

[0184] During the key recovery process, the first network node may send a key recovery request by broadcasting, and at this time, the key recovery request may also be referred to as: message 2. Message 2 (i.e., key recovery request) is used to request the configuration node to recover the network key, or may be referred to as: message 2 is used to request synchronization of the current network key (i.e., the first network key) of the Bluetooth Mesh network.

[0185] In addition, as mentioned above, the situation where the number of failures to establish a friend relationship reaches the preset second threshold is that the number of times the fifth message is sent reaches the preset second threshold, and no feedback message from other network nodes has been received. At this time, the first network node sends message 2 to the configuration node, and message 2 carries the identifier of the configuration node. Exemplarily, message 2 carries the MAC address of the configuration node.

[0186] Considering the security of the communication process, the key recovery request is sent after being encrypted using the device key of the first network node. Exemplarily, the encryption algorithm may include but is not limited to: AES-CCM algorithm.

[0187] In an exemplary embodiment, both the key recovery request (message 2) and the key recovery message (message 1) can be Beacon messages. Furthermore, message 1 and message 2 can be specifically configuration broadcast frames (configuration Beacon).

[0188] S5014: The configuration node receives the key recovery request and obtains the device key of the first network node based on the identification information of the sender.

[0189] S5016: The configuration node decrypts the key recovery request using the device key of the first network node.

[0190] As mentioned above, the device key of the Mesh node is only known to the Mesh node itself and the configuration node. Therefore, if the decryption is successful, the configuration node can determine that the identity of the first network node is legitimate, and the configuration node can execute S502 to S510 to realize the key recovery of the first network node.

[0191] On the contrary, if the decryption fails, the configuration node cannot confirm the identity of the sender node of the key recovery request, and the configuration node may not feedback the current Bluetooth Mesh network key to the sender node.

[0192] In addition, Figure 5 Similar to the key recovery message mentioned in , the key recovery request can be a one-hop interaction, for example Figure 1 The message interaction between the Mesh node 111 and the Mesh gateway 110; or, the key recovery request can also reach the configuration node after being forwarded by multiple Mesh nodes in multiple hops.

[0193] For example, Fig. 9 Specifically shows Figure 8 Schematic diagram of the situation in which the message in S5012 and S504 reaches the receiving end through multi-hop forwarding, Fig. 9 Omitted Figure 8 The other steps in the process. Fig. 9 Specifically shown are a first network node (LPN node), n long power supply nodes, and a gateway node (configuration node), where n is 0 (one-hop direct interaction) or a positive integer (multi-hop forwarding). Fig. 9 In the illustrated embodiment, in step S5012, after the first network node sends a key recovery request to the outside, the key recovery request is forwarded to the gateway node via n hops through n forwardings by long power supply node 1 to long power supply node n. And, in step S504, when the gateway node sends a key recovery message to the first network node, the key recovery message is also forwarded to the gateway node via n hops through n forwardings by long power supply node n to long power supply node 1.

[0194] It should be noted that, in the process of the first network node actively requesting to recover the network key, the first network node may also repeatedly execute the following steps: Figure 8 or Fig. 9 The process shown in FIG. 1 is continued until the first network node can successfully communicate with other Mesh nodes.

[0195] In an exemplary embodiment, the first network node may periodically send a key recovery request to the configuration node until a feedback message from a friend node is successfully received after sending a message acquisition request. In other words, after the first network node executes S510 and successfully updates the locally maintained network key, it may send a FriendPoll to the friend node. If the first network node receives a feedback message from the friend node, it will no longer request the configuration node to update the network key.

[0196] In another exemplary embodiment, the first network node may periodically send a key recovery request to the configuration node until a new friendship relationship is established. In other words, after the first network node executes S510 and successfully updates the locally maintained network key, it may send a Friend Request message to other long power supply nodes. If friendship is successfully established, it will no longer request the configuration node to update the network key.

[0197] In any of the foregoing embodiments, for example, Figure 5 , Figure 8 , Fig. 9 In any of the embodiments shown, after the first network node implements update synchronization of the local network key based on the received message 1, it can also send a third message to the configuration node side, and the third message is used to indicate that the network device has successfully synchronized the first network key. The third message is, for example, a heartbeat message.

[0198] In addition, it should be noted that in the embodiments of the present application, Figure 8 The key recovery process shown in Figure 4 The key update process shown is executed afterwards, and the order of the two is limited.

[0199] Based on the above processing, the key update of any Mesh node in the Bluetooth Mesh network can be realized. On this basis, the Mesh node (exemplarily, such as the first network node) can also use the first network key to update the whole network encryption index, update the application key or reset the local serial number based on the successful update of the Netkey or the successful recovery of the Netkey.

[0200] Exemplarily, any Mesh node can update the network-wide encryption index (IV Index) through a secure broadcast frame (Secure Beacon).

[0201] Specifically, the Mesh node can update the IV Index through the IV Index Update process or the IV Index Recovery process. Both the IV Index Update process and the IV Index Recovery process can update the IVIndex, the difference is that the triggering conditions of the two are different. For example, when the IV Index in the SecureBeacon received by the Mesh node is 1 greater than the IV Index maintained by the Mesh node itself, and the IV Update Flag is 1, the IV Index Update process is started to update the IV Index. Except for this case and the case where the IV Index in the SecureBeacon received by the Mesh node is less than or equal to the IV Index maintained by the Mesh node itself, the IV Index is updated through the IVIndex Recovery process. No further explanation is given.

[0202] In the present application, when the IV Index is updated using Secure Beacon, the Netkey maintained by the current Mesh node (for example, the updated new Netkey, that is, the first network key) can be used to encrypt the Secure Beacon before message interaction.

[0203] The embodiments of the present application have no special restrictions on the triggering conditions and implementation methods of the process of updating the IV Index. Relevant standards or other public texts in the prior art can be adopted, which will not be discussed in detail here.

[0204] In addition to updating the IV Index, the Mesh node can also reset its own local sequence number (SeqNum) based on the updated Netkey. SeqNum is maintained locally by each Mesh node, and the SeqNum values ​​of each Mesh node may be the same or different.

[0205] The embodiments of the present application have no special restrictions on the triggering conditions and implementation methods of the process of resetting SeqNum. Relevant standards or other public texts in the prior art can be adopted, which will not be discussed in detail here.

[0206] In addition, in an embodiment of the present application, the Mesh node can also update the application key (APPkey) based on the updated first network key (Netkey).

[0207] Specifically, the APPkey can be updated through the configuration model (Config Model). In other words, each Mesh node can exchange information through the Config Model to update the APPkey. Among them, when using the Config Model for information exchange, the sender uses the updated Netkey and the receiver's Devkey to encrypt the information.

[0208] Similarly, the embodiments of the present application have no special restrictions on the triggering conditions and implementation methods of the process of updating APPkey. Relevant standards or other public texts in the prior art can be adopted, which will not be discussed in detail here.

[0209] It is to be understood that some or all of the steps or operations in the above embodiments are merely examples, and the present application embodiments may also perform other operations or variations of various operations. In addition, the various steps may be performed in different orders presented in the above embodiments, and it is possible that not all of the operations in the above embodiments need to be performed.

[0210] The embodiment of the present application also provides a network device.

[0211] Exemplarily, the present application provides a network device, which includes: a processing module and a transceiver module; wherein the processing module is used to: determine a first network node from the network nodes of the Bluetooth Mesh network, the network key locally maintained by the first network node is inconsistent with the first network key of the current Bluetooth Mesh network; and to encrypt the first network key using the device key of the first network node to obtain a first ciphertext; the transceiver module is used to send a first message so that the first network node obtains the first network key, and the first message carries the first ciphertext.

[0212] In a possible embodiment, the transceiver module is also used to: receive a second message, where the second message is used to request a synchronized network key; at this time, the processing module is specifically used to: when the network node indicated by the requester identifier carried by the second message is not a deleted node, determine the network node indicated by the requester identifier carried by the second message as the first network node.

[0213] In another possible embodiment, the processing module is specifically used to: determine each long power supply node in the update failure list as the first network node; wherein the update failure list is used to record all network nodes in the Bluetooth Mesh network that have failed to update the key and are not deleted nodes; the long power supply node is other network nodes in the Bluetooth Mesh network except the low power consumption node.

[0214] In another possible embodiment, the network device is a configuration node, and the configuration node is a Mesh gateway or other long power supply node.

[0215] In another possible embodiment, the first message is a broadcast frame, and the first message carries an identifier of the first network node.

[0216] The network device provided in this embodiment can be used to execute the technical solution for configuring the node side in any of the aforementioned embodiments. Its implementation principle and technical effects can be further referred to the relevant description in the method embodiment.

[0217] Exemplarily, an embodiment of the present application also provides another network device. The network device includes: a processing module and a transceiver module; wherein the transceiver module is used to send a second message to the configuration node, the second message is used to request synchronization of the network key; and, is used to receive a first message from the configuration node, the first message carries a first ciphertext, the first ciphertext is obtained by encrypting the first network key of the Bluetooth Mesh network using the device key of the network device, and the network key locally maintained by the network device is inconsistent with the first network key; the processing module is used to decrypt the first ciphertext using the device key of the network device to obtain the first network key; and, is used to update the locally maintained network key to the first network key.

[0218] In a possible embodiment, the transceiver module is further used to: send a third message to the configuration node, where the third message is used to indicate that the network device has successfully synchronized the first network key.

[0219] In a possible embodiment, the processing module is further used to: use the first network key to update one or more of the whole network encryption index, update the application key, or reset the local serial number.

[0220] In a possible embodiment, the transceiver module is specifically used to: when the network device switches from a sleep state to an awake state, send a fourth message to a second network node; wherein the second network node and the network device have established a friend relationship, and the second network node is used to temporarily store messages for the network device while the network device is in a sleep state; the fourth message is used to request to obtain the message temporarily stored by the second network node for the network device; and, when the number of times the fourth message is sent reaches a preset first threshold and no feedback message is received from the second network node, broadcast a fifth message, and the fifth message is used to request to establish a friend relationship; and, when the number of times the fifth message is sent reaches a preset second threshold and no feedback message is received from other network nodes, send the second message to the configuration node.

[0221] The network device provided in this embodiment can be used to execute the technical solution on the Mesh node (including but not limited to the first network node) side in any embodiment, and its implementation principle and technical effects can be further referred to the relevant description in the method embodiment.

[0222] It should be understood that the division of the modules of the above network devices is only a division of logical functions. In actual implementation, they can be fully or partially integrated into one physical entity, or they can be physically separated. And these modules can all be implemented in the form of software calling through processing elements; they can also be all implemented in the form of hardware; some modules can also be implemented in the form of software calling through processing elements, and some modules can be implemented in the form of hardware. For example, the processing module can be a separately established processing element, or it can be integrated in a communication device, such as a chip of a Mesh device. In addition, it can also be stored in the memory of the communication device in the form of a program, and called and executed by a processing element of the communication device. The implementation of other modules is similar. In addition, all or part of these modules can be integrated together, or they can be implemented independently. The processing element described here can be an integrated circuit with signal processing capabilities. In the implementation process, each step of the above method or each module above can be completed by an integrated logic circuit of hardware in a processor element or instructions in the form of software.

[0223] For example, the above modules may be one or more integrated circuits configured to implement the above methods, such as one or more application specific integrated circuits (ASIC), or one or more digital singnal processors (DSP), or one or more field programmable gate arrays (FPGA). For another example, when a certain module above is implemented in the form of a processing element scheduler, the processing element may be a general-purpose processor, such as a central processing unit (CPU) or other processor that can call a program. For another example, these modules may be integrated together and implemented in the form of a system-on-a-chip (SOC).

[0224] An embodiment of the present application also provides a network device, which includes: at least one processor and a memory; the memory stores computer-executable instructions; the at least one processor executes the computer-executable instructions, so that the network device executes the method executed by the configuration node side or the Mesh node (including but not limited to the first network node) side in any of the aforementioned embodiments.

[0225] The network device may include one or more processors, which may also be referred to as processing units, and may implement certain control functions. The processor may be a general-purpose processor or a dedicated processor.

[0226] In an optional design, the processor may also store instructions, which can be executed by the processor so that the network device executes the method described in the above method embodiment corresponding to the configuration node or Mesh node (including but not limited to the first network node).

[0227] In yet another possible design, the network device may include a circuit that can implement the functions of sending, receiving, or communicating in the aforementioned method embodiments.

[0228] Optionally, the network device may include one or more memories on which instructions or intermediate data are stored, and the instructions may be executed on the processor so that the network device executes the method described in the above method embodiment. Optionally, other relevant data may also be stored in the memory. Optionally, instructions and / or data may also be stored in the processor. The processor and memory may be provided separately or integrated together.

[0229] Optionally, the network device may further include a transceiver. The transceiver may be referred to as a transceiver unit, a transceiver, a transceiver circuit, or a transceiver, etc., and is used to implement the transceiver function of the communication device.

[0230] If the network device (as a configuration node) is used to implement the corresponding Figure 5 In the illustrated embodiment, when the configuration node sends a key recovery message to the first network node, for example, the transceiver may send the key recovery message to the first network node. The transceiver may further perform other corresponding communication functions. The processor is used to perform the corresponding determination or control operation, and optionally, the corresponding instructions may be stored in the memory. The specific processing methods of each component may refer to the relevant description of the aforementioned embodiment.

[0231] If the network device (as the first network node) is used to implement the corresponding Figure 8 When the first network node in the operation of sending a key recovery request to the configuration node, for example, the transceiver can send the key recovery request to the configuration node. The transceiver can also further perform other corresponding communication functions. The processor is used to complete the corresponding determination or control operation, and optionally, the corresponding instructions can also be stored in the memory. The specific processing method of each component can refer to the relevant description of the aforementioned embodiment.

[0232] The processor and transceiver described in the present application can be implemented in an integrated circuit (IC), an analog IC, a radio frequency integrated circuit RFIC, a mixed signal IC, an application specific integrated circuit (ASIC), a printed circuit board (PCB), an electronic device, etc. The processor and transceiver can also be manufactured using various IC process technologies, such as complementary metal oxide semiconductor (CMOS), N-type metal oxide semiconductor (NMOS), P-type metal oxide semiconductor (positive channel metal oxide semiconductor, PMOS), bipolar junction transistor (BJT), bipolar CMOS (BiCMOS), silicon germanium (SiGe), gallium arsenide (GaAs), etc.

[0233] Optionally, the communication device may be an independent device or may be a part of a larger device. For example, the device may be:

[0234] (1) Independent integrated circuit IC, or chip, or chip system or subsystem;

[0235] (2) having a set of one or more ICs, and optionally, the IC set may also include a storage component for storing data and / or instructions;

[0236] (3) ASIC, such as modem (MSM);

[0237] (4) Modules that can be embedded in other devices;

[0238] (5) Receivers, terminals, cellular phones, wireless devices, handsets, mobile units, network equipment, etc.;

[0239] (6)Others

[0240] An embodiment of the present application further provides a computer-readable storage medium, in which a computer program is stored. When the computer-readable storage medium is run on a computer, the computer executes the communication method described in the above embodiment.

[0241] In addition, an embodiment of the present application also provides a computer program product, which includes a computer program. When the computer program is run on a computer, the computer executes the communication method described in the above embodiment.

[0242] In the above embodiments, it can be implemented in whole or in part by software, hardware, firmware or any combination thereof. When implemented using software, it can be implemented in whole or in part in the form of a computer program product. The computer program product includes one or more computer instructions. When the computer program instructions are loaded and executed on a computer, the process or function described in this application is generated in whole or in part. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions can be stored in a computer-readable storage medium, or transmitted from one computer-readable storage medium to another computer-readable storage medium. For example, the computer instructions can be transmitted from a website site, computer, server or data center to another website site, computer, server or data center by wired (e.g., coaxial cable, optical fiber, digital subscriber line) or wireless (e.g., infrared, wireless, microwave, etc.) mode. The computer-readable storage medium can be any available medium that a computer can access or a data storage device such as a server or data center that includes one or more available media integration. The available medium can be a magnetic medium (e.g., a floppy disk, a hard disk, a tape), an optical medium (e.g., a DVD), or a semiconductor medium (e.g., a solid-state hard disk Solid State Disk), etc.

Claims

1. A key updating method, characterized in that: Applied to a Bluetooth Mesh network, the Bluetooth Mesh network includes at least two network nodes, the configuration node is a network node in the Bluetooth Mesh network, the configuration node is used to configure a network key of the Bluetooth Mesh network, and the method includes: The configuration node determines the first network node from the network nodes of the Bluetooth Mesh network in response to the second message sent by the first network node, the network key locally maintained by the first network node is inconsistent with the first network key of the current Bluetooth Mesh network, the second message is used to request synchronization of the network key, and the first network node is a low power node LPN; The configuration node encrypts the first network key using the device key of the first network node to obtain a first ciphertext; The configuration node sends a first message to enable the first network node to obtain the first network key, and the first message carries the first ciphertext.

2. The method according to claim 1, characterized in that The configuration node determines, in response to the second message from the first network node, the first network node from the network nodes of the Bluetooth Mesh network, including: The configuration node receives the second message sent by the first network node; When the network node indicated by the requester identifier carried in the second message is not a deleted node, the configuration node determines the network node indicated by the requester identifier carried in the second message as the first network node.

3. The method according to claim 1 or 2, characterized in that: The configuration node is a Mesh gateway or other long power supply node.

4. The method according to claim 1 or 2, characterized in that: The first message is a broadcast frame, and the first message carries an identifier of the first network node.

5. A key updating method, characterized in that: Applied to a Bluetooth Mesh network, the Bluetooth Mesh network includes at least two network nodes, the configuration node is a network node in the Bluetooth Mesh network, the configuration node is used to configure a network key of the Bluetooth Mesh network, the first network node is any network node except the configuration node, and the method includes: The first network node sends a second message to the configuration node, where the second message is used to request synchronization of a network key, and the first network node is a low power node LPN; The first network node receives a first message from the configuration node, where the first message carries a first ciphertext, where the first ciphertext is obtained by encrypting a first network key of the Bluetooth Mesh network using a device key of the first network node, and a network key locally maintained by the first network node is inconsistent with the first network key; The first network node decrypts the first ciphertext using a device key of the first network node to obtain the first network key; The first network node updates a locally maintained network key to the first network key.

6. The method according to claim 5, characterized in that The method further comprises: The first network node sends a third message to the configuration node, where the third message is used to indicate that the first network node has successfully synchronized the first network key.

7. The method according to claim 5 or 6, characterized in that: The first network node sending a second message to the configuration node includes: When the first network node switches from a dormant state to an awake state, the first network node sends a fourth message to a second network node; wherein the second network node has established a friend relationship with the first network node, and the second network node is used to temporarily store messages for the first network node while the first network node is in a dormant state; the fourth message is used to request to obtain the message temporarily stored by the second network node for the first network node; When the number of times the fourth message is sent reaches a preset first threshold and no feedback message has been received from the second network node, the first network node broadcasts a fifth message, where the fifth message is used to request to establish a friendship relationship; When the number of times the fifth message is sent reaches a preset second threshold and no feedback message is received from other network nodes, the first network node sends the second message to the configuration node.

8. A network device, characterized in that: include: at least one processor and memory; The memory stores computer-executable instructions; The at least one processor executes the computer-executable instructions so that the network device performs the method according to any one of claims 1 to 7.

9. A network system, characterized in that: include: At least two network nodes, The configuration node is a network node in a Bluetooth Mesh network, and the configuration node is used to configure a network key of the Bluetooth Mesh network, and is used to execute the method according to any one of claims 1 to 4; Any other network node except the configuration node is used to execute the method according to any one of claims 5 to 7.

10. A computer-readable storage medium, characterized in that: The computer-readable storage medium stores computer-executable instructions, and when the processor executes the computer-executable instructions, the method according to any one of claims 1 to 7 is implemented.

11. A computer program product, characterized in that The computer program product comprises a computer program, and when the computer program is run on a computer, the computer is caused to execute the method according to any one of claims 1 to 7.

Images