Provisioning a BluetoothMesh Network Part 2

September 25, 2017
Kai Ren
Bluetooth Low Energy, Connected Device, Device Networks, Mesh

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.

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.
Invitation: The provisioner invites the unprovisioned device to send its provisioning capabilities information.
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.

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.

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.