In Part 1 and Part 2 of this article series, we discussed the Bluetooth Mesh architecture and how messages are communicated over Bluetooth Mesh network. In today’s connected world, security is a key element in every design. Thus, it is important for an IoT application powered by Bluetooth Mesh to be absolutely secure and provide reliable functionality.
The Security implementation on a Bluetooth Mesh device is a mandatory requirement from the Bluetooth SIG and it cannot be disabled. Note that in a non-mesh BLE point-to-point connection security implementation is optional. The provisioning process by which the device is added to the Bluetooth Mesh network and data exchange within the Bluetooth Mesh network is meticulously designed with security as the utmost priority. Bluetooth Mesh protocol protects the network against various possible threats on multiple layers such as:
- Man-in-the-Middle (MITM) attacks are prevented using the Elliptic Curve Diffie-Hellman (ECDH) key exchange protocol during provisioning.
- Replay attacks are prevented by the use of sequence numbers.
- Trash-can attacks from discarded devices are prevented by the key refresh (blacklisting) procedure.
The Bluetooth Mesh topology is built with the requirement of mandatory security keys that secure the network at multiple layers of the stack. Let’s go through each security and privacy feature one by one.
Provisioning: Adding an unprovisioned device to Bluetooth Mesh network
A Bluetooth Mesh device is added to a mesh network using the provisioning process. The provisioned mesh device is called a node, and the device that performs provisioning is called a provisioner. Typically, a mobile phone act as the provisioner. It creates a mesh network, assigns a network key and other required keys. Unprovisioned mesh devices are added to the Bluetooth Mesh network using the provisioning process. The provisioner also configures provisioned mesh nodes and controls of the functionality of Bluetooth Mesh nodes in the mesh network.
The provisioning protocol can use two different provisioning bearers: PB-ADV (ADV bearer) or PB-GATT (GATT bearer). Today’s mobile devices don’t yet support the PB-ADV bearer. For this reason, the provisioning process is done through PB-GATT bearer.
An unprovisioned mesh device starts advertising after it is powered on. The provisioner scans for unprovisioned devices and establishes a standard BLE connection (assuming PB-GATT) with the unprovisioned device. It then shares keys using the Elliptical Curve Diffie-Hellman (ECDH) protocol. Thus key exchange using ECDH is very secure.
Both devices then create a session key using the exchanged keys. The session key is used to encrypt the network key, device key (key types are discussed in following sections of this article), IV index, and a unicast address, all of which are sent to the provisioned Bluetooth Mesh node. After successful provisioning, the mesh node goes through the configuration process where the mesh node’s capability is shared with the provisioner. The Provisioner assigns Application keys to the configured node. Each mesh node can have multiple Application keys, so each Application key must be bound with a specific mesh model using the process called key binding. This way the mesh stack knows which Application keys to use for a specified mesh model.
click for larger image
Figure 1: The Provisioning process for a Dimmable Light bulb. (Source: Cypress)
As it can be seen in the figure, the Dimmable Light bulb transmits Unprovisioned Device Beacons. When the provisioner tries to add a device, the Dimmable Bulb shows up in the Unprovisioned Device list. When the user clicks on the Dimmable Light device in iOS mesh app, the provisioning process starts.
The phone sends a Provisioning invite, and the Dimmable Light bulb responds with capabilities such as the number of supported elements, supported security algorithms, availability of public-key using out-of-band (OOB), and input/output capability to enter/display user value. Based on the Dimmable Light bulb’s capabilities, ECDH public keys are exchanged either using an OOB method or using the Bluetooth link. Then the authentication is performed.
Once the Dimmable Light bulb is authenticated, the Provisioner sends Provisioning data over the AES-CCM encrypted link. Once the Provisioning data (Network Key, Device Key, IV Index, Unicast Address, etc.) is sent to the Dimmable Light bulb, the provisioning process is complete. The Provisioner may now configure the Dimmable Light bulb (not shown in this sequence diagram).
Network key, Application key, and Device key
Possession of the Network key allows a node to decrypt and authenticate up to the Network layer that makes it possible to Relay messages within a Network. Network encryption keys and private keys are derived from the Network key. It is important to note that even though all the nodes in the network receive and forward mesh relay messages, the actual application data cannot be decrypted using the Network keys. The application data can only be decrypted only if the device possesses the appropriate Application key.
Network key: A node can possess one or more Network keys. This enables the creation of multiple subnets within a single Bluetooth Mesh network. For example, consider a multi-level parking system. It might be beneficial to split each level into its own subnet. This partitioning avoids relaying of messages across all levels and confines the relayed messages to the desired level.
Application key: Application keys are shared between a subset of devices within a mesh network. Generally these devices have similar functionality. For example, all the lightbulbs in the living room may share the same Application key whereas a motion sensor or a lock will have a separate Application key. The mesh message to change the state of the lightbulb can be decrypted only by the lightbulbs in the living room (i.e., these are the only devices that contain the required Application key).
Device key:Device keys are assigned to each provisioned mesh node by the Provisioner. This allows for unique identification of mesh nodes. The Device key is used only during the node configuration process by the provisioner.
Node removal (Key Refresh, Blacklisting)
It is important to prevent a hacker from mounting an attack on a specific mesh network using security keys obtained from a faulty or disposed mesh node which was part of the targeted mesh network. This kind of attack is commonly known as Trashcan attack. To avoid these kinds of attacks, the Bluetooth SIG has defined a key refresh procedure. This procedure can be initiated by the Provisioner to put a specific node in the Blacklist. The key refresh procedure issues new Network keys, Application keys, and all the necessary information to all the devices in the mesh network except for the devices in the Blacklist. Any keys the Blacklisted device had can no longer be used to access the mesh network.
Privacy (Message obfuscation):
Privacy is an important aspect for everyone. Privacy in Bluetooth Mesh is addressed using the privacy key. As discussed earlier, the privacy key is derived from the Network key. Bluetooth Mesh uses this privacy key to obfuscate the message header values such as the source address. If the source address is obfuscated, this will prevent an attacker from tracking messages based on their source address.
An attacker can choose to disrupt a mesh network by capturing over the air messages and resending the same packet multiple times. Imagine an attacker capturing messages to unlock the door lock. If an attacker can successfully capture over-the-air messages to unlock the door, this would provide access to the door. Clearly, this would be a huge threat to people and their property. To address this issue, the Bluetooth SIG provided two fields as part of each network message: the Initialization vector index (IV index) and sequence number (SEQ).
The sequence number is incremented every time a node publishes a message. mesh nodes will discard the mesh messages with a sequence number equal to or smaller than the last processed valid mesh message. To change the sequence number, an attacker must possess all the required keys to decode and then encrypt the message. These keys are available only to the intended device. Thus, even if an attacker tries to reply the message, it will be discarded by the target node. The IV index is a separate field in the mesh network message. The value of IV index in messages must be equal to or greater than the last processed valid mesh message, otherwise the message will be discarded.
In a nutshell, the Provisioning process in Bluetooth Mesh allows only trusted devices to be added to the network and avoids any man-in-the-middle attacks. Security keys such as the Network key allow the creation of subnets while Application keys allow mesh messages to be decoded only by a specific application. Key refresh procedures implement safe node removal and protect against Trashcan attacks. Replay attacks are avoided by adding a sequence number to every message. Message obfuscation protects the sender’s identity. All these features make Bluetooth Mesh very secure and private.
In the next part of this article series, we will talk about the points to be considered while selecting a Bluetooth Mesh device for your application.
Sachin Gupta is Product Marketing Manager at Cypress Semiconductor. He has more than 11-years of experience in product marketing and applications engineering roles. He has managed USB Type-C, Wi-Fi, Bluetooth, SoC and FPGA products in his product marketer roles. He can be reached at firstname.lastname@example.org.
Santhosh Vojjala is currently working as Principal Applications Engineer at Cypress Semiconductor. He has 11+ years’ experience in managing and developing world class connectivity (IoT), touch screen and embedded systems solutions for world wide customers. He can be reached at email@example.com