Secure Path Discovery in Mesh Networks

Abstract

A method for performing secure path discovery in a mesh network at a destination device is disclosed. The method includes receiving a path discovery request from an originator device and selecting a path selection in response to the path discovery request. The method also includes transmitting the path selection to the originator device and receiving a random seed from a provisioner device. The method also includes generating an authentication code based on the random seed, transmitting an authentication code message to the originator device, and receiving a communication from the originator device only when the originator device receives an authentication response message from the provisioner device confirming that the destination device has been authenticated.

Description

[0001] Priority claim

[0002] This patent application claims priority to Indian Application No. 201941031298, filed on August 2, 2019, entitled “SECURE PATH DISCOVERY IN AMESH NETWORK”, and Non-Provisional Application No. 16 / 946,635, filed on June 30, 2020, entitled “SECURE PATH DISCOVERY IN A MESH NETWORK”, and the above applications are assigned to the assignee of this application and are hereby incorporated by reference. Technical Field

[0003] Various aspects described herein relate generally to wireless communications and, more particularly, to secure path discovery in mesh networks.

[0004] background

[0005] All wireless networking technologies generally have limited range. However, there are many environments where devices that are otherwise out of communication range of each other may need to communicate using reliable low-power wireless technologies. For example, the Internet of Things (IoT) is based on the idea that everyday devices can be read, identified, located, addressed, and otherwise controlled via an IoT communication network (e.g., an ad hoc system or the Internet).

[0006] One way to address the problem that arises when devices are outside of each other's maximum communication range is to implement a mesh network, which has a topology in which all devices can communicate with each other, either directly or indirectly. For example, two devices that are within radio range can communicate directly, while communication with devices that are outside of each other's radio range can be achieved via one or more intermediate "relay" nodes. Thus, a mesh network can provide multiple paths to route messages from an originator node to a destination node, resulting in higher reliability relative to other networks that tend to have all traffic flow through a central hub (e.g., a router or gateway).

[0007] A wireless mesh network may generally refer to a network in which various devices or "nodes" have the ability to receive and act on messages in addition to the ability to repeat or relay messages to surrounding devices or nodes within radio range. Therefore, the mesh architecture can extend the effective radio range associated with any wireless technology used to convey messages, and can thus be used to implement IoT and other suitable use cases that are at least partially based on wireless communications. The efficiency and security of mesh networks can be improved by using directional forwarding, which enables the originator node to convey information to a specific destination node. Accordingly, it is necessary to ensure that communications between nodes are not attacked by third-party attackers.

[0008] Overview

[0009] A simplified overview of one or more aspects disclosed herein is given below. As such, the following overview should neither be considered an exhaustive overview of all contemplated aspects, nor should the following overview be considered to identify key or decisive elements related to all contemplated aspects or to delineate the scope associated with any particular aspect. Accordingly, the sole purpose of the following overview is to present certain concepts related to one or more aspects of the mechanisms disclosed herein in a simplified form prior to the detailed description given below.

[0010] In one aspect of the present disclosure, a method for performing secure path discovery in a mesh network at a destination device is described. The method includes receiving a path discovery request from an originator device and selecting a path selection in response to the path discovery request. The method also includes transmitting the path selection to the originator device and receiving a random seed from a provisioner device. The method also includes generating an authentication code based on the random seed and transmitting the authentication code message to the originator device. The method also includes receiving a communication from the originator device only when the originator device receives a verification response message from the provisioner device confirming that the destination device has been verified. The destination device can increment the random seed at each new secure path discovery. In one example, the random seed is 4 octets.

[0011] When the provisioning device determines that a large portion of the random seed sequence has been used, the provisioning device can send a customized configuration message including a new random seed to the destination device. The provisioning device can update the random seed for at least one device on a periodic basis. The provisioning device can send a new random seed to the device based on a request from the device.

[0012] In one implementation, the destination device generates an authentication code by generating an encrypted hash value based on a random seed, a device key of the destination device, and a payload. The authentication code message includes an authentication code, AuthMic (authentication message integrity check), and a destination device unicast address. In one example, the authentication code is 4 octets.

[0013] In one implementation, the provisioner device performs verification by decrypting the value of the authentication code and determining whether the value of AuthMic sent by the destination device matches the value of AuthMic generated by the provisioner device. If the verification response message confirms that the destination device has failed verification, the originator device blocks the destination device from receiving any communications. The originator device reports to the provisioner device that the destination device is a third-party attacker.

[0014] In another aspect of the present disclosure, a destination device for performing secure path discovery in a mesh network is described. The destination device includes a memory and at least one processor coupled to the memory, the at least one processor being configured to: receive a path discovery request from an originator device and select a path selection in response to the path discovery request. The destination device transmits the path selection to the originator device and receives a random seed from the provisioner device. The destination device generates an authentication code based on the random seed; and transmits the authentication code message to the originator device. The destination device receives communications from the originator device only when the originator device receives a verification response message from the provisioner device confirming that the destination device has been verified.

[0015] In another aspect of the present disclosure, a destination device for performing secure path discovery in a mesh network is described. The destination device includes means for receiving a path discovery request from an originator device and means for selecting a path selection in response to the path discovery request. The destination device also includes means for transmitting the path selection to the originator device and means for receiving a random seed from a provisioner device. The destination device also includes means for generating an authentication code based on the random seed and means for transmitting the authentication code message to the originator device. The destination device also includes means for receiving communications from the originator device only when the originator device receives a verification response message from the provisioner device confirming that the destination device has been verified.

[0016] In another aspect of the present disclosure, a non-transitory computer-readable medium storing code for performing secure path discovery at a destination device is described. The code includes instructions executable by a processor to: receive a path discovery request from an originator device, select a path selection in response to the path discovery request, transmit the path selection to the originator device, receive a random seed from a provisioner device, generate an authentication code based on the random seed, transmit the authentication code message to the originator device, and receive a communication from the originator device only if the originator device receives an authentication response message from the provisioner device confirming that the destination device has been authenticated.

[0017] In one aspect of the present disclosure, a method for secure path discovery in a mesh network at an originator device is described. The method includes sending a path discovery request to a destination device and receiving a path selection from the destination device. The method also includes receiving an authentication code message from the destination device and transmitting a verification request message to a provisioner device. The method also includes receiving a verification response message from the provisioner device and sending a communication to the destination device only if the verification response message from the provisioner device confirms that the destination device has been verified.

[0018] The authentication code message includes an authentication code, AuthMic (authentication message integrity check), and a destination device unicast address. In one implementation, the destination device generates an authentication code by generating an encrypted hash value based on a random seed, a device key of the destination device, and a payload. In one implementation, the provisioning device performs verification by decrypting the value of the authentication code and determining whether the value of AuthMic sent by the destination device matches the value of AuthMic generated by the provisioning device. If the verification response message confirms that the destination device has failed verification, the originating device blocks the destination device from receiving any communications. The originating device reports to the provisioning device that the destination device is a third-party attacker.

