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

Designing and Developing Bluetooth® Internet Gateways

Design and implement your own Bluetooth® Internet Gateway (BIG) working prototype and see for yourself how BIGs allow applications to exchange data with Bluetooth devices from anywhere in the world.

Wireless Connectivity Options for IoT Applications - Asset Tracking

If you recall from the previous article in this series, we covered the application…

How Bluetooth Technology Uses Adaptive Frequency Hopping to Overcome Packet Interference

Interference is one of the biggest challenges for any wireless technology in providing reliable…

How Bluetooth Mesh Enables Scalable, Reliable Low-Power Wireless Networks

Silvair, a strong advocate for Bluetooth mesh and a leading contributor to the Bluetooth mesh…

6 Companies That Prove the Reliability of Bluetooth Technology in Challenging Environments

While wireless technologies are sometimes perceived as unable to support the levels of reliability…

A Technical Overview of LC3

An Introduction to LE Audio Over the past two decades, since its inception, Bluetooth®…

How Bluetooth Technology Creates Reliability From Unreliable Foundations

Figure 3a – A stack configuration supporting Bluetooth LE with GAP/GATT/ATT Bluetooth® enabled devices…

2 Ways Bluetooth Technology Makes Wireless Connections Reliable

One of the biggest challenges for any wireless technology in providing reliable data communication…

Understanding Reliability in Bluetooth® Technology

Download this detailed discussion of the issues and factors that impact the reliability of…

Bluetooth Mesh Networking Highlights and Features

This white paper provides an overview of the Bluetooth Mesh Profile and highlights some…

Energy and Cost Savings at Pioneer Markets in Mariposa and Waterford, California

Pioneer market is a family owned grocery business operating in Mariposa, California and Waterford,…

Energy Efficiency Through Standards-Based Lighting Control Systems

This session will discuss the unified architecture of Bluetooth mesh–based inter-luminaire networks extended with…

Unlocking IoT Data With Bluetooth® Mesh

In this webinar we explore how sensing meets lighting control in Bluetooth mesh. We…

An Introduction to Bluetooth Low Energy for Swift Developers

All smartphones support Bluetooth® Low Energy (LE) and it is used in all manner…

Building a Sensor-Driven Lighting Control System Based on Bluetooth® Mesh

A technical examination of which Bluetooth mesh models to use in different types of…

What is Bluetooth Mesh? | Tech Chats - with Cypress Semiconductor

Chris Anderson chats with Michael Shen of Cypress Semiconductor about Bluetooth mesh, covering a…

Multi-vendor Bluetooth Mesh SSL projects benefit warehouse and factory settings

Yamaha warehouse and Crystal bottled water facility leverage Bluetooth Mesh to slash energy use…

150,000 Sq Ft Facility With Bluetooth Mesh Luminaires

The customer – one of the most popular bottled water providers in the US,…

Bluetooth mesh models: The building blocks for interoperable products

Bluetooth® technology is a wireless standard with agreed, formal specifications that support global interoperability…

Yamaha Motors Improves Energy Performance and Operational Flexibility with Bluetooth Mesh Controls

Maximizing efficiency at its midwestern distribution center is an important business goal for Yamaha…

How to Deploy BlueZ on a Raspberry Pi Board as a Bluetooth Mesh Provisioner

This step-by-step study guide will teach you: How to rebuild the kernel on a…

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