Chapter 10 of the Bluetooth Mesh Networking Series

In part 1 of this article, I introduced the provisioning bearer layer and the first three phases of the Bluetooth® Mesh provisioning process: beaconing, invitation, and exchange public keys.

  1. Beaconing: The unprovisioned device sends an unprovisioned device beacon if the PB-ADV bearer is supported, or it sends a connectable advertising packet if PB-GATT is instead being used. This indicates to the provisioner that it is ready to be provisioned.
  2. Invitation: The provisioner invites the unprovisioned device to send its provisioning capabilities information.
  3. Exchange Public Keys: In this phase, depending on the capabilities of the unprovisioned device, the provisioner selects a suitable authentication method and informs the unprovisioned device of the approach to be taken. After that, the provisioner and the unprovisioned device create an elliptic curve public-private key pair and exchange public keys. Each device then calculates a symmetric key, known as the ECDHSecret, using its own private key and the peer device’s public key. This key is used to secure communication between the two devices from this point on.

This article covers the remaining two phases of the provisioning process: Authentication and the Distribution of Provisioning Data. 

Authentication

In this step, the provisioner uses the selected authentication method to authenticate the unprovisioned device. There are three available approaches to authentication: Output OOB, Input OOB, and Static OOB or No OOB.

Output OOB

If the Output OOB (Out of Band) authentication method is selected, the unprovisioned device picks a random number and outputs that number in a way which is compatible with its capabilities. For example, if the unprovisioned device is a light bulb, it could blink a given number of times. If the device has an LCD screen, it could show the random number as a multiple digit value. The user of the provisioner inputs the number observed to authenticate the unprovisioned device. The workflow for the Output OOB authentication method is shown in Figure 1

Authentication using Output OOB.
Figure 1 – Authentication using Output OOB

After the random number has been input, the provisioner generates and checks a confirmation value. The check confirmation value operation is identical within the overall authentication step, regardless of the authentication method used and is described below.

Input OOB

The Input OOB authentication method is similar to the Output OOB method, but device roles are reversed. The provisioner generates a random number, displays it, and then prompts the user to input the random number into the unprovisioned device using an appropriate action. For instance, a light switch may allow the user to input the random number by pressing a button an appropriate number of times within a certain period. 

Compared to Output OOB, the Input OOB method requires one additional provisioning protocol PDU to be sent. After finishing the authentication action, the unprovisioned device sends a Provisioning Input Complete PDU to the provisioner to inform it that the random number has been input. The process continues with the check confirmation value operation.

Figure 2 – Authentication with Input OOB

Static OOB or No OOB

In cases where neither Input OOB or Output OOB are possible, the provisioner and unprovisioned device may use either Static OOB authentication or No OOB authentication. In this case, the provisioner and unprovisioned device each generate a random number and then proceed to the check confirmation value operation.

Check Confirmation Value

Regardless of the authentication method used, confirmation value generation and checking takes place. According to the Bluetooth Mesh Specification, the provisioner and unprovisioned device should each calculate a confirmation value separately. The two values become known as ConfirmationProvisioner and ConfirmationDevice. Both values use the same function flow in their calculation, varying only in their use of different random number inputs.

The specification includes two pages which illustrate the calculation procedure. The confirmation value generation function requires eight parameters whose values come from proceeding steps in the provisioning process. You’ll find more detail in specification sections 5.4.2.4 Authentication and 5.4.1 Provisioning PDUs.

The table below lists the parameters used for confirmation value generation and their origin.

Table 1 – Parameters used for confirmation value calculation.

Parameter

Origin

ProvisioningInvitePDUValue

ProvisioningCapabilitiesPDUValue

Step 2

ProvisioningStartPDUValue

PublicKeyProvisioner

PublicKeyDevice

Step 3

ECDHSecret

Step 3

AuthValue

Step 4

If Output OOB or Input OOB method is used, AuthValue is the value input by the user.

RandomProvisioner

Step 4: Random number from the provisioner.

RandomDevice

Step 4: Random number from the unprovisioned device.

Let’s take a look at the algorithm used for confirmation value generation. Figure 3 provides a flowchart which includes several rounds of AES-CMAC and SALT generation. The flowchart applies to both the ConfirmationProvisioner and ConfirmationDevicevalues.

  • If input was performed by the provisioner, we start with a value termed RandomProvisioner (shown below in blue) and the ConfirmationProvisioner is generated.
  • If input was performed by the unprovisioned device, we start with a value termed RandomDevice (shown below in green) and a ConfirmationDevice value is generated.