[0019] In another aspect of the present disclosure, an initiator device for performing secure path discovery in a mesh network is described. The initiator device includes a memory and at least one processor coupled to the memory, the at least one processor configured to: send a path discovery request to a destination device, receive a path selection from the destination device, receive an authentication code message from the destination device, transmit a verification request message to a provisioner device, receive a verification response message from the provisioner device, and send a communication to the destination device only if the verification response message from the provisioner device confirms that the destination device has been verified.

[0020] In another aspect of the present disclosure, an originator device for performing secure path discovery in a mesh network is described. The originator device includes means for sending a path discovery request to a destination device and means for receiving a path selection from the destination device. The originator device also includes means for receiving an authentication code message from the destination device and means for transmitting a verification request message to a provisioner device. The originator device also includes means for receiving a verification response message from the provisioner device and means for sending a communication to the destination device only if the verification response message from the provisioner device confirms that the destination device has been verified.

[0021] In another aspect of the present disclosure, a non-transitory computer-readable medium storing code for performing secure path discovery at an originator device is described. The code includes instructions executable by a processor to perform the following operations: sending a path discovery request to a destination device, receiving a path selection from the destination device, receiving an authentication code message from the destination device, transmitting a verification request message to a provisioner device, receiving a verification response message from the provisioner device, and sending a communication to the destination device only if the verification response message from the provisioner device confirms that the destination device has been verified. BRIEF DESCRIPTION OF THE DRAWINGS

[0023] The accompanying drawings are presented to aid in describing various aspects of the disclosure and are provided solely for the purpose of illustrating these aspects and not limiting thereof.

[0024] Figure 1 is a block diagram illustrating one configuration of a wireless mesh network.

[0025] Figure 2 is a block diagram illustrating one configuration of a wireless mesh network implemented in an example residential environment.

[0026] Figure 3 is a block diagram illustrating one configuration of a node capable of operating within a wireless mesh network.

[0027] Figure 4 is a block diagram illustrating a controller (acting as a provisioner device) provisioning an unprovisioned device in a wireless mesh network.

[0028] Figure 5 is a block diagram illustrating one configuration of path discovery using directed forwarding.

[0029] Figure 6 is a block diagram illustrating one configuration of secure path discovery using directed forwarding.

[0030] Figure 7 is a flow chart illustrating a method of performing secure path discovery in a mesh network at a destination node.

[0031] Figure 8 is a flow chart illustrating a method of performing secure path discovery in a mesh network at an originator node.

[0032] Detailed Description

[0033] Various aspects of the present disclosure are provided in the following description and related drawings for various examples provided for illustrative purposes. Alternative aspects may be designed without departing from the scope of the present disclosure. In addition, well-known aspects of the present disclosure may not be described in detail or may be omitted to avoid obscuring more relevant details.

[0034] The terms used herein only describe specific aspects and should not be interpreted as limiting any aspect disclosed herein. As used herein, the singular forms of "one", "some" and "the" are intended to also include plural forms, unless the context clearly indicates otherwise. Those skilled in the art will further understand that the terms "include", "have", "include" and / or "contain" as used herein specify the existence of stated features, integers, steps, operations, elements, and / or components, but do not exclude the existence or addition of one or more other features, integers, steps, operations, elements, components and / or their groups.

[0035] In addition, various aspects can be described in the form of a sequence of actions performed by, for example, an element of a computing device. Those skilled in the art will recognize that the various actions described herein can be performed by a dedicated circuit (e.g., an application specific integrated circuit (ASIC)), by a program instruction being executed by one or more processors, or by a combination of the two. Additionally, these action sequences described herein can be considered to be fully implemented in any form of non-transient computer-readable medium, which stores a corresponding computer instruction set that will cause the associated processor to perform the functionality described herein upon execution. Thus, various aspects described herein can be implemented in several different forms, all of which have been conceived to fall within the scope of the subject matter claimed for protection. In addition, for each aspect described herein, the corresponding form of any such aspect can be described herein as, for example, "logic configured to perform the described actions" and / or other structural components configured to perform the described actions.

[0036] As used herein, the term "node" refers to a mobile or stationary device that is a member of a wireless mesh network. A node may be a cellular phone, a "smart phone", a personal or mobile multimedia player, a personal data assistant, a laptop, a desktop computer, a tablet computer, a wireless game controller, an IoT device (e.g., a "smart" thermostat, a refrigerator, a microwave oven, a speaker system, a meter, etc.), and a device having a programmable processor, a memory, and a device for connecting to and communicating on a radio access network (RAN) implementing a specific radio access technology (RAT), for connecting to and communicating on a wireless local area network (WLAN) (e.g., based on IEEE 802.11, etc.), and / or for communicating via a device-to-device (D2D) direct connection or a peer-to-peer (P2P) connection (e.g., A similar device that is connected to and communicates with other devices through a circuit system.

[0037] The efficiency of a mesh network can be improved by using directional forwarding, which enables the originator node to communicate information to a specific destination node. When directional forwarding is implemented in a mesh network, the originator node uses a path discovery technique to determine the best path for communicating with the destination node. Path discovery generally involves the originator node sending a path discovery message to all nodes (called intermediate nodes) between the originator node and the destination node. These nodes respond to the originator node with specific information, which the originator node can use to determine which communication path is the most efficient for communicating with the destination node. The problem with path discovery is that the node is vulnerable to attacks by third-party attackers who use man-in-the-middle, spoofing, and interference attacks to intercept communications. Accordingly, there is a need for performing secure path discovery in a mesh network.

[0038] Figure 1 1 is a block diagram illustrating a configuration of a wireless mesh network. An exemplary wireless mesh network 100 may include various nodes 102, which may be optionally organized into a group 104 in communication via a network "cloud" 114 (e.g., the Internet), a controller 106 (e.g., a mobile device), a gateway 112, and a configuration infrastructure 116. Although the controller 106 and the gateway 112 are shown as separate elements from the node 102, the controller 106 and / or the gateway 112 may be included in the node 102. In general, the node 102 may be a basic building block of the wireless mesh network 100. The node 102 may be any suitable device that can be configured to send, receive, and relay messages to surrounding nodes 102 (i.e., devices). The message communication between the nodes 102 may generally be based on broadcast messages, which may be transmitted via one or more wireless channels.

[0039] The controller 106 (which may also be referred to as a provisioner device) may be configured to establish a wireless connection 108 with the node 102. The controller 106 may use a wireless radio to communicate with the node 102 in the wireless mesh network 100. The controller 106 may have an additional communication path 110 to the wireless mesh network 100. For example, the controller 106 may use a configuration application to communicate with a configuration infrastructure 116 via the additional communication path 110 (e.g., via a web console or service). The configuration infrastructure 116 may service configuration commands received from the controller 106 (e.g., to securely distribute network keys to new nodes 102, to program a particular node 102 to be within a group 104 or another group, etc.). A gateway 112 (e.g., an access point) may link the various nodes 102 to the network 114 and allow command and control on a local area network (LAN) or wireless LAN (WLAN) to which the gateway 112 is connected. Like other elements in the wireless mesh network 100, the gateway 112 may also communicate with the various nodes 102 via wireless channels using wireless radios. The wireless mesh network 100 may enable the nodes 102 to send, receive, and / or relay messages (e.g., command and control operations) that may originate from one or more of the nodes 102 and / or be received from the gateway 112 via the wireless connection 108 from the controller 106 or via an additional communication path 110 between the controller 106 and the various nodes 102.

[0040] The nodes 102, controllers 106, and gateways 112 may be configured to communicate with each other via a wireless mesh protocol, which generally enables devices to send, receive, and relay messages to / from surrounding devices within radio range, thereby forming an ad-hoc mesh network. For example, message communication may be based on broadcast messages transmitted and received via one or more wireless channels (e.g., Bluetooth broadcast channels), where each node 102 receiving the broadcast message may accept the message and forward the message to other nodes 102 within radio range. In this way, the range over which each node 102 can communicate may be easily extended, as one or more intermediate nodes 102 may be used to relay messages to another node 102 that is originally outside the radio range of the originating node 102. The wireless mesh protocol may enable the wireless mesh network 100 to be easily expanded to accommodate new devices, which may also increase the geographic coverage of the wireless mesh network 100 depending on device placement. Wireless mesh protocols may be used to support a variety of different use cases based at least in part on point-to-point, point-to-multipoint, and / or other suitable wireless communications.

[0041] Figure 2 is a block diagram illustrating one configuration of a wireless mesh network implemented in an example residential environment. Figure 2In the environment 200 shown in FIG. 1 , a wireless mesh network supports a home automation or IoT use case, where home appliances, lights, electrical switches, thermostats, etc. can form a wireless mesh network and be controlled via a wireless mesh protocol directly using one or more user devices or indirectly via a gateway device in communication with the one or more user devices (e.g., a smartphone, laptop, etc.). For example, Figure 2 The residential environment 200 shown in FIG. 1 includes a smart phone 202 (which may correspond to the controller 106), outdoor speakers 204 and 206, bedroom speakers 208 and 212, a thermostat 210, a washing machine 214, a clock 216, a refrigerator 218, a coffee maker 220, a kitchen speaker 222, living room speakers 224 and 230, a television 228, an electronic lock 232, and a home gateway device 226 (which may correspond to the home gateway device 226). Figure 1 206 ). Various devices can communicate with other devices within sufficient range (e.g., via broadcast messages), and can receive and relay messages appropriately to ensure that the message reaches the intended destination. For example, a user can press a button on the smartphone 202 to engage the electronic lock 232 that is outside the radio range of the smartphone 202. However, the smartphone 202 is within the radio range of the outdoor speakers 204 and 206, the clock 216, and the refrigerator 218. The smartphone 202 can broadcast a message containing a command to engage the electronic lock 232. The outdoor speakers 204 and 206, the clock 216, and the refrigerator 218 can each relay the message until the message eventually reaches the electronic lock 232.

