Provisioning a Bluetooth
Mesh Network Part 2

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.

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.

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.

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

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.