Figure 3 – Confirmation value generation chart

Confirmation Value Check

When confirmation values are ready, they are exchanged by the two devices and each checks the integrity of the received value. Figure 4 illustrates the confirmation value checking process.

The confirmation process starts with the provisioner sending its random number, RandomProvisioner, to the unprovisioned device. The unprovisioned device uses it to recalculate the confirmation value and verify it by comparing it with the confirmation value it previously received.

Figure 4 – Confirmation value check
  • If the confirmation value calculated by the unprovisioned device does not match the received ConfirmationProvisioner, then the provisioning process will be aborted.
  • If the confirmation value calculated by the unprovisioned device matches the received ConfirmationProvisioner, then the unprovisioned device sends its RandomDevice value to provisioner.

The provisioner then uses the same process to recalculate the confirmation value and verify by comparing the calculated value with the previously received value.

  • If the confirmation value calculated by the provisioner does not match the received ConfirmationDevice, then the provisioning process will be aborted.
  • If the confirmation value calculated by the provisioner matches the received ConfirmationDevice, it means that authentication is successful. The unprovisioned device may now become a node in the Bluetooth Mesh network via the provisioner and unprovisioned device completing step five of the provisioning process: Distribution of Provisioning Data.

Distribution of Provisioning Data

Once the authentication step has completed, the bearer established between provisioner and unprovisioned device can be secured for the most important step in the provisioning process:  deriving and distributing the provisioning data. The provisioner is responsible for generating the provisioning data, which consists of a number of items of data, including a security key known as the Network Key. Table 2 lists the provisioning data fields.

Table 2 – Provisioning Data

Field

Size(octets)

Notes

Network Key

 

NetKey for short. NetKey secures communication at the network layer and is shared across all nodes in the network. Possession of a given NetKey is what defines membership of a given Bluetooth Mesh network or subnet. Equipping a device with a network’s NetKey is one of the primary outcomes of the provisioning process.

The provisioner creates the NetKey when provisioning the first device to be added to the network.

Device Key

 

A unique security key possessed only by the provisioner and the device being provisioned.

Key Index

 

NetKeys are too long to be transported in single segment messages. To make messaging as efficient as possible, keys are allocated a globally unique 12-bit index value known as the key index, which acts as a short identifier for the key. Messages include key index values which may be referenced against key lists maintained by Configuration Clients.

Flags

 

Flag bitmask – indicates the status of the associated key.

IV Index

 

The IV (Initialization Vector) Index is a 32-bit value which is shared by all nodes in a network. Its purpose is to provide entropy (randomness) in the calculation of message nonce values.

Unicast Address

 

Unicast address of the primary element of the new node.

In order to distribute provisioning data securely, the provisioner uses AES-CCM to encrypt the provisioning data with a shared SessionKey, which both the provisioner and unprovisioned device calculate. AES-CCM requires three input parameters: session key, session nonce, and plaintext. The plaintext parameter value contains the provisioning data which needs to be encrypted. The device key, session key, and session nonce values are derived by a process which is depicted in Figure 5.

Figure 5 – DevKey/SessionKey/SessionNonce Generation Process

From Figure 5 we can see that:

  • If an input value of prsk (green) is passed into the k1 function, a SessionKey will be generated. This is the key used for provisioning data encryption.
  • If an input value of prsn (yellow) is passed into the k1 function, a SessionNonce will be generated. This is the nonce value used for provisioning data encryption.
  • If an input value of prdk (blue) is passed into the k1 function, a DevKey will be generated.

Both the provisioner and the unprovisioned device need to generate a SessionKey and SessionNonce. When the SessionKey and SessionNonce values are ready, the provisioner encrypts and sends the Provisioning Data PDU containing the derived provisioning data to the unprovisioned device. Here, the corresponding same SessionKey and SessionNonce values are used to decrypt the received data.

At this point, the provisioning process is finished. The two peer devices each know the new DevKey and the global NetKey, which makes our new device a node and member of the Bluetooth Mesh network.

Developing Mesh

The provisioning process is the bedrock of Bluetooth® Mesh security, which allows network devices to reliably and securely communicate with one another.  If you’d like to know more about Bluetooth Mesh, you can download the specifications and get everything you need to develop the next Bluetooth Mesh innovation.

FEATURED WEBINAR

What Makes Bluetooth Mesh So Disruptive?

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

WATCH THE WEBINAR

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