[0042] Bluetooth mesh uses four types of nodes, including: relay nodes, low power nodes (LPNs), proxy nodes, and friend nodes. Relay nodes receive and forward messages across the mesh network. Relay nodes generally remain in active or awake mode, which significantly increases power consumption. This is not disadvantageous for standard power supply applications (wherein the node is hardwired or plugged into a power source connected to the power grid (such as wall power, AC power, household power)) (such as smart lighting). This is a problem for battery-powered nodes (such as switches incorporated into mesh networks). Due to their application, relay nodes generally operate on standard power supplies (i.e., non-battery power).

[0043] LPNs use the general power saving features of BLE (e.g., remaining in a sleep state for longer periods of time), and can therefore operate on battery power for longer periods of time. Each LPN is connected to a standard powered Friend Node, which remains in an active or awake mode and caches any messages directed to the LPN. When the LPN enters receive mode (according to a predetermined schedule), it polls the Friend Node for any messages stored in the Friend Node's cache. The Friend Node sends all cached messages (called response messages) to the LPN, which operates as instructed and then returns to a power saving sleep mode. A Friend Node can be a friend with multiple LPNs.

[0044] Proxy nodes can allow legacy devices to operate on a mesh network. For example, in the case where a consumer wants to use an old smartphone to control smart lighting via a mesh network. The proxy node will generally be a legacy implementation that does not support sending announcement packets through any profile. The proxy node will have Generic Attribute Profile (GATT) connection support. This GATT bearer exists for legacy devices. Proxy nodes that only support GATT will create a proxy connection with a proxy server. The proxy server supports both GATT and announcement bearers. When the proxy node wants to send a communication to other nodes, the proxy node sends the communication to the proxy server on the GATT bearer. The proxy server will relay the communication on the announcement bearer and the GATT bearer to other nodes.

[0045] Reference Figure 2 , (battery powered) thermostat 210 may be an example of an LPN, while (if standard powered) bedroom speaker 212 and / or television 228 may be examples of friend nodes. In another example, (battery powered) clock 216 may be an LPN, while (standard powered) refrigerator 218 may be a friend node. In another example, refrigerator 218, television 228, and washing machine 214 may be relay nodes, for example, because they are all standard powered. Outdoor speakers 204 and 206, bedroom speaker 212, and living room speaker 250 may also be relay nodes, even though they are not standard powered. Each node in a wireless mesh network (e.g., wireless mesh network 100) has its own device key (a unique device-specific private key, referred to as a "DevKey" in Bluetooth mesh) known only to itself and the provisioning device.

[0046] Each node in a wireless mesh network shares a network key (a network-specific public key, called the "NetKey" in Bluetooth mesh). Before a new node can participate in routine mesh operations, it is "provisioned" (i.e., onboarded to the mesh network) by a provisioner device through a process called "provisioning." A provisioner device is a trusted device that has access to all nodes in the mesh network. For example, a provisioner device can be Figure 1 The controller 106 in the . The new node is assigned an address (eg, an Internet Protocol (IP) address) along with a network key and a device key. After provisioning, the device key is used to establish a secure channel with the provisioning party device to configure the new node.

[0047] Provisioning is generally done using an application installed on a provisioner device (e.g., controller 106). The Bluetooth mesh provisioning procedure uses the Elliptic Curve Diffie-Hellman (ECDH) key agreement protocol and 256-bit Elliptic Curve Cryptography (ECC) public-private key exchange to distribute provisioning data. ECDH is an anonymous key agreement protocol that allows two parties, each with an ECC public-private key pair, to establish a shared secret over an insecure channel. The purpose of ECDH in Bluetooth mesh provisioning is to allow a secure link to be created between a provisioner device and an unprovisioned device. It uses public and private keys to distribute a symmetric secret key, which can then be used by the two devices to encrypt and decrypt subsequent messages.

[0048] The provisioning procedure is designed to accomplish two tasks. The first task is to authenticate an unprovisioned device. For example, in a Bluetooth mesh network, there may be a few, dozens, or hundreds of devices in a small space. Authentication is performed to ensure that the device the provisioner device is interacting with is the device the user wants to provision. The second task is to establish a secure link with the unprovisioned device to share information with it. At the end of the process, the unprovisioned device becomes a node in the Bluetooth mesh network.

