Last Updated on
In this post, we’re continuing our tutorial series on Bluetooth mesh (you can find part 1 here and part 2 here). This will be the final post that will cover “theory only” content — in the upcoming posts we’ll start digging into more practice by implementing a Bluetooth mesh example on the Nordic nRF52 series platform.
In this post, we’ll be covering the provisioning process as well as how security is handled in Bluetooth mesh.
The Provisioning Process
The provisioning process is one of the most important concepts in Bluetooth mesh. It is used for adding devices to the mesh network. A device that gets added to the network is called a node, and the device used to add a node to the network is called the provisioner (usually a tablet, smartphone, or a PC).
This process involves five steps:
Step 1: Beaconing
Step 1 involves what’s called beaconing, where the unprovisioned device announces its availability to be provisioned by sending the mesh beacon advertisements in the advertisement packets. This is a new type of advertisement data type introduced in the Bluetooth mesh standard. A common way to trigger this process is via a defined sequence of button presses on the unprovisioned device.
Step 2: Invitation
When the provisioner discovers the unprovisioned device via the beacons that were sent, it sends an invitation to this unprovisioned device. This uses a new type of PDU introduced in Bluetooth mesh called the provisioning invite PDU.
The unprovisioned device then responds with information about its capabilities in a provisioning capabilities PDU, which includes:
- The number of elements the device supports.
- The set of security algorithms supported.
- The availability of its public key using an Out-of-Band (OOB) technology.
- The ability of this device to output a value to the user.
- The ability of this device to allow a value to be input by the user.
Step 3: Public Key Exchange
Security in Bluetooth mesh involves the use of a combination of symmetric and asymmetric keys such as the Elliptic-curve Diffie-Hellman (ECDH) algorithm. In ECDH, public keys are exchanged between the provisioner and the device to be provisioned. This is done either directly over BLE or via an out-of-band (OOB) channel.
Step 4: Authentication
The next step is to authenticate the unprovisioned device. This usually requires an action by the user by interacting with both the provisioner and the unprovisioned device. The authentication method depends on the capabilities of both devices used.
In one case, called the output OOB, the unprovisioned device could output a random single- or multiple-digit number to the user in some form, such as blinking an LED a number of times. That number is then inputted into the provisioning device via some input method. Other cases include an input OOB, where the number is generated by the provisioner and entered into the unprovisioned device, a static OOB, or no OOB at all.
Regardless of the authentication method used, the authentication also includes a confirmation value generation step and a confirmation check step.
Step 5: Provision Data Distribution
After authentication is complete, each device derives a session key using their private key and the public key sent to it from the other device. The session key is then used to secure the connection for exchange of additional provisioning data, including the network key (NetKey), a device key, a security parameter known as the IV index, and a unicast address which is assigned to the provisioned device by the provisioner. After this step, the unprovisioned device becomes known as a node.
How is Security Handled in Bluetooth Mesh?
The first important note regarding security in Bluetooth mesh is that it is mandatory. This is compared to BLE where it’s optional and left to the developer to decide whether to include it or not.
Here are some of the basics of security in Bluetooth mesh:
- All mesh messages are encrypted and authenticated
- Network security, application security, and device security are all handled independently.
- Security keys can be changed during the life of the mesh network
Due to the separation of security between the network, application, and device levels, there are three types of security keys (each addressing a specific concern):
- Network key (NetKey)
Possession of this shared key makes the device part of the network (also known as a node). There are two keys derived from the NetKey: the network encryption key and the privacy key. Possession of the NetKey allows a node to decrypt and authenticate up to the network layer, allowing the relay of messages, but no application data decryption.
- Application Key (AppKey)
This is a key that’s shared between a subset of nodes within a mesh network, normally those that participate in a common application. For example, a lighting system AppKey would be shared between light switches and light bulbs, but not with a thermostat or a motion sensor.
An AppKey is used to decrypt and authenticate messages at the application level, but it is only valid within one mesh network, not across multiple networks.
- Device Key (DevKey)
This is a device-specific key that’s used during the provisioning process for securing communication between the unprovisioned device and the provisioner.
One major concern with a mesh network is gaining access to a network via a discarded or removed device that used to be part of the network. This can be accomplished via gaining physical access to the keys stored within the device (often referred to as a trash can attack).
In order to protect against such an attack, Bluetooth mesh defines a procedure for removal of a node where the device is added to a blacklist and the keys are refreshed. This process distributes new network keys, applications keys, and other relevant data to all nodes, except those in the blacklist.
Another concern is privacy. The way privacy is addressed in Bluetooth mesh is via the use of a privacy key that’s used to obfuscate the message header. The privacy key is derived from the network key (NetKey). For example, the source address could be obfuscated to prevent tracking of a device via its address.
The last security topic we want to cover is replay attacks. A replay attack is when one or more messages are stored and replayed later by a malicious device.
Bluetooth mesh provides protection against replay attacks by:
- Utilizing a sequence number (SEQ). Elements increment the SEQ value every time they publish a message. A node, receiving a message from an element which contains a SEQ value that’s less than or equal to the one in the last valid message, will discard it (since it is likely that it relates to a replay attack).
- Using an incrementing IV index, which is an additional value that also gets validated when a message is received.
So far, in this series, we’ve covered mostly the theoretical and core concepts within Bluetooth mesh. This is all good, but from my experience, one’s knowledge and understanding is not complete until you get your hands dirty with practical examples and implementation on a real development platform. This is what we’ll focus on in the upcoming posts in this series: we’ll take this theoretical knowledge and apply it to a real-life example implemented on the Nordic nRF52 series platform.
Be sure to subscribe below to get notified when we continue our journey with Bluetooth mesh!