Securing the Mesh

A project log for Bluetooth Low Energy Mesh Protocol

This is a demo project for my Bluetooth Low Energy Mesh Protocol using a simple nRF51822 based board

tim-wilkinsonTim Wilkinson 06/05/2015 at 19:590 Comments

BLEMP, my Bluetooth Mesh Network, needs to be secure. As a proof of concept, there's little harm in it being open. If I want to use it serious, and have others use it, it needs a better security story than "hope". Thankfully, Bluetooth has its own set of security protocols. Over the years various security vulnerabilities have been found, and each iteration of the spec has attempted to fix them. A few interesting papers on this are here, here and here.

Simplistic security overview

From the literature we can conclude that once a connection is established, information is exchanged securely. However, vulnerabilites exist in setting up such a connection. This setup using a shared secret; usually a 6-digit pin code, or sometimes just pushing a pairing button (effectively the pin code 000000). Obviously a brute force attack on such a trivial secret takes no time, but requires the attacker to captures this initiation process. That may be unlikely, especially as devices have to be put into "pairing" mode to allow this to happen. This mitigates attempts to hack devices without physical access. Once setup is completed, each Bluetooth device holds a common 128-bit key which is used as the basis for all future communications. For all practical purposes, this key cannot be cracked.

BLEMP poses a number of additional problems in its attempt to use the security mechanisms already present in Bluetooth. First, it may have hundreds of nodes which may speak to dozens of neighboring nodes. Second, these neighbors will change over time. And third, we want authorized external parties (i.e. Phones) to be able to talk to any part of the Mesh. Bluetooth's security is designed to secure a single point-to-point connection and not a mesh. How might we do this?

Out-of-band pairing

Fortunately, bluetooth has an additional pin code mechanism for pairing. Rather than restrict the pin code to a six digits, a 128-bit key may be used. Such a value, generate randomly, is large enough to make the pairing process unhackable, and is referred to as out-of-band pairing (OOB). If each node in the mesh knows this secret, it will be able to pair with any other node in the network, at any time, and securely communicate.

There remains the issue of how each node is given this shared secret, but I'll leave key management for another post. In the prototype the value is simply defined in the code.

Long Term Keys

The OOB key lets nodes in the network securely communicate. However, no common client devices (e.g. iOS or Android) support out-of-band pairing - even if they knew the out-of-band key, they would be unable to access the network. Instead we have to use 6-digit pin code pairing, understand that it has limitations, and attempt to mitigate them. But pin code pairing only works for a single phone-to-node connection; if we wanted to talk to a different node (as we might in a mesh network) we would have to pair with that node as well. For hundreds of node this would be impractical.

When pairing with a device, Bluetooth has the option to "bond" with it. This establishes a 128-bit long-term key (LTK), shared between the phone and node, which can be used later for secure communication without pairing again (forcing the user to re-enter a pin code). If this key is known by all the nodes in the network, then in theory, any device which knows the key will be able to security communicate with any node. Essentially the LTK acts like the OOB secret but for phone-to-node security.

The LTK is not predefined, but is generate and stored on the node during the pairing process. Once generated then, we must securely distribute it to all the other nodes in the network. Fortunately, we have already secure the mesh using the OOB key, so we can use the mesh to do this.

Now we must persuade the phone to select the correct LTK when talking to a mesh node. Normally the phone selects the appropriate LTK based on the address of the mesh node. To force it to select the same key we would have to force every mesh node have the same address. This is obviously unworkable. Fortunately Bluetooth contains one final security trick we can use; the Resolvable Private Address.

Resolvable Private Addresses and Identity Resolving Keys

To make Bluetooth devices difficult to track, each device may change its address as often as it likes. Because of this, addresses are no longer the identity of the devices therefore Bluetooth defines a new identity; the Identity Resolving Key (IRK). This key is also exchanged during bonding. When a device reconnects to a node, it uses the resolvable device address and the IRK to select the LTK to use to encrypt communications; and the same LTK is always used with the same IRK.

So, practically speaking, the same LTK will be used to communicate with any device which has the same IRK, regardless of the address of the device. If all the mesh nodes have the same IRK, but different resolvable private addresses, they will appear as individually addressable nodes, but any phone which is bonded with one will have bonded with all. The IRK does not have to be secret (knowing the IRK without the associated LTK does not grant access) and is currently defined in the code.


By defining two 128-bit values, the OOB and the IRK, we can construct a Bluetooth mesh network which is internally and externally secure. All this is done using standard Bluetooth mechanisms. The next step is key management; how to securely associated these keys with a new mesh node.