[0049] Figure 3 3 is a block diagram illustrating one configuration of a node 102 capable of operating within a wireless mesh network. The processor 302 of the node 102 runs an application that enables the node 102 to perform the functionality described in the present disclosure, and includes a cache memory 304 along with a system memory hierarchy 308. The system memory hierarchy 308 acts as an interface for storing and retrieving data and instructions from off-chip memory. The system memory hierarchy 308 may include various volatile and non-volatile memory systems.

[0050] The node 102 is capable of interfacing with a wireless local area network via a transceiver 320 and an antenna 322. The transceiver 320 includes a modem 320A and a digital signal processor (DSP) 320B, although other types of modules may be employed in practice, all or some such modules may be integrated on a single chip, and some modules may be integrated with the processor 302. In one implementation, the node 102 has a WLAN link 332 to a gateway 112, which may provide access to a network 114 (not shown).

[0051] Processor 302 may implement a low-power, short-range wireless network protocol stack 306, such as a Bluetooth Low Energy (BLE) protocol stack or a Bluetooth mesh protocol stack. Instructions for executing part or all of the low-power, short-range wireless network protocol stack 306 are stored in system memory hierarchy 308. However, in Figure 3 In the example of , a separate chip or embedded hardware core (shown as a low energy short range wireless network processor 324) implements portions of the low energy short range wireless network protocol stack 306 to perform low energy short range wireless network operations. The low energy short range wireless network processor 324 includes a memory 326 (shown as on-chip memory), although the memory 326 may be part of a memory hierarchy in which some of the memory also resides off-chip. A wireless interface 328 provides an interface to an antenna 330 that is suitable for operating in a designated spectrum utilized by a low energy short range wireless network. Communication may be performed with any number of devices having low energy short range wireless network capabilities, such as one or more other nodes 102. Instructions for implementing some or all of the low energy short range wireless network operations described in the present disclosure may be stored in the memory 326. The memory 326 may be referred to as a non-transitory computer readable medium.

[0052] Node 102 includes both a transceiver 320 that permits node 102 to act as an access terminal to gateway 112, and a low energy, short range wireless network processor 324 and a wireless interface 328 that together permit node 102 to act as a low energy mesh network node in a low energy mesh network, such as wireless mesh network 100. For example, node 102 may receive information for another node 102 from gateway 112 via transceiver 320. Node 102 may establish a connection with all downlink nodes 102 and transmit the information in one or more data packets to the downlink nodes 102 using low energy, short range wireless network processor 324 and wireless interface 328.

[0053] The node 102 may optionally include a user interface. The node 102 may include a CODEC (coder-decoder) 310 for interfacing with a microphone 312 and a speaker 314. A display controller 316 provides an interface to a display 318 so that a user can interact with the node 102.

[0054] In one implementation, as directed by instructions stored in the memory 326, the low energy short range wireless network processor 324 can cause the node 102 to perform various operations in the present disclosure. For example, the low energy short range wireless network processor 324, the memory 326, and the wireless interface 328 can all be used in a collaborative manner to load, store, and execute various operations, thereby allowing the logic for performing these operations to be distributed across various elements. In another example, the functionality can be incorporated into a discrete component (e.g., the low energy short range wireless network processor 324).

[0055] The nodes 102 in a mesh network (e.g., wireless mesh network 100) can communicate with each other using various wireless communication protocols (such as Zigbee, Thread, Bluetooth, Bluetooth low energy, magnetic communication, near field communication (NFC), near field magnetic induction (NFMI) communication, near ultra low energy field (NULEF) communication, Wi-Fi (802.11), and related wireless communication protocols). The Bluetooth protocol used for mesh networks is called "Bluetooth mesh" and is described in various publicly available specifications from the Bluetooth Special Interest Group (SIG). Bluetooth mesh is built on the Bluetooth Low Energy (BLE) protocol, which is described in various publicly available specifications from the Bluetooth SIG.

[0056] Figure 4 1 is a block diagram illustrating controller 106 (acting as a provisioner device) provisioning an unprovisioned device 410 in wireless mesh network 100. Device 410 Figure 1 Controller 106 and device 410 may also be referred to as node 102. Controller 106 and device 410 may communicate with each other using their respective low energy short range wireless network processor 324 and wireless interface 328 according to the Bluetooth mesh protocol.

[0057] At 402, device 410 indicates its availability to be provisioned by transmitting an unprovisioned device beacon in one or more announcement packets. A user may need to initiate device 410 to announce in this manner by, for example, pressing a combination of buttons on device 410 or holding a button pressed for a certain length of time on device 410. The beacon message may include a universally unique identifier (UUID) of device 410.

[0058] At 404, the controller 106 sends an invitation to the device 410 in the form of a provisioning invitation protocol data unit (PDU). At 406, the device 410 responds with information about itself in a provisioning capability PDU. The provisioning capability PDU may include the number of elements supported by the device 410, the set of security algorithms supported (e.g., ECDH), the availability of its public key using an out-of-band (OOB) method, the ability of the device 410 to output values ​​to the user (e.g., display LEDs, speakers, etc.), and / or the ability of the device 410 to receive user input values ​​(e.g., touch screens, buttons, microphones, etc.). In a Bluetooth mesh, the device 410 may support more than one element. An element is an entity that has a unicast address through which other devices in the mesh network can communicate. For example, a four-switch expansion board with mesh capabilities will have four elements indicating four different switches. In another example, one element of the device 410 may support turning a light on or off, while another element may support changing the color of the light.

[0059] At 408, controller 106 sends a Provisioning Start PDU to device 410, which indicates to device 410 that controller 106 is not aware of the public key of device 410. At 412 and 414, controller 106 and device 410 exchange their public keys either directly (e.g., through their Bluetooth connection) or using an out-of-band method (e.g., device 410 flashes its LED a certain number of times and the user enters that number into a user interface of controller 106). At 416, controller 106 sends a Provisioning Confirm Provisioner PDU to device 410, and at 418, device 410 sends a Provisioning Confirm Device PDU to controller 106, which confirms that each device has received the other's public key.

[0060] At 420, the controller 106 outputs the random single-digit or multi-digit number to the user in some form, such as by displaying it on the touch screen of the controller 106. At 422, the device 410 also outputs the random single-digit or multi-digit number to the user in some form, using an action appropriate to its capabilities. For example, it may flash its LED the number of times that random number, or emit a beep that number of times. The user inputs the number(s) output by the controller 106 and the device 410 into the device 410 and the controller 106, respectively, and a cryptographic exchange involving the random number occurs between the two devices to complete the authentication of each of the two devices to each other.

