Secret key updating method, network equipment, system and storage medium

Abstract

The invention provides a secret key updating method, network equipment, a system and a storage medium, which are applied to a Bluetooth Mesh network, the Bluetooth Mesh network comprises at least two network nodes, a configuration node is a network node in the Bluetooth Mesh network, and the configuration node is used for configuring a network secret key of the Bluetooth Mesh network. The configuration node determines a first network node from network nodes of the Bluetooth Mesh network, and a network key locally maintained by the first network node is inconsistent with a first network key of the current Bluetooth Mesh network, so that the configuration node encrypts the first network key by using a device key of the first network node to obtain a first ciphertext, and transmits the first ciphertext to the Bluetooth Mesh network; and sending a first message carrying the first ciphertext, so that the first network node obtains the first network key. Thus, the latest secret key can be provided for the first network node missing the secret key updating process, a user does not need to manually recover the network secret key, and the network secret key recovery efficiency is improved.

Description

[0001] This application is a divisional application. The original application has the application number 202011435123.X and the original application date is December 10, 2020. The entire contents of the original application are incorporated herein by reference. Technical Field

[0002] This application relates to the field of communication technology, and in particular to a key update method, network device, system and storage medium. Background Technology

[0003] Bluetooth, as a wireless multi-hop interconnection technology for low-power, low-energy devices, along with Wi-Fi and ZigBee technologies, has entered the smart home application environment as a networking method for the Internet of Things (IoT). Bluetooth Mesh networking is also gradually being applied in the IoT field.

[0004] In a wireless network built using Bluetooth Mesh networking technology (hereinafter referred to as a Bluetooth Mesh network), each Mesh node stores a network key (Netkey). When Mesh nodes communicate with each other, the information is encrypted using the Netkey before being exchanged. To prevent trash-can attacks, whenever a Mesh node is deleted from the Bluetooth Mesh network, the Netkey needs to be updated across the entire network.

[0005] However, if a Mesh node misses the key update process for any reason, it will be unable to obtain the latest Netkey, thus preventing it from communicating with other Mesh nodes in the Bluetooth Mesh network. Summary of the Invention

[0006] This application provides a key update method, network device, system, and storage medium for providing the latest key to network nodes that have missed the key update process.

[0007] In a first aspect, this application provides a key update method applied to a Bluetooth Mesh network, wherein the Bluetooth Mesh network includes at least two network nodes, and a configuration node is one of the network nodes 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 determining a first network node from the network nodes of the Bluetooth Mesh network, wherein the network key maintained locally by the first network node is inconsistent with the first network key of the current Bluetooth Mesh network; thereby, the configuration node encrypts the first network key using the device key of the first network node to obtain a first ciphertext; and then, the configuration node sends a first message (i.e., message 1 in the following specific embodiments) to enable the first network node to obtain the first network key, wherein the first message carries the first ciphertext.

[0008] In other words, when the first network node misses the key update process, the network key maintained locally 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 can obtain the first network key. The first message carries a first ciphertext obtained by the configuration node encrypting the first network key using the device key of the first network node. This ensures that only the configuration node and the first network node in the entire Bluetooth Mesh network can decrypt the first message, thus guaranteeing communication security.

[0009] The solution provided in this embodiment offers a method to recover the network key for the first network node that missed the key update process, eliminating the need for the user to manually rejoin the first network node into the Mesh network and improving the efficiency of network key recovery.

[0010] In this embodiment, the Bluetooth Mesh network may include long-power nodes and low-power nodes (LPN) nodes. Long-power nodes generally do not have a sleep state; while LPN nodes have sleep and wake-up states to reduce power consumption. Alternatively, long-power nodes can also be understood as other network nodes in the Bluetooth Mesh network besides LPN nodes.

[0011] On the one hand, after switching from a dormant state to a wake-up state, the LPN node can send a second message to the configuration node based on its own situation (the method described in the second aspect later will be explained in detail, and will not be elaborated here). This is to actively request the update and synchronization of the network key.

[0012] In one possible embodiment, the configuration node determines the first network node from the network nodes of the Bluetooth Mesh network, including: the configuration node receiving a second message (i.e., message 2 in subsequent specific embodiments), the second message being used to request synchronization of the network key; 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. 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 designates it as the first network node and sends it a first message to enable it to obtain the first network key of the current Bluetooth Mesh network, thereby achieving network key synchronization.

[0013] On the other hand, since long-powered nodes do not have a sleep state, for long-powered nodes whose key updates recorded by the configuration node fail, the configuration node can actively restore the key after the key update process is completed.

[0014] In one 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-powered 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 key updates and are not deleted nodes; the long-powered nodes are other network nodes in the Bluetooth Mesh network besides low-power nodes. In other words, the configuration node can actively perform key recovery processing on all long-powered nodes in the update failure list, that is, the configuration node sends a first message to each of the long-powered nodes in the update failure list (which are then designated as the first network node).

[0015] Furthermore, the configuration node can send a first message to multiple first network nodes, and the first messages sent by the configuration node to different first network nodes are different. This is because each first network node has a unique device key, meaning that the device keys of multiple first network nodes are different. Therefore, the first ciphertext obtained by encrypting the first network key using different device keys is also different. In other words, the first ciphertext carried in the first messages of different first network nodes is different, and thus the first messages sent by the configuration node to different first network nodes are different.

[0016] In one possible design, the key update method provided in this application can be applied after the key update process and executed in conjunction with it. For example, when a new network node joins or a network node leaves the Bluetooth Mesh network, the key update process can be initiated; and for network nodes that miss the key update process, they can be designated as the first network node, and the configuration node can execute the aforementioned key update method to enable the first network node to obtain the first network key. In this way, a method for recovering the key can be provided for network nodes that miss the key update, eliminating the need for the user to manually rejoin the first network node into the Mesh network, thus improving the efficiency of network key recovery.

[0017] Furthermore, the configuration node can also maintain an update failure list after the key update process is completed. Specifically, the method also includes: determining the network node that did not receive the first notification as the update failure node, obtaining the 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.

[0018] In this embodiment of the application, the configuration node is a Mesh gateway in a Bluetooth Mesh network; or, the configuration node is another long-powered node.

[0019] In this embodiment, 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. For example, the identifier of the first network node can be the Media Access Control (MAC) address of the first network node.

[0020] In one embodiment of this application, the aforementioned second message, i.e., message 2 in the subsequent detailed embodiments, can also be a configuration broadcast frame (configuration beacon), which carries the identifier of the configuration node. For example, the identifier of the configuration node can be the MAC address of the configuration node.

[0021] Secondly, this application provides a key update method applied to a Bluetooth Mesh network, wherein the Bluetooth Mesh network includes at least two network nodes, a configuration node is one of the network nodes in the Bluetooth Mesh network, the configuration node is used to configure the network key of the Bluetooth Mesh network, and a first network node is any network node other than the configuration node. The method includes: the first network node sending a second message to the configuration node, the second message being used to request synchronization of the network key; after receiving the second message, the configuration node sending a first message to the first network node, the first network node receiving the first message from the configuration node, the first message carrying first ciphertext, the first ciphertext being 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 being inconsistent with the first network key; the first network node decrypting the first ciphertext using the device key of the first network node to obtain the first network key; and the first network node updating its locally maintained network key to the first network key.

[0022] The solution provided in this embodiment allows the first network node to proactively request network key synchronization from the configuration node. Using the first network node's device key, it decrypts the first ciphertext carried in the first message from the configuration node to obtain the first network key of the current Bluetooth Mesh network, thus achieving key synchronization. During this process, the device key of the first network node is known only to the configuration node and the first network node, which enhances the security of the first message during transmission. Furthermore, this method provides a way for the first network node to recover its network key if it misses the key update process, eliminating the need for the user to manually rejoin the first network node to the Mesh network and improving the efficiency of network key recovery.

