Provisioning a Bluetooth Mesh Network Part 1

Posted on September 18, 2017 by Kai Ren

Chapter 9 of the Bluetooth Mesh Networking Series

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.
FEATURED RESOURCE

Bluetooth Mesh Networking - An Introduction for Developers

Download this comprehensive technology overview to learn more about the key concepts and terminology, system architecture, and security mechanisms, as well as the unique message publication and delivery technique behind Bluetooth mesh networking.

Download the overview

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.

Mesh system architecture vs. provisioning 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:

  1. Provisioning Invite
  2. Provisioning Capabilities
  3. Provisioning State
  4. Provisioning Public Key
  5. Provisioning Input Complete
  6. Provisioning Confirmation
  7. Provisioning Random
  8. Provisioning Data
  9. Provisioning Complete
  10. 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:

  1. 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.
  2. 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:

  1. Beaconing
  2. Invitation
  3. Exchange public keys
  4. Authentication
  5. 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.

1. 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.

2. 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.

Provisioning Invitation
Figure 2 - Provisioning Invitation

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.  

3. 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.

Public key exchange when the unprovisioned device uses an OOB method.
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.

Public Key Exchange when unprovisioned device public key is unknown.
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

ON-DEMAND WEBINAR
Webinar

What Makes Bluetooth Mesh so Disruptive?

The behind-the-scenes story of the making of Bluetooth mesh

Watch our free on-demand webinar to discover how Bluetooth mesh is disrupting building automation, wireless sensor networks, asset tracking, and more.

Watch now

Kai Ren

Kai Ren

Kai Ren is Technical Program Manager for the APAC region at the Bluetooth SIG. He has more than 8 years of experience in design and development of wireless sensor networks, specializing in short range, low power wireless technology. His goal at the Bluetooth SIG is to build out Bluetooth’s developer program in the APAC region, helping developers bring innovative applications and products to market.

View all posts by Kai Ren