[0061] After authentication has been successfully completed, the session key is derived from the ECDH shared secret by each of the two devices based on its private key (e.g., "DevKey" in Bluetooth mesh) and the exchanged public key. More specifically, both the controller 106 and the device 410 use their own public key (exchanged at 412 and 414) and private key pairs to calculate the ECDH shared secret. The ECDH algorithm is used by each device to securely calculate the session key by exchanging public keys, using the public keys to calculate the ECDH shared secret, and then generating the session key from the common ECDH secret.

[0062] At 424, controller 106 uses the session key to encrypt subsequent distribution of data used to complete the provisioning process, including a network key (e.g., a "NetKey" in Bluetooth mesh) that is transmitted to device 410 in a Provisioning Data PDU. At 426, upon receiving the Provisioning Data PDU, device 410 sends a Provisioning Complete PDU to controller 106 to complete the provisioning process. After provisioning has been completed, provisioned device 410 possesses the network key (NetKey) of the mesh network, mesh security parameters known as IV indexes, and a unicast address for device 410 assigned by controller 106. It is now referred to as a "node" in a mesh network, such as node 102 in wireless mesh network 100.

[0063] Figure 5 5 is a block diagram illustrating a configuration of path discovery using directed forwarding. In this configuration, originator node A 502 wants to communicate with node D 508, but does not know the available communication paths. For example, one communication path can be originator node A 502 to node B 504 to node C 506 to destination node D 508, while another communication path can be originator node A 502 to node E 510 to node F 512 to node G 514 to destination node D 508.

[0064] The originator node A 502 broadcasts a PREQ message including certain information fields to all intermediate nodes including node B 504, node C 506, node E 510, node F 512 and node G 514 via the intermediate nodes. The PREQ is sent on a fixed group address of all DF nodes (ALL DF NODES) (0xFFFB). The PREQ message may include any type of information field, size, format, information type and related fields. In one example, the PREQ message may include, but is not limited to, the information fields in the PREQ message format table listed below.

[0065] PREQ Message Format

[0066]

[0067] The intermediate nodes including node B 504, node C 506, node E 510, node F 512 and node G 514 receive the PREQ message. If any of the intermediate nodes supports the path metric POPMT field in the PREQ message, the intermediate node can process the PREQ message and forward it to another intermediate node. For example, the originator node A 502 sends a PREQ message 518 to node B 504. Node B 504 sends the same PREQ message 522 to node C 506. Node C 506 sends the same PREQ message 526 to destination node D 508. In another example, the originator node A 502 sends a PREQ message 516 to node E 510. Node E 510 sends the same PREQ message 520 to node F 512. Node F 512 sends the same PREQ message 524 to destination node G 514. Node G 514 sends the same PREQ message 528 to destination node D 508 .

[0068] After the intermediate node forwards the PREQ message, the intermediate node can store the content of the forwarded PREQ message in a discovery table (DT) in its own memory. The intermediate node can store the PREQ message in the discovery table so that the intermediate node can use the same entry in the table when it receives a related PREP message.

[0069] When destination node D 508 receives PREQ message 526, destination node D 508 can evaluate which PREQ message is the most efficient by evaluating the path metric field POPMT in each message, which is called the hop count. For example, all PREQ messages include the following hop counts: PREQ (hop = 0) 516, PREQ (hop = 0) 518, PREQ (hop = 1) 520, PREQ (hop = 1) 522, PREQ (hop = 2) 524, PREQ (hop = 2) 526, PREQ (hop = 3) 528. The hop count is the number of intermediate node paths between originator node A 502 and destination node D 508. In this example, destination node D 508 will select the PREQ (hop = 2) 526 at node C 506 because this is the most efficient path for communicating with originator node A 502.

[0070] Destination node D 508 will send a PREP message 530 to the selected node C 506. Node C 506 will send the same PREP message 532 to node B 504. Node B 504 will then send the same PREP message 534 to originator node A 502. At this point, the path from originator node A 502 to destination node D 508 is built. PREP messages 530, 532, and 534 may include any type of information field, size, format, information type, and related fields. In one example, PREP messages 530, 532, and 534 may include, but are not limited to, the information fields in the PREP message format table listed below.

[0071] PREP Message Format

[0072]

[0073]

[0074] In this example, the intermediate nodes (including node B 504 and node C 506) that obtain the PREP messages 530 and 532 each create a path entry in their own forwarding table (FT), which is stored in their own memory. Later, when each node sends and / or forwards any message from the originator node A 502 to the destination node D 508, the path entry can be referenced by them.

[0075] Figure 6 is a block diagram illustrating a configuration of secure path discovery using directed forwarding. In this configuration, the path discovery process is similar to Figure 5 508, except that an authentication and verification process is added to ensure that the destination node D 508 is not a third-party attacker. The authentication and verification process ensures that the originator node A 502 has assurance that the communication path to the destination node D 508 is secure.

[0076] For ease of reference, node and path discovery messages use the same Figure 5 The same reference numerals are used in the diagram because the underlying path discovery parts are the same. Figure 6As shown in , originator node A 502 wants to communicate with node D 508, and needs to determine the best communication path. Originator node A 502 sends a path discovery request to destination node D 508, so that destination node D 508 can select a path. In one implementation, originator node A 502 broadcasts a PREQ message including certain information fields to all intermediate nodes including node B 504, node C 506, node E 510, node F 512, and node G 514. The intermediate nodes will forward the same PREQ message (516, 518, 520, 522, 524, 526, 528) to each other, and end at destination node D 508. In one example, originator node A 502 will set the POPMT field to (0x02) in the PREQ messages 516 and 518 that it initially sends to node B 504 and node E 510. All intermediate nodes supporting that particular POPMT value will forward the PREQ message to the next node until destination node D 508 receives the PREQ message.

[0077] When destination node D 508 receives PREQ message 526, destination node D 508 can evaluate which PREQ message is the most efficient by evaluating the path metric field POPMT in each message, which is called the jump count. In this example, destination node D 508 will select the PREQ (jump = 2) 526 at node C 506 because this is the shortest path to communicate with originator node A 502. Destination node D 508 can select a path from one or more paths. Destination node D 508 can select a path based on various criteria, including but not limited to: network metrics, node metrics, node values, jump counts, POPMT values, PREQ message values, shortest paths, and related metrics and values.

[0078] The destination node D 508 will send the selected path to the originator node A 502. In one implementation, the destination node D 508 will send a PREP message 530 to the selected node C 506. Node C 506 will send the same PREP message 532 to the node B 504. Node B 504 will then send the same PREP message 534 to the originator node A 502. At this point, the path from the originator node A 502 to the destination node D 508 is established.

[0079] The originator node A 502 will wait to send a communication to the destination node D 508 until the originator node A 502 receives the authentication code message 612 from the destination node D 508 and the provisioner device 602 has authenticated the destination node D 508 .

[0080] Before destination node D 508 generates authentication code message 612, destination node D 508 may communicate with provisioner device 602. Destination node D 508 may communicate with provisioner device 602 at any time, including before the path discovery process. In one example, destination node D 508 has not yet been provisioned on the wireless mesh network. Destination node D 508 communicates with provisioner device 602 to receive the random seed during initial random exchange 604 and continue to perform the provisioning process. Figure 4 An example of the provisioning process is found in As part of the provisioning process, destination node D 508 communicates with provisioner device 602 to receive a random seed during an initial random exchange 604 .