[0023] In one possible embodiment, after completing the aforementioned key update process, the first network node may also send a third message to the configuration node, the third message being used to indicate that the first network node has successfully synchronized the first network key.

[0024] In one possible embodiment, after completing the aforementioned key update process, the first network node may also use the first network key to update the global encryption index (IV Index), update the application key (APP Key), or reset the local serial number (SegNum).

[0025] In one possible embodiment, the first network node may send a second message to the configuration node if it fails to establish a friend node multiple times after being woken up.

[0026] Specifically, when the first network node switches from a dormant state to a wake-up state, the first network node sends a fourth message to the second network node; wherein the second network node and the first network node have established a friend relationship (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 retrieve the messages temporarily stored by the second network node for the first network node. For example, the fourth message can be a Friend Poll message.

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

[0028] Therefore, 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, which is used to request the establishment of a friend relationship. For example, the fifth message can be a Friend Request message.

[0029] 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 (i.e., message 2) to the configuration node.

[0030] Thirdly, this application provides a network device, including: at least one processor and a memory; the memory stores computer-executable instructions; the at least one processor executes the computer-executable instructions, causing the network device to perform the method as described in any one of the embodiments of the first or second aspect.

[0031] Fourthly, this application provides a network system comprising: at least two network nodes, wherein a configuration node is one of the network nodes in the Bluetooth Mesh network, the configuration node being configured to configure the network key of the Bluetooth Mesh network, and to perform the method as described in any embodiment of the first aspect; any other network node besides the configuration node is configured to perform the method as described in any embodiment of the second aspect.

[0032] Fourthly, this application provides a computer-readable storage medium storing computer-executable instructions, which, when executed by a processor, implement the method described in the first or second aspect.

[0033] Fifthly, this application provides a computer program that, when executed by a computer, performs the method described in the first or second aspect.

[0034] In one possible design, the program in the fifth aspect can be stored wholly or partially on a storage medium packaged with the processor, or it can be stored wholly or partially on a memory not packaged with the processor.

[0035] In summary, the key update method, network device, system, and storage medium provided in this application embodiment encrypt the first network key of the current Bluetooth Mesh network using the device key of the first network node in each node of the Bluetooth Mesh network. The network key maintained locally by the first network node is inconsistent with the first network key of the current Bluetooth Mesh network. Therefore, the configuration node sends a first ciphertext obtained by encrypting the first network key to the first network node, enabling the first network node to synchronize the first network key. This provides a method for synchronizing the latest network key for first network nodes that miss the key update process. Furthermore, only the configuration node and the first network node in the entire Bluetooth Mesh network can decrypt this first message, ensuring communication security during the key update process. Attached Figure Description

[0036] Figure 1 A schematic diagram of a Bluetooth Mesh network architecture provided in this application;

[0037] Figure 2 A schematic diagram illustrating the application of a Bluetooth Mesh network in a smart home scenario, as provided in this application embodiment;

[0038] Figure 3 This is a schematic diagram of message interaction in a key update method in the prior art.

[0039] Figure 4 A message interaction diagram illustrating a key update method provided in this application;

[0040] Figure 5 A schematic diagram of message interaction for a key recovery method provided in this application;

[0041] Figure 6 A schematic diagram of message interaction for another key recovery method provided in this application;

[0042] Figure 7 A schematic diagram of message interaction for another key recovery method provided in this application;

[0043] Figure 8 A schematic diagram of message interaction for another key recovery method provided in this application;

[0044] Figure 9 A schematic diagram of message interaction for another key recovery method provided in this application. Detailed Implementation

[0045] The embodiments of this example will now be described in detail with reference to the accompanying drawings.

[0046] In this application, "at least one" means one or more, and "more than one" means two or more. "And / or" describes the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can mean: A alone, A and B simultaneously, or B alone, where A and B can be singular or plural. The character " / " generally indicates that the preceding and following related objects are in an "or" relationship. "At least one of the following" or similar expressions refer 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, and c can be single or multiple.

[0047] The embodiments of this application can be applied to any Bluetooth Mesh network.

[0048] Bluetooth Mesh networks are many-to-many networks. A Bluetooth Mesh network can include multiple network nodes, also known as nodes within the Bluetooth Mesh network. These nodes can be abbreviated as nodes, Mesh nodes, device nodes, Mesh devices, etc., and this application embodiment does not impose any particular restrictions on their naming. In a Bluetooth Mesh network, each network node can communicate freely with other network nodes. Relay nodes can relay received messages. Thus, in a Bluetooth Mesh network, messages can reach the receiving end through relaying by one or more Mesh nodes, greatly expanding the message transmission range and the coverage of the Mesh network.

[0049] For example, Figure 1 A schematic diagram of a Bluetooth Mesh network provided in an embodiment of this 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 enable communication between the Bluetooth Mesh network and other networks. For example, the Mesh gateway can enable communication between the Bluetooth Mesh network and networks such as Wireless-Fidelity (WiFi) networks and ZigBee (Zifeng protocol) networks. Further details will follow... Figure 1 Detailed explanation.

[0050] A Bluetooth Mesh network 100 may include a Mesh gateway, and in addition, the Bluetooth Mesh network may include other Mesh nodes. For example... Figure 1 As shown, the Bluetooth Mesh network 100 includes: Mesh gateway 110 and multiple Mesh nodes: Mesh node 111 to Mesh node 117.

[0051] In a Bluetooth Mesh network, other Mesh nodes can connect directly to Mesh Gateway 110, or indirectly through one or more other Mesh nodes. For example... Figure 1 As shown, Mesh node 111 is directly connected to Mesh gateway 110, Mesh nodes 112 and 113 are connected to Mesh gateway 110 through Mesh node 114, and Mesh nodes 115 and 116 are connected to Mesh gateway 110 through Mesh node 117.

[0052] It should be understood that Figure 1 The number and connection relationships of the mesh nodes in the Bluetooth mesh network shown are merely an example, and the embodiments of this application are not limited thereto. For example, the Bluetooth mesh network may also include more or fewer mesh nodes, and for example, one or more of mesh nodes 111 to 117 may be connected to more mesh nodes.

[0053] Mesh nodes can be categorized based on whether they have a sleep state. Specifically, the mesh nodes in the Bluetooth Mesh network 100 can be divided into long-power nodes and low-power nodes (LPNs). Long-power nodes generally do not have a sleep state, while LPN nodes have sleep and wake-up states to reduce power consumption.

[0054] In one exemplary embodiment, a Mesh node directly connected to a power source can be a long-term powered node, while a Mesh node powered by a battery or other mobile power source (or device) can be an LPN node. For example, a long-term powered node can be an electronic device such as a TV or computer connected to a power source, and these long-term powered nodes can communicate with other Mesh nodes via a Bluetooth module; while an LPN node can be an electronic device such as a mobile phone, Bluetooth headset, or Bluetooth speaker with Bluetooth functionality. These LPN nodes generally do not remain continuously connected to a power source for extended periods and can be powered by a battery or similar device, and communicate with other Mesh nodes.

[0055] In a Bluetooth Mesh network, the Mesh gateway is a continuously powered node. Other Mesh nodes besides the Mesh gateway include continuously powered nodes and LPN nodes. LPN nodes can be directly connected to the Mesh gateway, or indirectly connected to the Mesh gateway through one or more other Mesh nodes (continuously powered nodes).

[0056] For example, in Figure 1 In the Bluetooth Mesh network 100 shown, Mesh gateway 110 is a long-powered node. In addition, Mesh nodes 114 and 117 can also be long-powered nodes, while other nodes, such as Mesh nodes 111-113 and Mesh nodes 115-116, can be LPN nodes. LPN nodes (e.g., Mesh node 111) can be directly connected to Mesh gateway 110; alternatively, LPN nodes (e.g., Mesh nodes 112-113 and Mesh nodes 115-116) can be connected to Mesh gateway 110 through long-powered nodes, in which case the long-powered node acts as a relay node or a friend node.

[0057] When dividing Mesh nodes according to their functional roles, a Bluetooth Mesh network can include the following types: Mesh gateway node (or Bluetooth Mesh gateway), Bluetooth relay node, proxy node, friend node, and Bluetooth LPN node.

[0058] The Mesh gateway is used to connect the Bluetooth Mesh network to other networks, such as those described later. Figure 1 In the scenario shown, a Mesh gateway can connect a Bluetooth Mesh network and a WiFi router, thereby connecting to other networks, which will be discussed in detail later.

[0059] In addition, the Mesh gateway can also act as a provisioner and / or a configuration client. The provisioner is responsible for the access of Mesh nodes in the entire Bluetooth Mesh network, while the configuration client is responsible for the overall network configuration, which may include, but is not limited to, the configuration of Netkey.

[0060] It should be noted that in real-world scenarios, a Mesh gateway typically functions as both a network access manager and a configuration client. However, in practice, this application embodiment does not impose any particular limitations on whether the configuration client or the network access manager is a Mesh gateway.

[0061] Specifically, the configuration client and network access manager can be implemented through one or more long-powered nodes. For ease of explanation, the Mesh node responsible for the overall network configuration function described in the configuration client will be referred to as the "configuration node." For example, in... Figure 1 In the Bluetooth Mesh network 100 shown, Mesh gateway 110 (a long-powered node) can act as a configuration client and network access manager, undertaking the configuration function of the entire network (Bluetooth Mesh network) Netkey and the network access management function of the entire network. Alternatively, Mesh node 114 (a long-powered node) can act as a configuration client, undertaking the configuration function of the entire network Netkey, and Mesh node 117 (another long-powered node) can act as a network access manager, undertaking the network access management function of the entire network.

[0062] Bluetooth mesh relay nodes are typically continuously powered nodes responsible for forwarding network messages. For example, in... Figure 1 In the Bluetooth Mesh network 100 shown, Mesh node 114 can act as a Bluetooth relay node, which can be used to forward network messages between Mesh gateway 110 and Mesh node 112, and can also be used to forward network messages between Mesh gateway 110 and Mesh node 112.

[0063] A proxy node is typically a continuously powered node responsible for acting as a proxy for BLE devices that are not part of the Bluetooth Mesh network to access the Bluetooth Mesh network. For example, in... Figure 1 In the Bluetooth Mesh network 100 shown, Mesh node 114 and Mesh node 117 can act as proxy nodes to handle network access for BLE devices that are not part of the current Bluetooth Mesh network system. The proxy process will not be described in detail here.

[0064] Friend nodes are long-running nodes that can temporarily store messages for dormant nodes (i.e., LPN nodes in a dormant state) with which they have established a friend relationship. Thus, when a dormant LPN node wakes up, it can retrieve the messages it received during its dormancy period by interacting with its 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 sleep; 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 sleep.

[0065] In one exemplary embodiment, when Mesh node 112 wakes up from hibernation, it can send a friend poll message to its friend node, namely Mesh node 114. This friend poll message requests network messages from the friend node that were stored during its hibernation period. Therefore, when Mesh node 114 receives this friend poll message and has stored the temporary messages from Mesh node 112's hibernation period, Mesh node 114 can send a response message back to Mesh node 112. This response message carries the messages that Mesh node 114 temporarily stored for Mesh node 112 during its hibernation period.

[0066] In one possible implementation, to maximize the coverage of the mesh network, a long-powered node can simultaneously function as a relay node, proxy node, and friend node. In this case, the long-powered node can be called a Mesh Relay, Proxy & Friend node. For example, Figure 1 In the system shown, Mesh node 114 can be a Mesh Relay, Proxy & Friend node.

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

[0068] For example, Bluetooth Mesh networks can be further applied to smart home scenarios. In this case, you can refer to... Figure 2 , Figure 2 This illustration shows a schematic diagram of a Bluetooth Mesh network applied to a smart home scenario, as provided in an embodiment of this application. Figure 2 As shown, this communication system includes a Bluetooth Mesh network 100, exemplarily. Figure 2 The Bluetooth Mesh network shown includes Mesh gateway 110 and Mesh node 111. It can be understood that the Bluetooth Mesh network 100 may also include more Mesh nodes, such as... Figure 1 As shown, no further explanation is provided here.

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

[0070] In one exemplary embodiment, Figure 2A ZigBee network 200 is illustrated, comprising a ZigBee gateway 210 and ZigBee devices 220. In this scenario, Mesh node 111 is connected to WiFi router 310 via Mesh gateway 110, and ZigBee device 220 is connected to WiFi router 310 via ZigBee gateway 210. Thus, Mesh node 111 and ZigBee device 220 can communicate via WiFi router 310.

[0071] In another exemplary embodiment, Figure 2 The diagram further illustrates a WiFi device 320. In this scenario, Mesh node 111 is connected to WiFi router 310 via Mesh gateway 110, and WiFi device 320 is also connected to WiFi router 310. Thus, Mesh node 111 and WiFi device 320 can communicate through WiFi router 310.

[0072] In another exemplary embodiment, Figure 2 The terminal is also shown further. For example, Figure 1 The document specifically illustrates two forms of the terminal: a tablet computer 410 and a mobile phone 420. In this embodiment, the terminal may also have other forms, such as a laptop computer, a handheld computer, a mobile internet device (MID), a smart speaker, a smart TV, or other terminals with WiFi access capabilities. In this scenario, the terminal can communicate with the WiFi router 310. Therefore, the Mesh node 111 can communicate with the mobile phone 420 and the tablet computer 410 through the Mesh gateway 110 and the WiFi router 310.

[0073] In another exemplary embodiment, Figure 2 It also further demonstrates the Smart Home Cloud 500, such as 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.

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

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

[0076] In the aforementioned Bluetooth Mesh network 100, each Mesh node communicates with others using a network key (Netkey) to encrypt information. Specifically, each Mesh node can store its own Netkey. As mentioned earlier, the configuration client is responsible for the overall network configuration, which may include, but is not limited to, configuring the Netkey. The Netkey is generally configured by the configuration client (or configuration node) and synchronized across the entire network. For each Mesh node (including the Mesh gateway), the Mesh node's Netkey must be consistent with the global Netkey in order to communicate normally with other Mesh nodes.

[0077] According to the Bluetooth Mesh 1.0 specification, when there is a risk of NetKey and / or AppKey leakage, for example when a Mesh node is removed from the Bluetooth Mesh network, a Key Refresh procedure can be used to update the NetKey and AppKey across the entire network. Before performing the Key Refresh procedure, the Configuration Client can add the Mesh nodes at risk of leakage to a blacklist (or update key blacklist). Mesh nodes on the blacklist cannot obtain the new keys (including NetKey, and possibly other keys such as AppKey).

[0078] This is illustrative and can be used as a reference. Figure 3 The diagram illustrates the message interaction process in the prior art for key updates. This key update process mainly involves message interaction between the configuration client and each Mesh node outside the blacklist. Figure 3 In the configuration, the client is specifically set to a Mesh gateway. Figure 3 This illustration shows the message exchange process between the Mesh gateway and a Mesh node during a Netkey update.

[0079] like Figure 3 As shown, when updating the Netkey across the entire network, the key update process includes the following steps:

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

[0081] The key update message carries a second ciphertext, which is obtained by using a double encryption mechanism. This second ciphertext is obtained by doubly encrypting the first network key (i.e., the new network key) using the original network key (the original Netkey, which can also be referred to as the second network key) and the device key (Devkey) of the Mesh node. 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.

[0082] exist Figure 3 During the key update process shown, the Mesh gateway can send key update messages, which are encrypted using the Devkey of the Mesh node and the original Netkey, to each Mesh node that is not on the blacklist.

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

[0084] Specifically, the key update message can be sent through a configuration model. It is understood that the key update message is used to update the Netkey of the Bluetooth Mesh network, and the naming convention is not particularly limited in this embodiment. For example, the key update message can be a Config Network Key Update message.

[0085] In addition, the Mesh gateway also sends a Config Key Refresh Phase Set message with a Transaction value of 2 to the Mesh nodes. When the Transaction value of the Config Key Refresh Phase Set message is 2, this message indicates that the Mesh node can encrypt and send the message using the new Netkey, and that the Mesh node can decrypt the message using either the new Netkey or the original Netkey.

[0086] It's important to note that the meaning of the Config Key Refresh Phase Set message differs depending on the Transaction value carried within it. A Config Key Refresh Phase Set message with a Transaction value of 3 will also be discussed later, and will be explained in detail thereafter.

[0087] S304, Mesh node decryption key update message.

[0088] As mentioned earlier, the key update message is sent after doubly encrypting the new Netkey using the original Netkey and the Mesh node's Devkey. Therefore, upon receiving the key update message, the Mesh node can decrypt the second ciphertext carried in the message using the original Netkey and its own Devkey. In other words, when the Mesh node receives the key update message, it decrypts it at the network layer using the original Netkey and at the Model layer using its own Devkey. If both decryptions are successful, the Mesh node obtains the new Netkey.

[0089] S306. When decryption is successful, the Mesh node sends a first notification to the Mesh gateway, which informs the Mesh gateway that it has successfully received the new network key.

[0090] At this point, the Mesh node learns the new Netkey, and the original Netkey has not been deprecated. Currently, in a Bluetooth Mesh network, the sending Mesh node can encrypt data using the new Netkey before sending it, while the receiving Mesh node can decrypt it using either the new or the original Netkey.

[0091] Specific implementation Figure 3 During the key update process shown, the first notification is sent via the Config Model. Specifically, the first notification is the Config NetKey States message.

[0092] S308 When the first notification is received from all non-blacklisted Mesh nodes, the Mesh gateway sends a second notification across the entire network to notify the entire network to revoke the original network key.

[0093] Specifically, before each Mesh node receives the second notification, each Mesh node can use either 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 use only the new Netkey to communicate with other Mesh nodes.

[0094] 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, this message (i.e., the second notification) is used to instruct the Mesh nodes to communicate using only the new Netkey. In other words, the original Netkey is discarded.

[0095] Furthermore, after receiving a Config Key Refresh PhaseSet message with a Transaction value of 3, each Mesh node can also send a Config Key Refresh Phase States message to the Mesh gateway. This Config Key Refresh Phase States message indicates that it (the Mesh node) has completed the key update settings.

[0096] by Figure 1 Taking the Bluetooth Mesh network 100 shown as an example, the key update process will be explained. Figure 1 In the illustrated embodiment, Mesh gateway 110 acts as a configuration client, distributing key update messages to Mesh nodes 111 to 117. Therefore, for any one of Mesh nodes 111 to 117, taking Mesh node 111 as an example, upon receiving the key update message, Mesh node 111 decrypts the message using its stored original Netkey. Successful decryption yields the new Netkey. Subsequently, Mesh node 111 sends a Config NetKey States message (i.e., the first notification) to Mesh gateway 110.

[0097] In addition, 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. During this phase, when Mesh node 111 sends a message to other Mesh nodes, it encrypts the message using the new Netkey before sending it; when receiving a message from other Mesh nodes, Mesh node 111 decrypts it using either the new Netkey or the original Netkey.

[0098] Until Mesh Gateway 110 receives Config Key Refresh PhaseStates messages from all Mesh nodes—that is, when Mesh Gateway 110 receives Config Key Refresh Phase States messages from Mesh nodes 111 to 117 respectively—Mesh Gateway 110 sends a Config Key Refresh Phase Set message (second notification) with a transaction value of 3 to Mesh nodes 111 to 117 to invalidate the original Netkey. This achieves a full network update of the Netkey.

[0099] It is important to note that, in Figure 3 During the key update process shown, before step S308 is executed, the Mesh gateway needs to confirm that all Mesh nodes not on the blacklist have successfully received the new Netkey. That is, after receiving the first notification from all Mesh nodes not on the blacklist, it will send the second notification across the entire network.

[0100] Therefore, when a Mesh node not on the blacklist fails to send the first notification to the Mesh gateway for some reason, the Mesh gateway will not be able to receive the first notification from that Mesh node.

[0101] For clarity, in the following explanation, a Mesh node (or Mesh node) that is not on the key update blacklist and fails to send the first notification during the key update process will be referred to as the first network node (or first network node). The first network node may fail to send the first notification to the Mesh gateway due to one or more reasons, such as being in a dormant state, battery issues, malfunction, communication interference, or being moved out of the Bluetooth Mesh network's coverage area. The reasons why the first network node fails to send the first notification may include: the first network node failing to receive the key update message, and / or the first network node being unable to send the first notification.

[0102] In this scenario, the Mesh gateway can wait until it receives the first notification from all non-blacklisted Mesh nodes before executing S308 to complete the key update process.

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

[0104] However, in Bluetooth Mesh networks, the key update process is generally initiated based on the risk of key leakage. For example, it may be initiated when a Mesh node leaves the network, or when a new Mesh node joins the network. Figure 3 The key update process is illustrated. Therefore, the longer the Mesh gateway waits during the key update process, the greater the chance the Bluetooth Mesh network is vulnerable to Trash-can attacks, and the higher the security risk.

[0105] In some cases, the first network node may be unable to resolve the fault, thus preventing it from successfully sending the first notification to the Mesh gateway. If the Mesh gateway continues to wait, the key update process may never be completed, which greatly affects the security of the Bluetooth Mesh network.

[0106] Besides the aforementioned key update methods, maintenance personnel can also provisioning the first network node to allow it to rejoin the network and obtain the latest network key. However, this key update method requires manual intervention from maintenance personnel, and the reconfiguration process is cumbersome and complex, with poor timeliness, thus posing certain security risks.

[0107] The technical solutions of this application will be described in detail below with specific embodiments. These technical solutions can obtain updated network keys for Mesh nodes that have missed key updates, which is beneficial to improving the security of Bluetooth Mesh networks. The following specific embodiments can be combined with each other, and the same or similar concepts or processes may not be described again in some embodiments. The embodiments of this application will be described below with reference to the accompanying drawings.

[0108] This application provides a key update method that can be applied to Bluetooth Mesh networks to implement key updates for Bluetooth Mesh networks.

[0109] In this embodiment, the configuration client can be handled by a continuously powered node in the Bluetooth Mesh network. For ease of explanation, the Mesh node responsible for configuring the entire network will be referred to as the "configuration node." As mentioned earlier, the configuration node can specifically be a Mesh gateway in the Bluetooth Mesh network, or it can be any continuously powered node other than a Mesh gateway. For example, Figure 1 In the scenario shown, the configuration node can be Mesh gateway 110, or it can be Mesh node 117 or Mesh node 114.

[0110] For ease of explanation, we will use a configuration node and another Mesh node (excluding the configuration node) as an example to illustrate this solution.

[0111] In this embodiment of the invention, the key update process for the Bluetooth Mesh network can be referred to... Figure 4 Specifically, it may include the following steps:

[0112] S402, the configuration node sends a key update message to the Mesh node, in which the key update message carries the encrypted new network key.

[0113] 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.

[0114] Understandably, in real-world scenarios, the configuration node can send key update messages to each Mesh node other than the configuration node.

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

[0116] In other words, the Mesh node uses the original Netkey and its own Devkey to decrypt the key and update the message.

[0117] S406. When decryption is successful, the Mesh node sends a first notification to the configuration node, which informs the configuration node that it has successfully received the new network key.

[0118] Figure 4 For the implementation methods of S402 to S406, please refer to... Figure 3 The relevant statements in S302 to S306 are not repeated here.

[0119] S408 When the timeout period reaches the preset duration, or when the current time reaches the preset time, the configured node sends a second notification to the entire network. This second notification is used to notify the entire network to abolish the original network key.

[0120] The starting point for the timing duration is the moment when the configured node in S402 sends a key update message.

[0121] In other words, in Figure 4 In the illustrated embodiment, after the configuration node sends the key update message, it can start timing. When the timing reaches a preset duration (or waiting time, timeout period), or when the current time reaches a preset time, the configuration node sends a second notification to notify the entire network that the original network key has been revoked. Thus, through 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 feedback from Mesh nodes.

[0122] However, in Figure 4 During the key update process shown, there may be Mesh nodes, i.e., the first network nodes, that fail to successfully send the first notification to the configuration node for some reason. Therefore, in this embodiment of the application... Figure 4 Based on the key update process shown, a key recovery process for the first network node is further provided.

[0123] In this application embodiment, the first network node refers to a portion of the Bluetooth Mesh network whose locally maintained network key after the key update process is inconsistent with the first network key of the current Bluetooth Mesh network.

[0124] It should be understood that the "key recovery process" is actually the key update process for the first network node; this naming is only used to distinguish it from 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 considered as part of the key update process. For ease of distinction, the following explanations will use... Figure 4 The key update process shown for all Mesh nodes (not on the blacklist, and all Mesh nodes except the configuration node) 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.

[0125] Specifically, when restoring the key for the first network node, the first network node can obtain the new network key through message interaction between the first network node and the configuration node.

[0126] 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. Each Mesh node has a unique Devkey, which can only be obtained by the Mesh node itself and the configuration node. Therefore, encrypting the Config Model message using the first network node's Devkey ensures that only the first network node and the configuration node can successfully decrypt the message, thus improving the security of message exchange during key recovery.

[0127] Specifically, the key recovery process can be triggered by the configuration node based on the update failure list; or, the first network node can send a key recovery request to the configuration node, and the configuration node can then respond to the received key recovery request.

[0128] The following explains the implementation methods of these two key recovery processes.

[0129] The first key recovery method involves configuring the node to actively trigger the aforementioned key recovery process based on the update failure list.

[0130] The update failure list is used to record Mesh nodes that fail to update during the key update process. Specifically, the update failure list can record the node identifier of the Mesh node that failed to update. The node identifier can include, but is not limited to, MAC address, Mesh address, custom number, etc. The custom number can be a combination of one or more of the following: text, characters, and numbers.

[0131] Therefore, this key update method can be used to update keys. Figure 4 The key update process shown is implemented afterward.

[0132] The update failure list can be recorded and maintained by the configuration node. In a Bluetooth Mesh network, the configuration node is responsible for the overall network configuration. Therefore, the configuration node can know which Mesh nodes are included in the current Bluetooth Mesh network. Based on this, the configuration node can determine which Mesh nodes did not promptly respond to the first notification received during the key update process.

[0133] Based on this, in one possible embodiment, the configuration node, in addition to executing... Figure 4 In addition to the key update process shown, the identifiers of Mesh nodes that fail to provide timely feedback on the first notification can also be obtained, and these identifiers are recorded in the update failure list. In this embodiment, the update failure list records all Mesh nodes (including long-powered nodes and LPN nodes) that failed to update in the entire Bluetooth Mesh network.

[0134] Since the update failure list applies to all Mesh nodes (including long-powered nodes and LPN nodes), the configuration node retrieves all long-powered nodes from the update failure list and treats them as first network nodes. Then, key recovery is performed on each first network node separately.

[0135] In this embodiment, for long-powered nodes, the configuration node actively performs key recovery. For LPN nodes that miss key updates, the configuration node can respond to key recovery requests from LPN nodes, as detailed later. This differentiates between long-powered nodes and LPN nodes that miss key updates, preventing LPN nodes from missing the key recovery process initiated by the configuration node due to being in a dormant state. This helps shorten the key recovery process time, improves key recovery efficiency, and saves system resources.

[0136] In this scenario, the configuration node can determine the first network node (or target node, target Mesh node) based on the update failure list. Then, it can use the first network node's Devkey to encrypt the first network key, obtaining the first ciphertext. The first network key is the current network key of the Bluetooth Mesh network. The configuration node then sends message 1 to the first network node, enabling the first network node to decrypt the first ciphertext carried in message 1, thus obtaining the first network key. In the Bluetooth Mesh network, message 1 can reach the first network node in a single hop or via multiple hops relayed through other Mesh nodes. Message 1 can be carried in a Beacon frame.

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

[0138] S502, the configuration node uses the device key of the first network node to encrypt the current network key and obtains the key recovery message.

[0139] like Figure 5 The key recovery process shown is in Figure 4 This process, executed after the key update procedure shown, is used to recover the keys of the mesh nodes that failed to update the Netkey during the key update process. At this time, all long-powered nodes in this part of the mesh nodes that failed to update the Netkey are treated as the first network node, and the following steps are performed. Figure 5 The key recovery process is shown below. At this point, the current network key mentioned in this step can be specifically... Figure 4 The new network key.

[0140] At this time, the current network key of the Bluetooth Mesh network is the first network key. 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.

[0141] S504, the configuration node sends a key recovery message to the first network node.

[0142] In specific implementation, the key recovery message is message 1 as described above. In this embodiment, the configuration node can send the key recovery message externally via broadcast. At this time, the key recovery message (i.e., message 1) carries the identifier of the first network node. Thus, in the Bluetooth Mesh network, the key recovery message can reach the first network node in one hop, or it can reach the first network node through multi-hop relay forwarding via other Mesh nodes.

[0143] S506, the first network node receives the key recovery message (i.e., message 1).

[0144] S508, the first network node uses its device key to decrypt the key recovery message and obtain the current network key.

[0145] The current network key is also the first network key. Specifically, this step involves the first network node using its own Devkey to decrypt the first ciphertext carried in message 1 to obtain the first network key of the current Bluetooth Mesh network.

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

[0147] Because the first network node missed the key update process, the network key it maintains locally is inconsistent with the current network key of the Bluetooth Mesh network. Therefore, when performing this step, the first network node simply updates its locally maintained network key to the current network key of the Bluetooth Mesh network.

[0148] For example, if the first network node locally maintains network key 1, and its power is depleted, it cannot communicate with the Bluetooth Mesh network and misses the Bluetooth Mesh network's key update process. During this period, the Bluetooth Mesh network's network key undergoes three updates: key 1 → key 2 → key 3 → key 4. When the first network node replaces its battery, the current network key of the Bluetooth Mesh network within the Bluetooth Mesh network is key 4. Figure 5 When the aforementioned 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 realize key update.

[0149] Figure 5 This diagram only schematically illustrates the interaction process between a first network node and a configuration node. In real-world scenarios, there may be multiple first network nodes in the Bluetooth Mesh network. In this case, the following steps can be performed separately for each first network node: Figure 5 The key recovery process shown implements key recovery for each first network node. In other words, as... Figure 5 The key recovery process shown is implemented for a single first network node. When there are multiple first network nodes, the key recovery process only needs to be executed multiple times.

[0150] It is understandable that when there are multiple first network nodes, each first network node has a different Devkey, and the first ciphertext obtained in this step is different. That is, the information (first ciphertext) carried by the key recovery message is different.

[0151] It should be noted that, Figure 5The interaction diagram shown is for illustrative purposes only. When this key recovery method is actually applied to a Bluetooth Mesh network, it may require multiple hops to achieve interaction between the two.

[0152] For example, Figure 6 A key recovery method for long-powered nodes is illustrated. Specifically, Figure 6 for Figure 5 The key recovery method shown is applied to Figure 1 The diagram illustrates one implementation method for a Bluetooth Mesh network. Figure 6 The diagram schematically illustrates Mesh node 112 (first network node), Mesh node 114, and Mesh gateway 110 (configuration node). At this time, the key recovery message sent by Mesh gateway 110 to Mesh node 112 needs to be forwarded by Mesh node 114 before it can reach Mesh node 112.

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

[0154] If the first network node is Mesh gateway 110, then Mesh node 117 can send message 1 (key recovery message) to the outside world, which carries the identifier of Mesh gateway 110. At this time, the key recovery message reaches the first network node in one hop.

[0155] Alternatively, if the first network node is Mesh node 114, then Mesh node 117 sends message 1 (key recovery message) to the outside world, which carries the identifier of Mesh node 114. This key recovery message can then be relayed through Mesh gateway 110 to reach Mesh node 114. This is not an exhaustive list.

[0156] 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. This receiver identifier uniquely indicates the receiver of the broadcast message. Specifically, the receiver identifier may include, but is not limited to, the receiver's physical (Media Access Control, MAC) address.

[0157] Thus, in a Bluetooth Mesh network, when any Mesh node receives a key recovery message, it can determine whether it is the recipient of that message based on the receiver identifier (MAC address) carried within it. Specifically, if the MAC address carried in the key recovery message matches its own MAC address, then it is the recipient of the key recovery message; otherwise, if they do not match, it is not the recipient of the key recovery message.

[0158] Therefore, when a Mesh node itself is not the recipient of a 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 recipient of a key recovery message, it decrypts the key recovery message using its own Devkey. For example, Figure 6 During the key recovery process, after receiving the key recovery message, Mesh node 114 determines that it is not the recipient of the key recovery message and that it is a relay node. If so, it forwards the key recovery message to Mesh node 112. After receiving the key recovery message, Mesh node 112 determines that it is the recipient of the key recovery message, decrypts the key recovery message, obtains the current Bluetooth Mesh network key, and then updates the locally maintained network key to complete the key recovery.

[0159] In this embodiment of the application, the key recovery message (message 1) can specifically be a configuration broadcast frame (Beacon). At this time, the configuration broadcast frame carries the first ciphertext encrypted with the current Netkey using the Devkey of the first network node.

[0160] In addition, it should be noted that in a scenario where the configuration node actively performs key recovery for the first network node, the configuration node can send key recovery messages to the first network node multiple times.

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

[0162] In another exemplary embodiment, the configuration node may also periodically send key recovery messages to the first network node until the number of transmissions reaches a preset threshold or a heartbeat is received. The threshold number can be preset as needed and is not particularly limited.

[0163] The second key recovery method involves the first network node sending a key recovery request to the configuration node, which then responds to the received key recovery request and performs the recovery accordingly.

[0164] In this implementation, the configuration node does not need to actively perform key recovery for the first network node; instead, the first network node actively requests it. This implementation is suitable for the key recovery process of LPN nodes, i.e., when the first network node is an LPN node. This is because LPN nodes may be in a dormant state, and adopting an implementation where the LPN node actively requests key recovery is more conducive to saving system resources. Details are as follows.

[0165] Now combined Figure 7 The processing flow shown illustrates the process of key recovery for the LPN node (i.e., the first network node).

[0166] As mentioned earlier, LPN nodes switch between sleep and wake-up states. Specifically, LPN nodes can periodically wake up (enter wake-up state) or fall asleep (enter sleep state). For example, Figure 7 In this context, LPN nodes can periodically transition from a sleep state to a wake-up state.

[0167] Each LPN node has one friend node, which is a node with which it has established a friend relationship. The friend node is a continuously powered node in the Bluetooth Mesh network, used to temporarily store messages for the LPN node while it is in sleep mode. For ease of explanation, the node that has already established a friend relationship with the LPN node (which can be referred to as the first network node) is denoted as the friend node.

[0168] So, if Figure 7 As shown, when an LPN node switches from a dormant state to a wake-up state, that is, after the LPN node wakes up, it can send a message retrieval request (i.e., the fourth message) to a friend node. This message retrieval request is used to request the messages that the friend node temporarily stored for it during its dormant period. For example, the message retrieval request can specifically be a Friend Poll message.

[0169] It's important to note that when an LPN node sends a message retrieval request, it needs to encrypt the request using a locally maintained network key. When a friend node receives this request, it can decrypt it using the same locally maintained network key.

[0170] If decryption is successful, the friend node sends the message it has temporarily stored to the LPN node. The LPN node can then 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 initiate a key recovery process. Therefore, after receiving the message temporarily stored by the friend node, the LPN node can process the message or perform other data processing procedures. This embodiment of the application does not impose any particular limitations on this. Figure 7 It is represented as "working". In addition, LPN nodes can switch from a wake-up state to a sleep state (timed sleep) at a predetermined time or according to a preset cycle.

[0171] 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 retrieval request. In other words, the friend node will not send back the message it has temporarily stored to the LPN node. At this time, the LPN node will not receive any feedback regarding the message retrieval request.

[0172] In this scenario, if the LPN node does not receive a feedback message from the friend node within a preset first time period, the LPN node can repeatedly attempt to send message retrieval requests to the friend node. For example, if no feedback message is received from the friend node within a preset first time period after the fourth message is sent, the LPN node periodically sends message retrieval requests to the friend node until it receives a feedback message from the friend node, or until the number of requests reaches a preset first threshold.

[0173] If, after multiple attempts, the LPN node fails to receive a message from the friend node, there are two possible reasons: the network key maintained locally by the LPN node has expired; or the friend node has malfunctioned. For example, the friend node may have been moved out of the Bluetooth Mesh network's coverage area, missed the key update process, or experienced a communication failure, etc., to name just a few.

[0174] In this scenario, an LPN node can attempt to establish a friendly relationship with other long-supply nodes. That is, the LPN node selects other long-supply nodes as its friendly nodes.

[0175] When the number of times the fourth message is sent reaches a preset first threshold, and no feedback message is received from the friend node, the LPN node broadcasts a friend establishment request (the fifth message). The friend establishment request is used to request the establishment of a friend relationship with the network node. For example, the friend establishment request can be a Friend Request message. It should be noted that the Friend Request message cannot be forwarded by relay nodes; only network nodes within the wireless coverage area of ​​the LPN node can process this Friend Request message.

[0176] Similarly, when an LPN node sends a friend request, it needs to encrypt the request using a locally maintained network key. Long-supplying nodes around the LPN node, upon receiving the friend request, can decrypt it using their locally maintained network key.

[0177] If decryption is successful, the long-powered node can establish a friend relationship with the LPN node. The establishment of this friend relationship is existing technology and will not be elaborated upon here. After establishing the friend relationship, the long-powered node becomes a friend node of the LPN node. The LPN node can then perform its wake-up operations until a predetermined time is reached or a preset period is followed, at which point it switches from the wake-up state to a sleep state (timed sleep).

[0178] If the network keys maintained by the LPN node and the long-powered node are inconsistent, decryption will fail, and the LPN node will be unable to establish a friend relationship with the long-powered node.

[0179] In this case, if the LPN node does not receive feedback messages from other network nodes within the preset second time period, the LPN node can try to establish a friendly relationship with other network nodes multiple times until the friendly relationship is successfully established, or until the number of times the fifth message is sent reaches the preset second threshold.

[0180] If, after multiple attempts, the LPN node fails to receive messages from other long-supply nodes—that is, when the number of times the fifth message is sent reaches a preset second threshold and no feedback messages are received from other network nodes—it indicates that the network key maintained locally by the LPN node may have expired. In this case, the LPN node can proactively initiate a key recovery process. Specifically, the LPN node sends message 2 to the configuration node to request the recovery of the network key (or, to request synchronization of the current network key). Further details will follow. Figure 8 Detailed explanation.

[0181] After the LPN node recovers the network key from the configuration node, it can communicate normally with other Mesh nodes and perform tasks or wait. Figure 7The specific processing behavior of the LPN node in the wake-up state is not shown. Afterwards, the LPN node can switch from the wake-up state to the sleep state (timed sleep) at a predetermined time or according to a preset cycle.

[0182] Thus, the LPN node follows Figure 7 The method shown enables proactive recovery of the network key while the device is in a wake-up state.

[0183] Figure 8 The diagram illustrates the message interaction during the key recovery process of an LPN node. Figure 8 In the illustrated embodiment, in addition to including Figure 5 In addition to steps S502 to S510 in the illustrated embodiment, such as Figure 8 As shown, prior to S502, the method further includes the following steps:

[0184] S5012, when the number of times the friend relationship fails to be established reaches a preset second threshold, the first network node sends a key recovery request to the configuration node.

[0185] During the key recovery process, the first network node can send a key recovery request via broadcast. In this case, the key recovery request can also be simply referred to as: Message 2. Message 2 (i.e., the key recovery request) is used to request the network key to be recovered from the configuration node, or it can be referred to as: Message 2 is used to request the synchronization of the current network key (i.e., the first network key) of the Bluetooth Mesh network.

[0186] Furthermore, as mentioned earlier, the situation where the number of failed attempts to establish a friend relationship reaches a preset second threshold is defined as follows: the number of times the fifth message is sent reaches the preset second threshold, and no feedback message is received from other network nodes. In this case, the first network node sends message 2 to the configuration node, which carries the identifier of the configuration node. For example, message 2 carries the MAC address of the configuration node.

[0187] For security reasons during communication, the key recovery request is sent encrypted using the device key of the first network node. For example, the encryption algorithm may include, but is not limited to, the AES-CCM algorithm.

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

[0189] S5014, the configuration node receives the key recovery request and obtains the device key of the first network node based on the identifier information of the sender.

[0190] S5016, the configuration node uses the device key of the first network node to decrypt the key recovery request.

[0191] As mentioned earlier, the device key of a Mesh node is known only to the Mesh node itself and the configuration node. Therefore, if decryption is successful, the configuration node can determine the legitimacy of the first network node, and can then execute steps S502 to S510 to recover the key of the first network node.

[0192] Conversely, if decryption fails, the configuration node cannot verify the identity of the sending node of the key recovery request, and the configuration node may choose not to send the current Bluetooth Mesh network key back to the sending node.

[0193] In addition, with Figure 5 Similar to the key recovery message mentioned above, the key recovery request can be a one-hop interaction, for example... Figure 1 The message interaction between Mesh node 111 and Mesh gateway 110; or, the key recovery request may reach the configuration node after multiple hops through multiple Mesh nodes.

[0194] For example, Figure 9 Specifically shown Figure 8 A schematic diagram illustrating how messages in S5012 and S504 reach the receiving end via multi-hop forwarding. Figure 9 The middle part is omitted Figure 8 The processing of other steps in the process. Figure 9 Specifically, it illustrates a first network node (LPN node), n long-powered nodes, and a gateway node (configuration node), where n is 0 (one-hop direct interaction) or a positive integer (multi-hop forwarding). Figure 9 In the illustrated embodiment, in step S5012, after the first network node sends a key recovery request, it is forwarded n times by long-powered nodes 1 to n to the gateway node. Similarly, in step S504, when the gateway node sends a key recovery message to the first network node, it is also forwarded n times by long-powered nodes n to 1 to the gateway node.

[0195] It should be noted that during the process of the first network node actively requesting the recovery of the network key, the first network node can also repeat the following steps multiple times: Figure 8 or Figure 9 The process shown continues until the first network node can successfully communicate with other Mesh nodes.

[0196] In one exemplary embodiment, the first network node can periodically send key recovery requests to the configuration node until it successfully receives a feedback message from the friend node after sending a message retrieval request. In other words, after the first network node executes S510 and successfully updates the locally maintained network key, it can send a FriendPoll message to the friend node. If the first network node receives a feedback message from the friend node, it will no longer request to update the network key from the configuration node.

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

[0198] In any of the foregoing embodiments, for example, Figure 5 , Figure 8 , Figure 9 In any of the embodiments shown, after the first network node updates and synchronizes its local network key based on the received message 1, it can also send a third message to the configuration node side. 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.

[0199] Furthermore, it should be noted that in the embodiments of this application, for Figure 8 The key recovery process shown is in Figure 4 The key update process shown is executed after the key update process, and the order of the two is limited.

[0200] Based on the aforementioned processing, the key of any Mesh node in the Bluetooth Mesh network can be updated. Furthermore, after successfully updating or restoring the Netkey, the Mesh node (exemplarily, such as the first network node) can also use the first network key to update one or more of the following: update the network-wide encryption index, update the application key, or reset the local serial number.

[0201] For example, any Mesh node can update the network-wide encrypted index (IV Index) through a secure broadcast frame (Secure Beacon).

[0202] Specifically, Mesh nodes can update their IV Index through either the IV Index Update process or the IV Index Recovery process. Both processes update the IV Index, but their triggering conditions differ. For example, if the IV Index in the SecureBeacon received by the Mesh node is one greater than the IV Index maintained by the Mesh node itself, and the IV Update Flag is 1, then the IV Index Update process is initiated to update the IV Index. Otherwise, or if 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 IV Index Recovery process. Further explanation is omitted.

[0203] In this application, when updating the IV Index using Secure Beacon, the Secure Beacon can be encrypted using the Netkey maintained by the current Mesh node (e.g., the updated new Netkey, which is also the first network key) before message exchange.

[0204] The embodiments of this application do not impose any special restrictions on the triggering conditions and implementation methods for the process of updating the IV Index. Relevant standards or other publicly available texts in the prior art can be used, and will not be discussed further here.

[0205] In addition to updating the IV Index, Mesh nodes can also reset their own locally maintained 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.

[0206] The embodiments of this application do not have any special restrictions on the triggering conditions and implementation methods of resetting SeqNum. Relevant standards or other public texts in the prior art can be used, which will not be discussed further here.

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

[0208] Specifically, the APPkey can be updated through a Config Model. In other words, Mesh nodes can exchange information through the Config Model to update the APPkey. When exchanging information using the Config Model, the sending end uses the updated Netkey and the receiving end's Devkey to encrypt the information.

[0209] Similarly, the embodiments of this application do not have any special restrictions on the triggering conditions and implementation methods of the APPkey update process. Relevant standards or other public texts in the prior art can be adopted, which will not be discussed further here.

[0210] It is understood that some or all of the steps or operations in the above embodiments are merely examples, and other operations or variations thereof can be performed in the embodiments of this application. Furthermore, the steps may be performed in different orders as presented in the above embodiments, and it is not necessary to perform all the operations in the above embodiments.

[0211] This application also provides a network device.

[0212] For example, this application provides a network device, which includes a processing module and a transceiver module; wherein the processing module is configured to: determine a first network node from the network nodes of the 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; 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 configured to send a first message to enable the first network node to obtain the first network key, wherein the first message carries the first ciphertext.

[0213] In one possible embodiment, the transceiver module is further configured to: receive a second message, the second message being used to request the synchronization of a network key; at this time, the processing module is specifically configured to: when the network node indicated by the requester identifier carried in the second message is not a deleted node, determine the network node indicated by the requester identifier carried in the second message as the first network node.

[0214] In another possible embodiment, the processing module is specifically configured to: determine each long-powered 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 keys and are not deleted nodes; the long-powered nodes are other network nodes in the Bluetooth Mesh network besides low-power nodes.

[0215] In another possible embodiment, the network device is a configuration node, which is a Mesh gateway or other long-powered node.

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

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

[0218] For example, this application also provides another network device. The network device includes: a processing module and a transceiver module; wherein the transceiver module is configured to send a second message to the configuration node, the second message being used to request synchronization of a network key; and to receive a first message from the configuration node, the first message carrying first ciphertext, the first ciphertext being obtained by encrypting a first network key of the Bluetooth Mesh network using the device key of the network device, wherein the network key maintained locally by the network device is inconsistent with the first network key; the processing module is configured to decrypt the first ciphertext using the device key of the network device to obtain the first network key; and to update the locally maintained network key to the first network key.

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

[0220] In one possible embodiment, the processing module is further configured to: use the first network key to update one or more of the following: update the network-wide encryption index, update the application key, or reset the local serial number.

[0221] In one possible embodiment, the transceiver module is specifically configured to: send a fourth message to a second network node when the network device switches from a sleep state to a wake-up state; wherein the second network node has established a friendly relationship with the network device, and the second network node is configured to temporarily store messages for the network device during the network device's sleep state; the fourth message is configured to request the retrieval of messages temporarily stored by the second network node for the network device; and to: broadcast a fifth message 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 fifth message being configured to request the establishment of a friendly relationship; and to: send a second message to the configuration node 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.

[0222] The network device provided in this embodiment can be used to implement the technical solution on the Mesh node (including but not limited to the first network node) side of any embodiment. Its implementation principle and technical effect can be further referred to the relevant description in the method embodiment.

[0223] It should be understood that the division of the various modules in the above network devices is merely a logical functional division. In actual implementation, they can be fully or partially integrated into a single physical entity, or they can be physically separated. Furthermore, these modules can be implemented entirely in software through processing element calls; they can be implemented entirely in hardware; or some modules can be implemented in software through processing element calls, while others are implemented in hardware. For example, a processing module can be a separate processing element, or it can be integrated into the communication device, such as a chip in a mesh device. Alternatively, it can be stored as a program in the communication device's memory, and its functions can be called and executed by a processing element within the communication device. The implementation of other modules is similar. Moreover, these modules can be fully or partially integrated together, or they can be implemented independently. The processing element mentioned here can be an integrated circuit with signal processing capabilities. In the implementation process, the steps of the above methods or the various modules can be completed through integrated logic circuits in the hardware of the processor element or through software instructions.

[0224] For example, these modules can be one or more integrated circuits configured to implement the above methods, such as one or more Application Specific Integrated Circuits (ASICs), one or more digital signal processors (DSPs), or one or more Field Programmable Gate Arrays (FPGAs). As another example, when a module is implemented via a processing element scheduler, the processing element can be a general-purpose processor, such as a Central Processing Unit (CPU) or other processor capable of calling programs. Furthermore, these modules can be integrated together to form a system-on-a-chip (SOC).

[0225] This 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, causing the network device to perform the methods executed on the configuration node side or Mesh node (including but not limited to the first network node) side in any of the foregoing embodiments.

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

[0227] In an alternative design, the processor may also store instructions that can be executed by the processor to cause the network device to perform the methods described in the above method embodiments corresponding to a configuration node or a Mesh node (including but not limited to a first network node).

[0228] In another possible design, the network device may include circuitry that performs the functions of sending, receiving, or communicating as described in the foregoing method embodiments.

[0229] Optionally, the network device may include one or more memories storing instructions or intermediate data. These instructions can be executed on the processor, causing the network device to perform the methods described in the above method embodiments. Optionally, the memory may also store other related data. Optionally, the processor may also store instructions and / or data. The processor and memory may be configured separately or integrated together.

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

[0231] 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, a transceiver may send the key recovery message to the first network node. The transceiver may also perform other corresponding communication functions. The processor is used to perform corresponding determination or control operations, and optionally, it may store corresponding instructions in the memory. The specific processing methods of each component can be found in the descriptions of the foregoing embodiments.

[0232] If the network device (as the first network node) is used to implement the corresponding Figure 8 When the first network node sends 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 perform corresponding determination or control operations, and optionally, it can also store corresponding instructions in the memory. The specific processing methods of each component can be referred to the relevant descriptions in the foregoing embodiments.

[0233] The processor and transceiver described in this application can be implemented on integrated circuits (ICs), analog ICs, radio frequency integrated circuits (RFICs), mixed-signal ICs, application-specific integrated circuits (ASICs), printed circuit boards (PCBs), electronic devices, etc. The processor and transceiver can also be manufactured using various IC process technologies, such as complementary metal oxide semiconductors (CMOS), n-type metal-oxide-semiconductor (NMOS), p-type metal oxide semiconductors (PMOS), bipolar junction transistors (BJTs), bipolar CMOS (BiCMOS), silicon germanium (SiGe), gallium arsenide (GaAs), etc.

[0234] Optionally, the communication device can be a standalone device or part of a larger device. For example, the device could be:

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

[0236] (2) A collection of one or more ICs, optionally including a storage component for storing data and / or instructions;

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

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

[0239] (5) Receivers, terminals, cellular phones, wireless devices, handheld devices, mobile units, network devices, etc.

[0240] (6) Others, etc.

[0241] This application also provides a computer-readable storage medium storing a computer program that, when run on a computer, causes the computer to perform the communication method described in the above embodiments.

[0242] Furthermore, this application also provides a computer program product, which includes a computer program that, when run on a computer, causes the computer to execute the communication method described in the above embodiments.

[0243] In the above embodiments, implementation can be achieved, in whole or in part, through software, hardware, firmware, or any combination thereof. When implemented in software, it can be implemented, in whole or in part, as 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, all or part of the processes or functions described in this application are generated. 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. For example, the computer instructions can be transmitted from one website, computer, server, or data center to another website, computer, server, or data center via wired (e.g., coaxial cable, fiber optic, digital subscriber line) or wireless (e.g., infrared, wireless, microwave, etc.) means. The computer-readable storage medium can be any available medium accessible to a computer or a data storage device such as a server or data center that integrates one or more available media. The available medium can be a magnetic medium (e.g., floppy disk, hard disk, magnetic tape), an optical medium (e.g., DVD), or a semiconductor medium (e.g., solid-state drive).

Claims

1. A key update method, characterized in that, The method, applied to a Bluetooth Mesh network comprising at least two network nodes, wherein a configuration node is one of the network nodes in the Bluetooth Mesh network, and the configuration node is used to configure the network key of the Bluetooth Mesh network, includes: The configuration node responds to the second message sent by the first network node, determines the first network node from the network nodes of the Bluetooth Mesh network, the network key maintained locally 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 the synchronization of the network key, and the first network node is a node that is not in the network key update blacklist and has not successfully sent the first notification during the network key update process; The configuration node uses the device key of the first network node to encrypt the first network key to obtain the first ciphertext; The configuration node sends a first message to enable the first network node to obtain the first network key, the first message carrying the first ciphertext.

2. The method according to claim 1, characterized in that, The configuration node responds to the second message from the first network node by determining 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-powered 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 the identifier of the first network node.

5. A key update method, characterized in that, The method is applied to a Bluetooth Mesh network, wherein the Bluetooth Mesh network includes at least two network nodes, a configuration node is one of the network nodes 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. The method includes: The first network node sends a second message to the configuration node, the second message being used to request the synchronization of the network key, wherein the first network node is a node that is not on the network key update blacklist and has not successfully sent the first notification during the network key update process; The first network node receives a first message from the configuration node. The first message carries a first ciphertext, which 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 maintained locally by the first network node is inconsistent with the first network key. The first network node uses its device key to decrypt the first ciphertext and obtain the first network key. The first network node updates the locally maintained network key to the first network key.

6. The method according to claim 5, characterized in that, The method further includes: The first network node sends a third message to the configuration node, the third message indicating 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 sends a second message to the configuration node, including: When the first network node switches from a dormant state to a wake-up state, the first network node sends a fourth message to the second network node; wherein, the second network node and the first network node have established a friend relationship, 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 retrieve the messages 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 is received from the second network node, the first network node broadcasts a fifth message, which is used to request the establishment of a friend 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-executed instructions; The at least one processor executes the computer execution instructions, causing the network device to perform the method as described in any one of claims 1-7.

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

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer-executable instructions, which, when executed by a processor, implement the method as described in any one of claims 1-7.

11. A computer program product, characterized in that, The computer program product includes a computer program that, when run on a computer, causes the computer to perform the method as described in any one of claims 1-7.

Images