Management of Devices in aBluetooth Mesh Network

August 28, 2017
Martin Woolley
Bluetooth Low Energy, Connected Device, Device Networks, Mesh

A Bluetooth^® Mesh network is like an exclusive club. If you’re a member of the club, you can enter the club and make use of those facilities and services which your membership type allows. If you’re not, you aren’t allowed through the front door, no matter what you say.

A Bluetooth Mesh device is either a member of a particular Bluetooth Mesh network, or it is not. If it is a member, it has the right to communicate, in at least a basic way, with other devices that are also members of that network. If it’s not a member, then anything and everything that device transmits will be ignored by other devices in the network.

A Bluetooth Mesh device can be thought of as having a membership type as well, like having access to specific club amenities (gym, golf course, etc.), but not the entire club. It can only fully interact with certain devices in the network. The concept governing this is that of the application. For example, a Bluetooth Mesh light switch can switch Bluetooth Mesh lights on or off in the network as a consequence of each of those devices being part of the lighting application. The light switch cannot switch on the heating system because the heating system is not part of the lighting application.

For a device to become a member of a Bluetooth Mesh network, it must be added to the network using a secure process called provisioning.

Security

Security is central to Bluetooth^® Mesh networking and we’ll cover the subject in detail later in this series. Adding or removing a device to/from a Bluetooth mesh network are both processes which have security requirements at their very heart.

Bluetooth Mesh networking uses a system of different security key types to secure the network as a whole, as well as to secure and separate individual applications within the network. Being a member of a network and having the right to participate in a particular application is, in both cases, a consequence of a device possessing the right security keys. All nodes in a network possess a key called the network key or NetKey. It is possession of this key which makes a device a member of that network, i.e. one of its nodes.

Nomenclature

Earlier in the Bluetooth^® Mesh Networking Series, we introduced the formal, technical terms device and node. You may recall that a device which is a member of a Mesh network is called a node and one which is not is called a device. I’ll now use “Device” with an uppercase “D” to denote a device which is not yet part of a mesh network and continue to use “device” as I have been so far, to mean an electronic item in the more general, informal sense.

The Provisioner

Provisioning transforms a humble device into a node, a full-fledged member of a Bluetooth Mesh network. The process is accomplished using an application, which is typically provided by product manufacturers for use on smartphones or tablets, but may take other forms, such as desktop or web applications.

The device running the provisioning application is called the provisioner. The provisioner must be physically secure, as it has a very special role to play.

The Provisioning Protocol

During provisioning, the provisioner and the Device to be provisioned communicate using a Bluetooth^® Mesh protocol called the provisioning protocol. The provisioner may use the provisioning protocol over either of the PB-ADV or PB-GATT bearers[i], ensuring that provisioner applications may be implemented on older smartphones, only requiring that they have support for Bluetooth Low Energy (LE) and GATT.

Adding a New Device to the Network

Adding a device to the network is largely concerned with providing it with the network key which all the other nodes of that network possess. And of course, that process must itself be secure so that malicious devices cannot eavesdrop on the communication which takes place whilst adding the new device and steal the NetKey.

When a new device is purchased and it needs to be added to an existing Bluetooth Mesh network, users will employ the provisioner, together with instructions from the manufacturer of the new device, to add it to the Bluetooth Mesh network. This transforms the new device into a node and member of the Bluetooth Mesh network.

The process involves several steps, depicted in the flow chart below.

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.

FEATURED DOWNLOAD

Bluetooth Mesh Models: A Technical Overview

In this detailed technical paper, Martin Woolley provides a guided tour of the Bluetooth Mesh models, taking an in-depth look at building blocks critical to Bluetooth Mesh interoperability.

INSTANT DOWNLOAD