[0081] The provisioning device 602 can use several different procedures to send and / or update the random seed to the destination node D 508 and / or other nodes at any time. In one example, the provisioning device 602 can update the random seed for at least one node on a periodic basis. In another example, the provisioning device 602 sends a new random seed to the node based on a request from the node. In another example, when the provisioning device 602 determines that a large part of the random seed sequence has been used, the provisioning device 602 sends a customized configuration message 604 including the new random seed to the destination node D 508. The random seed can have any form, including α, a numerical value or an α numerical value. In one example, the random seed is a one-time random number. The random seed can also have any length. In another example, the random seed is 4 octets (32 bits). In another example, the random seed can also be selected from 0-64K (LSB 16 bits) to ensure that the node has enough range to increment the random seed.

[0082] Once the destination node D 508 receives the random seed, the destination node D will increment the value of the random seed 606. In one example, the destination node D can increment the value of the random seed based on each new secure path discovery performed by the destination device D 508. Then, the destination node D 508 will generate an authentication code based on the random seed. The authentication code can be generated by several different techniques (including encrypted and unencrypted procedures). In one example, the authentication code can be generated by generating an encrypted hash value based on different values ​​(including but not limited to random seeds, device keys of the destination device, and payload). The authentication code can have any form, including α, numerical value, or α numerical value. The authentication code can have any length. In one example, the authentication code is 4 octets.

[0083] Destination node D 508 will generate an authentication code message 612 that may be encrypted or unencrypted to send to originator node A 502. Authentication code message 612 may include any type of information field, any type of format, and any length. In one example, authentication code message 612 includes authentication code, AuthMic (authentication message integrity check), and destination device unicast address. Destination node D 508 will send authentication code message 612 to node C 506. Node C 506 then forwards authentication code message 612 to node B 504. Node B 504 then forwards authentication code message 612 to originator node A 502.

[0084] Once the originator node A 502 receives the authentication code message 612, the originator node A 502 will send a verification request message 608 to the provisioner device 602 to request the provisioner device 602 to verify that the destination node D 508 is a properly provisioned node and can receive communications. The verification request message 608 can include any type of information field. In one example, the verification request message 608 will include all fields and information from the authentication code message 612, such as the authentication code, AuthMic, and the destination device unicast address.

[0085] The provisioner device 602 will perform verification of the destination node D 502. The provisioner device 602 may perform verification using different techniques, calculations, comparisons, thresholds, metrics, and / or any values ​​contained in the authentication code message 612. In one implementation, the provisioner device 602 may perform verification by decrypting the authentication code and determining whether the value of AuthMic sent by the destination node D 508 matches the value of AuthMic generated by the provisioner device 602. If the two AuthMic values ​​match, the destination node D 502 is verified. If the two AuthMic values ​​do not match, the destination node D 502 fails verification. In another implementation, the provisioner device 602 may perform verification by determining whether the value of AuthMic from the authentication code message 612 matches the value of AuthMic generated by the provisioner device 602.

[0086] If the destination node D 508 fails to pass the verification, the provisioner device 602 will send a verification response message 610 to the originator node A 502 confirming that the destination node D 508 failed to pass the verification. The originator node A 502 can then prevent the destination node D 508 from receiving any messages from other nodes. The provisioner device 602 can also prevent the destination node D 508 from receiving any messages from other nodes. At this point, the originator node A 502 can then report to the provisioner device 602 that the destination node D 508 is a third-party attacker.

[0087] If the destination node D 508 passes the verification, the provisioning party device 602 will send a verification response message 610 to the originator node A 502 confirming that the destination node D 508 has been verified. At this point, the originator node A 502 can send a communication to the destination node D 508. For example, the communication can include data, text, graphics, video, audio, messages, signals, data packets, and related forms of communication. In another implementation, the originator node A 502 can send a confirmation message to the destination node D 508, thereby confirming that the destination node D 508 has been verified. Once the destination node D 508 receives the verification response message 610, the originator node A 502 and the destination node D 508 can begin to send communications to each other.

[0088] Figure 7 is a flow chart illustrating a method for performing secure path discovery in a mesh network at a destination device. Figure 5 and Figure 6 , the method 700 may be implemented by the originator node A 502 , the destination node D 508 , the intermediate nodes (node ​​B 504 , node C 506 , node E 510 , node F 512 , and node G 514 ), and the provisioner device 602 .

[0089] At step 702, the destination device receives a path discovery request from the originator device. The operations of 702 may be performed according to the methods described herein. In some implementations, the operations of 702 may be implemented by the originator node A 502, the destination node D 508, the intermediate nodes (node ​​B 504, node C 506, node E 510, node F 512, and node G 514), and the provisioner device 602, as shown in FIG. Figure 5 and Figure 6 Described.

[0090] At step 704, the destination device selects a path selection in response to the path discovery request. The operation of 704 may be performed according to the methods described herein. In some implementations, the operation of 704 may be performed by the originator node A 502, the destination node D 508, the intermediate nodes (node ​​B 504, node C 506, node E 510, node F 512, and node G 514), and the provisioner device 602, as described in reference to FIG. Figure 5 and Figure 6 Described.

[0091] At step 706, the destination device transmits the path selection to the originator device.

[0092] The operation of 706 may be performed according to the methods described herein. In some implementations, the operation of 706 may be implemented by the originator node A 502, the destination node D 508, the intermediate nodes (node ​​B 504, node C 506, node E 510, node F 512, and node G 514), and the provisioner device 602, as shown in FIG. Figure 5 and Figure 6 Described.

[0093] At step 708, the destination device receives a random seed from the provisioner device. The operations at 708 may be performed according to the methods described herein. In some implementations, the operations at 708 may be performed by the originator node A 502, the destination node D 508, the intermediate nodes (node ​​B 504, node C 506, node E 510, node F 512, and node G 514), and the provisioner device 602, as described with reference to FIG. Figure 5 and Figure 6 Described.

[0094] At step 710, the destination device generates an authentication code based on the random seed. The operations of 710 may be performed according to the methods described herein. In some implementations, the operations of 710 may be performed by the originator node A 502, the destination node D 508, the intermediate nodes (node ​​B 504, node C 506, node E 510, node F 512, and node G 514), and the provisioner device 602, as described in reference to FIG. Figure 5 and Figure 6 Described.

[0095] At step 712, the destination device transmits an authentication code message to the originator device. The operations of 712 may be performed according to the methods described herein. In some implementations, the operations of 712 may be performed by the originator node A 502, the destination node D 508, the intermediate nodes (node ​​B 504, node C 506, node E 510, node F 512, and node G 514), and the provisioner device 602, as described in reference to FIG. Figure 5 and Figure 6 Described.

