Provisioning a BluetoothMesh Network Part 1

September 18, 2017
Kai Ren
Bluetooth Low Energy, Device Networks, Mesh

In May 2017, WannaCry, the world’s most notorious ransomware, actively attacked computers around the world and held user data for ransom. The attack effected millions of computers in 150 countries, with the software demanding ransom payments in the cryptocurrency Bitcoin. Without a robust standards-based security system design, comparable situations could happen with the Internet of Things (IoT). It’s not hard to imagine how users of IoT devices could be forced to pay a hacker to open a locked door and gain access to their own home.

Security is at the heart of the design of Bluetooth^® mesh networking. Its use is mandatory with every packet encrypted and authenticated. Security in Bluetooth mesh networking protects against various threats and issues, including:

Replay attacks, which are prevented by judicious use of sequence numbers.
Man-in-the-middle attacks, which are protected against by using asymmetrical cryptography, such as the Elliptic Curve Diffie-Hellman (ECDH) key agreement protocol, during important procedures.
Trash-can attacks, which exploit discarded devices, by ensuring security keys get refreshed when necessary.

Overview

Provisioning is the process of adding a new, unprovisioned device to a Bluetooth mesh network, such as a light bulb. The process is managed by a provisioner. A provisioner and an unprovisioned device follow a fixed procedure which is defined in the Bluetooth mesh specification. A provisioner provides the unprovisioned device with provisioning data that allows it to become a Bluetooh mesh node.

A provisioner is typically a smartphone or other mobile computing device, running a provisioning application. Although only a single provisioner is required per network to perform provisioning, multiple provisioner devices may be used.

The Provisioning Protocol

The Bluetooth mesh specification defines the provisioning protocol, which defines PDUs used to communicate between a provisioner and a new, unprovisioned device during the provisioning process. Figure 1 depicts the provisioning protocol stack alongside the full Bluetooth mesh protocol stack.

Figure 1: Mesh system architecture vs. provisioning protocol stack

From bottom to top we have the following components:

Provisioning Bearer
A provisioning bearer layer enables the transportation of provisioning PDUs between a provisioner and an unprovisioned device. Two provisioning bearers are defined:
- PB-ADV: A provisioning bearer used to provision a device over the Bluetooth advertising channels. The PB-ADV bearer is used for transmitting Generic Provisioning PDUs. A device supporting PB-ADV should perform passive scanning with a duty cycle as close to 100% as possible in order to avoid missing any incoming Generic Provisioning PDUs.
- PB-GATT: A provisioning bearer used to provision a device using Bluetooth mesh proxy PDUs from the proxy protocol. The proxy protocol enables nodes to send and receive network PDUs, mesh beacons, proxy configuration messages, and provisioning PDUs over a connection-oriented, Bluetooth Low Energy (LE) bearer. PB-GATT encapsulates provisioning PDUs within GATT operations, involving the GATT provisioning service and it is provided for use when a provisioner does not support PB-ADV.
Provisioning protocol
Defines requirements for provisioning PDUs, behavior, and security. Understanding the provisioning protocol will help you select an approach to authenticate based on application requirements.

The Provisioning Procedure

The provisioning protocol defines ten types of provisioning PDU:

Provisioning Invite
Provisioning Capabilities
Provisioning State
Provisioning Public Key
Provisioning Input Complete
Provisioning Confirmation
Provisioning Random
Provisioning Data
Provisioning Complete
Provisioning Failed

For details of these PDUs, developers can refer to section 5.4.1 of the Bluetooth mesh specification.

The overall provisioning procedure must accomplish two important tasks at a high level:

Authenticate the unprovisioned device. In a Bluetooth mesh network, there may be several, dozens, or hundreds of devices in a small space. Authentication is performed to make sure that the device the provisioner interacts with is the device the user wants to provision.
Build a secure link with the unprovisioned device and share corresponding information with it. At the end of the process, the unprovisioned device will be a node in the Bluetooth mesh network.

The provisioning procedure consists of five phases:

Beaconing
Invitation
Exchange public keys
Authentication
Distribution of provisioning data

The first three phases will be covered here. We’ll review the last two phases in Provisioning a Bluetooth Mesh Network, Part 2.

Beaconing

Beaconing is a traditional application scenario in Bluetooth^® Low Energy. Imagine a GAP peripheral device, like a smartwatch or activity tracker, which wants to be connected with a GAP central device, such as a smartphone or tablet. The GAP peripheral device switches into the adverting state and starts to broadcast advertising packets. The GAP central device scans for advertising packets to discover the other device and receive basic information about it. Bluetooth mesh provisioning uses the same advertising mechanism.

If an unprovisioned device supports the PB-ADV bearer, it advertises as an unprovisioned device beacon. This involves a specified packet format and is used by the unprovisioned device to allow them to be discovered by a provisioner.

