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:

  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.

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

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

Bluetooth Channel Sounding: How It Works and What It Means

Bluetooth® Channel Sounding is a new secure, fine-ranging capability that promises to enhance the…

Receiver Blocking Resilience Test Suite

This Test Suite tests the receiver blocking resilience of a Bluetooth implementation. It is…

Now Available: New Version of the Bluetooth Core SpecificationBluetoothコア仕様の新バージョンがリリース

Thanks to the dedication and hard work of the Bluetooth community, Bluetooth® technology is…

Channel Sounding: Technical Overview (Pt 2)

In Part 1 we introduced the new Bluetooth distance measurement innovation known as Channel…

Unlocking Healthcare Potential: SPP and Bluetooth® LE for Medical Devices

The Serial Port Profile (SPP) has long been a well-known standard for wireless serial…

The Bluetooth Roadmap: Bluetooth Specifications in ProgressBluetoothのロードマップ:策定中のBluetooth仕様

Though not commonly known among many consumers, Bluetooth® technology is constantly and consistently advancing to…

A First Look at Bluetooth® Channel SoundingBluetoothチャネルサウンディングの紹介

Over the last 25 years, we have seen Bluetooth® technology advance from a point-to-point…

Silvair Compliance Guide: Adhering to UK lighting and Energy Standards

Silvair compliance guide explores the most important lighting control regulations currently valid in the…

Coffee → Max Throughput → More Bluetooth® Testing

Recently, while sipping on our americanos and lattes, conversation moved to our series of…

ABI Snapshot – Key Findings from the 2024 Bluetooth Market Update

In this ABI Snapshot, ABI Research’s Senior Director Andrew Zignani and Bluetooth SIG’s Market…

Bluetooth® Channel Sounding: A Technical Overview

This paper provides a detailed technical overview of Bluetooth® Channel Sounding, a secure fine ranging…

Enabling the Digital Transformation of Industrial IoT with Bluetooth®

The Industrial IoT is a digital transformation process for enterprises offering them compelling abilities…

Bluetooth Low Energy Fundamentals

The Bluetooth Low Energy (LE) Fundamentals Course is designed to give you the knowledge…

Bringing Wireless Controls To The Epicentre Of Connectivity

This year, the time came for the lighting infrastructure at the Bluetooth SIG headquarters…

Smart Lighting And Controls Halve Energy Consumption At Campus Pitzemburg

Campus Pitzemburg has cut its energy usage by 50% thanks to smart controlled energy…

Sylvania Lets Efficiency And Control Fly High At FLYINGGROUP Antwerp

FLYINGGROUP Antwerp was looking for a solution for their meeting rooms that were more…

Bluetooth® Technology for Linux Developers

Learn how to use the interprocess communication system D-Bus and the BlueZ APIs to create Bluetooth applications for Linux computers.

2021 Bluetooth® Market Update

Supported by updated forecasts from ABI Research and insights from several other analyst firms, the Bluetooth Market Update highlights the latest Bluetooth trends and forecasts.

Designing and Developing Bluetooth® Internet Gateways

Learn about Bluetooth® internet gateways, how to make them secure and scalable, and design and implement your own...

2020 Bluetooth® Market Update

Supported by updated forecasts from ABI Research and insights from several other analyst firms, the Bluetooth Market Update highlights the latest Bluetooth trends and forecasts.

The Bluetooth LE Security Study Guide

Learn about fundamental security concepts, the security features of Bluetooth Low Energy, and gain some hands-on experience using those features in device code.

2019 Bluetooth® Market Update

Supported by updated forecasts from ABI Research and insights from several other analyst firms, the Bluetooth Market Update highlights the latest Bluetooth trends and forecasts.

Lighting as a Platform

See how connected lighting systems are being used as a platform to enable advanced building services like wayfinding, asset tracking, and space utilization to improve the ROI of smart building investments.

Build a Smarter Building with Blue

See how Bluetooth increases reliability, reduces costs, and enhances your smart building ROI.

Overview – Bluetooth Mesh Networking

A quick overview outlining how Bluetooth mesh uniquely meets the reliability, scalability, and security requirements of commerical and industrial markets.

 Get Help