[0096] At step 714, the destination device receives the communication from the originator device only if the originator device receives a verification response message from the provisioner device confirming that the destination device has been verified. The operations of 714 may be performed according to the methods described herein. In some implementations, the operations of 714 may be performed by the originator node A 502, the destination node D 508, the intermediate nodes (node ​​B 504, node C 506, node E 510, node F 512, and node G 514), and the provisioner device 602, as described with reference to FIG. Figure 5 and Figure 6 Described.

[0097] Figure 8 is a flow chart illustrating a method for performing secure path discovery in a mesh network at an originator device. Figure 5 and Figure 6 , the method 800 may be implemented according to the methods described herein. In some implementations, the operations of 800 may be performed by the originator node A 502, the destination node D 508, the intermediate nodes (node ​​B 504, node C 506, node E 510, node F 512, and node G 514), and the provisioner device 602, as shown in FIG. Figure 5 and Figure 6 Described.

[0098] At step 802, the originator device sends a path discovery request to the destination device. The operations of 802 may be performed according to the methods described herein. In some implementations, the operations of 802 may be performed by the originator node A 502, the destination node D 508, the intermediate nodes (node ​​B 504, node C 506, node E 510, node F 512, and node G 514), and the provisioner device 602, as described in reference to FIG. Figure 5 and Figure 6 Described.

[0099] At step 804, the originator device receives a path selection from the destination device. The operations of 804 may be performed according to the methods described herein. In some implementations, the operations of 804 may be performed by the originator node A 502, the destination node D 508, the intermediate nodes (node ​​B 504, node C 506, node E 510, node F 512, and node G 514), and the provisioner device 602, as described with reference to FIG. Figure 5 and Figure 6 Described.

[0100] At step 806, the originator device receives the authentication code message from the destination device. The operations of 806 may be performed according to the methods described herein. In some implementations, the operations of 806 may be performed by the originator node A 502, the destination node D 508, the intermediate nodes (node ​​B 504, node C 506, node E 510, node F 512, and node G 514), and the provisioner device 602, as described in reference to FIG. Figure 5 and Figure 6 Described.

[0101] At step 808, the originator device sends a verification request message to the provisioner device. The operations of 808 may be performed according to the methods described herein. In some implementations, the operations of 808 may be performed by the originator node A 502, the destination node D 508, the intermediate nodes (node ​​B 504, node C 506, node E 510, node F 512, and node G 514), and the provisioner device 602, as described in reference to FIG. Figure 5 and Figure 6 Described.

[0102] At step 810, the originator device receives a verification response message from the provisioner device. The operations of 810 may be performed according to the methods described herein. In some implementations, the operations of 810 may be performed by the originator node A 502, the destination node D 508, the intermediate nodes (node ​​B 504, node C 506, node E 510, node F 512, and node G 514), and the provisioner device 602, as described in reference to FIG. Figure 5 and Figure 6 Described.

[0103] At step 812, the originator device sends the communication to the destination device only if the verification response message from the provisioner device confirms that the destination device has been verified. The operations of 812 may be performed according to the methods described herein. In some implementations, the operations of 812 may be performed by the originator node A 502, the destination node D 508, the intermediate nodes (node ​​B 504, node C 506, node E 510, node F 512, and node G 514), and the provisioner device 602, as described in reference to FIG. Figure 5 and Figure 6 Described.

[0104] It should be understood that any reference to an element, such as "first", "second", etc., is generally not limited to the number or order of these elements in this article. Specifically, these references can be used as a convenient method to distinguish two or more elements or element instances in this article. Therefore, the reference to the first element and the second element does not mean that only two elements can be adopted here or the first element must be located before the second element in some way. Moreover, unless otherwise stated, a group of elements may include one or more elements. In addition, the term "at least one of A, B, or C" or "one or more of A, B, or C" or "at least one of the group including A, B, and C" used in the specification or claim means "A or B or C or any combination of these elements". For example, this term can include A, or B, or C, or A and B, or A and C, or A and B and C, or 2A, or 2B, or 2C, etc.

[0105] In view of the above description and explanation, those skilled in the art will appreciate that the various illustrative logic blocks, modules, circuits, and algorithm steps described in conjunction with the aspects disclosed herein can be implemented as electronic hardware, computer software, or a combination of the two. To clearly illustrate this interchangeability of hardware and software, various illustrative components, blocks, modules, circuits, and steps are generally described above in terms of their functionality. Whether such functionality is implemented as hardware or software depends on the specific application and the design constraints imposed on the overall system. The technician can implement the described functionality in different ways for each specific application, but such implementation decisions should not be interpreted as causing a departure from the scope of the present disclosure.

[0106] Accordingly, it will be appreciated that, for example, a device or any component of a device may be configured (or made operable or adapted to) provide functionality as taught herein. This may be achieved, for example, by manufacturing (e.g., making) the device or component so that it will provide the functionality; by programming the device or component so that it will provide the functionality; or by using some other suitable implementation technique. As one example, an integrated circuit may be fabricated to provide the necessary functionality. As another example, an integrated circuit may be fabricated to support the necessary functionality and then (e.g., via programming) configured to provide the necessary functionality. As yet another example, a processor circuit may execute code for providing the necessary functionality.

[0107] In addition, the methods, sequences and / or algorithms described in conjunction with the aspects disclosed herein may be embodied directly in hardware, in a software module executed by a processor, or in a combination of the two. The software module may reside in a random access memory (RAM), a flash memory, a read-only memory (ROM), an erasable programmable ROM (EPROM), an electrically erasable programmable ROM (EEPROM), a register, a hard disk, a removable disk, a CD-ROM, or any other form of storage medium known in the art. The storage medium is coupled to the processor so that the processor can read and write information from / to the storage medium. In an alternative, the storage medium may be integrated into the processor (e.g., a cache).

[0108] Accordingly, it will also be appreciated that, for example, certain aspects of the present disclosure can include a computer-readable medium implementing a method for establishing an encrypted connection between a first node and a second node in a wireless mesh network.

[0109] Although the foregoing disclosure shows various illustrative aspects, it should be noted that various changes and modifications may be made to the illustrated examples without departing from the scope as defined in the appended claims. The present disclosure is not intended to be limited to only the specifically illustrated examples. For example, unless otherwise stated, the functions, steps, and / or actions in the method claims according to the various aspects of the present disclosure described herein need not be performed in any particular order. In addition, although certain aspects may be described or claimed in the singular, the plural is also contemplated unless it is explicitly stated to be limited to the singular.

Claims

1. A method for performing secure path discovery in a mesh network at a destination device, comprising: receiving a path discovery request from an originator device; selecting a path selection in response to the path discovery request; transmitting the path selection to the originator device; Receive a random seed from the provisioner device; generating an authentication code based on the random seed; Transmitting the authentication code message to the originator device; as well as Communications are received from the originator device only when the originator device receives an authentication response message from the provisioner device confirming that the destination device has been authenticated.

2. The method of claim 1, wherein: The random seed is incremented by the destination device upon each new secure path discovery.

3. The method of claim 1, wherein: The random seed is 4 octets.