When the PB-GATT bearer is used by the unprovisioned device, a GATT service called the Mesh Provisioning Service supports the overall provisioning procedure and interactions with the provisioner. In the beaconing phase, the unprovisioned device broadcasts advertising packets that include the UUID of the Mesh Provisioning Service. It is discovered by the provisioner through the standard Bluetooth Low Energy scan procedure.

Invitation

After beaconing, the provisioner and unprovisioned device establish a provisioning bearer, either PB-ADV or PB-GATT. Then the provisioner sends a Provisioning Invite PDU and the device responds with a Provisioning Capabilities PDU.

The Provisioning Invite PDU includes an Attention Duration field which indicates how long the primary element of the unprovisioned device should attract the user’s attention, using some form of visual indication.

The Provisioning Capabilities PDU 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 for this device to output a value to the user.
The ability for this device to allow a value to be inputed by the user.

The flowchart in Figure 2 is reminiscent of the pairing process in Bluetooth^® Low Energy, covered in a previous article: Bluetooth Pairing Part 1: Pairing Feature Exchange. The pairing feature exchange used by Bluetooth Low Energy pairing is similar to the provisioning invitation phase in the Bluetooth mesh provisioning procedure. In the provisioning invitation phase, the aim is to provide the provisioner with information about the unprovisioned device’s capabilities. With this information, the provisioner can decide what to do in the next step.

Exchange Public Keys

There are two basic techniques for encrypting information: symmetric encryption (also called secret key encryption) and asymmetric encryption (also called public key encryption.)

Symmetric encryption uses the same secret key for encryption and decryption. As long as both sender and recipient know the secret key, they can decrypt all messages encrypted with this key. However, it is difficult to securely exchange secret keys over a link and prevent them from falling into the wrong hands.

Asymmetric encryption uses two related keys, a key pair, to solve the problem above: the public key and private key. The public key is made freely available to anyone who might want to send you a message. The private key is kept secret, so that only you know it. Any message (text, binary files, or symmetric secret key) encrypted using the public key can only be decrypted by applying the same algorithm and only by using the matching private key. This means that you do not have to worry about passing public keys over the link, since they are only used for encryption and not for decryption. However, asymmetric encryption is slower than symmetric encryption and requires far more processing power to both encrypt and decrypt the content of messages.

In Bluetooth^® mesh use cases, most devices are based upon embedded chipsets or modules, so they can’t afford to encrypt/decrypt every message using computationally expensive asymmetric cryptography. Symmetric cryptography is better suited to devices which lack the processor power required by asymmetric cryptography, but we still have the problem of securely exchanging secret keys so that it can be used. Bluetooth mesh uses a combination of asymmetric and symmetric methods to solve this problem.

Asymmetric cryptography: Elliptic Curve Diffie–Hellman (ECDH) is an anonymous key agreement protocol that allows two parties, each having an elliptic curve public–private key pair, to establish a shared secret over an insecure channel. ECDH’s purpose in Bluetooth mesh provisioning is to allow the creation of a secure link between the provisioner and the unprovisioned device. It uses public and private keys to distribute a symmetric secret key which the two devices can then use for encryption and decryption of subsequent messages.
Symmetric cryptography: Every message transmitted in a Bluetooth mesh network is encrypted using AES-128 cryptography. The AES-128 algorithm is a common symmetric encryption/decryption engine, often used in embedded platforms.

In the exchange public keys phase, there are two possible ways for ECDH public keys to be exchanged. They can be exchanged over a Bluetooth link or through an OOB tunnel. In the provisioning invitation phase, the unprovisioned device has already reported whether or not it supports sending its public key via an OOB tunnel. If it does, the provisioner can proceed to use it and informs the unprovisioned device by sending a Provisioning Start PDU.

If the public key of the unprovisioned device is available via an OOB tunnel, then an ephemeral public key is transmitted from the provisioner to the device, and a static public key is read from the unprovisioned device using the appropriate OOB technology, such as a QR code. See Figure 3.

Figure 3 – Public key exchange when the unprovisioned device uses an OOB method

If not, both public keys are exchanged over a Bluetooth link as shown in Figure 4.

Figure 4 – Public Key Exchange when unprovisioned device public key is unknown

ECDHSecret = P-256(private key, peer public key)

In this equation, P-256 is the FIPS-P256 curve which is defined in FIPS 186-3.

Part 2 of this article will examine the last two stages in the provisioning procedure: authentication and distribution of provisioning data. I will also explain the security toolbox used in Bluetooth mesh networking.

FEATURED DOWNLOAD

Bluetooth Mesh Networking: Paving the Way for Smart Lighting

Bluetooth mesh networking brings the multi-vendor interoperability, low power, and low latency pedigree of Bluetooth Low Energy to the world of commercial lighting. Discover how this innovative technology can turn wireless connectivity into a smart lighting wireless platform.

INSTANT DOWNLOAD