Management of Devices in a
Bluetooth Mesh Network

Step 1. Beaconing

The Bluetooth Mesh network specification has introduced new GAP AD Types, including the <<Mesh Beacon>> AD Type[ii].

A device indicates its availability to be provisioned by using the <<Mesh Beacon>> AD type to advertise itself as an unprovisioned device. The user might need to start the new device advertising in this way by following a procedure described by the manufacturer, such as pressing a combination of buttons or holding down a button for a certain length of time.

The user will also start the “Add Device to Network” process within the provisioner, and this will cause it to receive the advertising packets from the beaconing device. Remember that the provisioner is likely to be a smartphone or tablet application, so in practical terms, this involves unlocking the smartphone, launching the application, perhaps logging into the app (for extra security) and employing its user interface to initiate looking for beaconing devices. In this way, the provisioner becomes aware of the new device and its readiness to go through the remainder of the provisioning process.

Step 2. Invitation

Next, the provisioner sends an invitation message to the device to be provisioned. The invitation takes the form of a provisioning Invite PDU, which is part of the provisioning protocol. The beaconing device responds with information about itself in a Provisioning Capabilities PDU.

The Provisioning Capabilities PDU provides information such as the number of elements it has and the provisioning-related algorithms it supports. It also indicates the types of input and output capabilities the device has, information which is used in the authentication step.

Step 3. Exchanging Public Keys

All Bluetooth^® Mesh devices, including the provisioner, support the FIPS P-256 Elliptic Curve Algorithm and therefore must have a public key. Asymmetric cryptography, based on this algorithm, is used to create a secure channel over which to perform the remainder of the provisioning process. To this end, the provisioner and device exchange their public keys. Note that the device may provide its public key via an out-of-band method, such as a QR code. We’ll focus on mesh security, including provisioning security, in a later article.

Step 4. Authentication

The provisioner makes use of its knowledge of the new device’s capabilities and sends a message to it, which instructs it to output either a single or multi-digit value in response to one of various supported user actions, such as pressing a button. The form that the value takes when output will vary, according to the device. One device might display a three-digit, numeric value on an LED panel while another might flash a red LED a number of times, the number of flashes being the output authentication value. The user of the provisioner will observe the value output by the device and enter it into the provisioner user interface.

The device and provisioner then exchange a cryptographic hash, derived from data which includes the random value which was output by the device, allowing them to complete the authentication of their peer.

Step 5. Distribution of the Provisioning Data

After authentication has successfully completed, a session key is derived by each of the two devices from their private keys and the exchanged, peer public keys. The session key is then used to secure the subsequent distribution of the data required to complete the provisioning process, including a NetKey and a unique address for the device, known as the Unicast Address.

After provisioning has completed, the provisioned device possesses the network’s NetKey, a Bluetooth^® Mesh security parameter known as the IV Index and it has a Unicast Address, allocated by the provisioner. The new device is now officially a node and a member of the Bluetooth Mesh network.TU

Removing a Node from the Network

There will come a time when a node of a Bluetooth^® Mesh network needs to be removed. The device might have broken and needs replacing or it might need to be moved to another Bluetooth Mesh network in another of the company’s offices in a different city. Equally, the device might have been sold with the expectation that the new owner will add the device to their own Bluetooth Mesh network, using the provisioning process described above.

If a device malfunctions and cannot be repaired, you might be tempted to simply throw it in the trash. If you sell a device to someone, you could equally be tempted to simply take the money and forget about your old device. That would be unwise, however.

Nodes contain security keys which they were provided with through the provisioning process. Remember, that it is possession of the main NetKey which determines that a device is a member of a network and therefore has access to it. Leaving the keys relating to your Bluetooth Mesh network inside a device when you throw it away or sell it could leave your network vulnerable to a trash can attack. Therefore, a secure procedure for removing nodes, which eliminates this concern, has been defined and will be described here.

Removing a node from a network involves two steps. First, the provisioner application is used to add the node to be removed to a reject list. Second, a process called the key refresh procedure is initiated.

The Reject List

Using the provisioner, the user must add the node to be removed to its reject list. The purpose of the reject list is simply to act as a list of those nodes which must not be issued with new security keys when the Key Refresh Procedure is initiated.

The Key Refresh Procedure

The key refresh procedure results in all nodes in the network, except for those which are members of the reject list, being issued with new network keys, application keys and all related, derived data. In other words, the entire set of security keys which form the basis for network and application security are replaced.

The user initiates key refresh using the provisioner and the provisioner creates and sends new keys to every node in the mesh network using configuration messages, except for those which are members of the reject list.

Low-power nodes will receive the new keys from their friend. As such, it may be some considerable time before they receive them and therefore, for the whole network to have its keys replaced.

Due to the fact that every Node will not receive its new keys at exactly the same time, the Key Refresh Procedure defines a transition period known as Phase 2, during which both the old keys and the new keys are used. Specifically, transmission uses the new keys, but nodes that support receiving messages use both the old and the new keys.

The provisioner informs all nodes that they should revoke the old keys when Phase 2 has completed and each node that is not reject listed has received its new keys.

At this point, the node which was removed from the network and which contains an old NetKey and an old set of AppKeys is no longer a member of the network and consequently, poses no threat.

Conclusion

Security is at the very core of the design of Bluetooth Mesh networking technology. We’ve seen how this has manifested itself in those most fundamental of network management scenarios, adding new devices to the Bluetooth Mesh network and removing them.

If that’s whetted your appetite for more information on Bluetooth^® Mesh network security, you’ll enjoy the next in our series of Bluetooth Mesh articles where we give you a detailed tour of some of the most important Bluetooth Mesh security features.