4. The method of claim 1, wherein: The authentication code is 4 octets.

5. The method of claim 1, wherein: When the provisioner device determines that a substantial portion of the random seed sequence has been used, the provisioner device sends a custom configuration message including a new random seed to the destination device.

6. The method of claim 1, wherein: The provisioner device can update the random seed for at least one device on a periodic basis.

7. The method of claim 1, wherein: The provisioner device sends a new random seed to the device based on a request from the device.

8. The method of claim 1, wherein: Generating the authentication code includes generating an encrypted hash value based on the random seed, a device key of the destination device, and a payload.

9. The method of claim 1, wherein: The authentication code message includes the authentication code, an authentication message integrity check AuthMic, and a unicast address of the destination device.

10. The method of claim 9, wherein: The provisioner device performs verification by decrypting the value of the authentication code and determining whether the value of AuthMic sent by the destination device matches the value of AuthMic generated by the provisioner device.

11. The method of claim 1, wherein: If the authentication response message confirms that the destination device has failed authentication, the originator device blocks the destination device from receiving any communications.

12. The method of claim 11, wherein: The originator device reports to the provisioner device that the destination device is a third-party attacker.

13. A method for performing secure path discovery in a mesh network at an originator device, comprising: Sending a path discovery request to a destination device; receiving a path selection from the destination device; receiving an authentication code message from the destination device; Transmitting a verification request message to the provisioning party device; receiving a verification response message from the provisioner device; and Communications are sent to the destination device only if the authentication response message from the provisioner device confirms that the destination device has been authenticated.

14. The method of claim 13, wherein: The authentication code message includes an authentication code, an authentication message integrity check AuthMic and a unicast address of the destination device.

15. The method of claim 14, wherein: Generating the authentication code includes generating an encrypted hash value based on a random seed, a device key of the destination device, and a payload.

16. The method of claim 14, wherein: The provisioner device performs verification by decrypting the value of the authentication code and determining whether the value of AuthMic sent by the destination device matches the value of AuthMic generated by the provisioner device.

17. The method of claim 13, wherein: If the authentication response message confirms that the destination device has failed authentication, the originator device blocks the destination device from receiving any communications.

18. The method of claim 17, wherein: The originator device reports to the provisioner device that the destination device is a third-party attacker.

19. A destination device for performing secure path discovery in a mesh network, comprising: Memory; as well as at least one processor coupled to the memory and configured to: receiving a path discovery request from an originator device; selecting a path selection in response to the path discovery request; transmitting the path selection to the originator device; Receive a random seed from the provisioner device; generating an authentication code based on the random seed; Transmitting the authentication code message to the originator device; as well as Communications are received from the originator device only when the originator device receives an authentication response message from the provisioner device confirming that the destination device has been authenticated.

20. The destination device of claim 19, wherein: The random seed is incremented by the destination device upon each new secure path discovery.

21. The destination device of claim 19, wherein: The random seed is 4 octets.

22. The destination device of claim 19, wherein: The authentication code is 4 octets.

23. The destination device of claim 19, wherein: When the provisioner device determines that a substantial portion of the random seed sequence has been used, the provisioner device sends a custom configuration message including a new random seed to the destination device.

24. The destination device of claim 19, wherein: The provisioner device can update the random seed for at least one device on a periodic basis.

25. The destination device of claim 19, wherein: The provisioner device sends a new random seed to the device based on a request from the device.

26. The destination device of claim 19, wherein: Generating the authentication code includes generating an encrypted hash value based on the random seed, a device key of the destination device, and a payload.

27. The destination device of claim 19, wherein: The authentication code message includes the authentication code, an authentication message integrity check AuthMic and a unicast address of the destination device.

28. The destination device of claim 27, wherein: The provisioner device performs verification by decrypting the value of the authentication code and determining whether the value of AuthMic sent by the destination device matches the value of AuthMic generated by the provisioner device.

29. The destination device of claim 19, wherein: If the authentication response message confirms that the destination device has failed authentication, the originator device blocks the destination device from receiving any communications.

30. The destination device of claim 29, wherein: The originator device reports to the provisioner device that the destination device is a third-party attacker.

31. An initiator device for secure path discovery in a mesh network, comprising: Memory; as well as at least one processor coupled to the memory and configured to: Sending a path discovery request to a destination device; receiving a path selection from the destination device; receiving an authentication code message from the destination device; Transmitting a verification request message to the provisioning party device; receiving a verification response message from the provisioner device; and Communications are sent to the destination device only if the authentication response message from the provisioner device confirms that the destination device has been authenticated.

32. The originator device of claim 31, wherein: The authentication code message includes an authentication code, an authentication message integrity check AuthMic and a unicast address of the destination device.

33. The originator device of claim 31, wherein: Generating the authentication code includes generating an encrypted hash value based on a random seed, a device key of the destination device, and a payload.

34. The originator device of claim 32, wherein: The provisioner device performs verification by decrypting the value of the authentication code and determining whether the value of AuthMic sent by the destination device matches the value of AuthMic generated by the provisioner device.

35. The originator device of claim 31, wherein: If the authentication response message confirms that the destination device has failed authentication, the originator device blocks the destination device from receiving any communications.

36. The originator device of claim 35, wherein: The originator device reports to the provisioner device that the destination device is a third-party attacker.

37. A destination device for performing secure path discovery in a mesh network, comprising: means for receiving a path discovery request from an originator device; means for selecting a path selection in response to said path discovery request; means for transmitting said path selection to said originator device; means for receiving a random seed from a provisioner device; means for generating an authentication code based on the random seed; means for transmitting the authentication code message to the originator device; as well as Means for receiving a communication from the originator device only if the originator device receives an authentication response message from the provisioner device confirming that the destination device has been authenticated.

38. An initiator device for performing secure path discovery in a mesh network, comprising: means for sending a path discovery request to a destination device; means for receiving a path selection from said destination device; means for receiving an authentication code message from said destination device; means for transmitting a verification request message to a provisioner device; means for receiving a verification response message from the provisioner device; as well as Means for sending a communication to the destination device only if the authentication response message from the provisioner device confirms that the destination device has been authenticated.

39. A non-transitory computer-readable medium storing code for performing secure path discovery at a destination device, the code comprising instructions executable by a processor to: receiving a path discovery request from an originator device; selecting a path selection in response to the path discovery request; transmitting the path selection to the originator device; Receive a random seed from the provisioner device; generating an authentication code based on the random seed; Transmitting the authentication code message to the originator device; as well as Communications are received from the originator device only when the originator device receives an authentication response message from the provisioner device confirming that the destination device has been authenticated.

40. A non-transitory computer-readable medium storing code for performing secure path discovery at an originator device, the code comprising instructions executable by a processor to: Sending a path discovery request to a destination device; receiving a path selection from the destination device; receiving an authentication code message from the destination device; Transmitting a verification request message to the provisioning party device; receiving a verification response message from the provisioner device; and Communications are sent to the destination device only if the authentication response message from the provisioner device confirms that the destination device has been authenticated.

Images