By Kamaldeep Bansal, System Applications and Intergation Lab, STMicroelectronics Pvt. Ltd.
Bluetooth Low Energy (BLE) is the wireless communication technology available in every smart phone today. It has various advantages over other available communication technologies like low power consumption, security, versatility feature, makes it a good choice to connect with the smart devices. Extending one to one or one to many Bluetooth capabilities to many to many BLE mesh technology is bringing a big revolution in IoT ecosystem. Smart devices connected over BLE mesh network can be controlled to develop a smart home, smart office or smart industry.
To make smart devices part of the mesh network, security credentials and configuration information need to be provided to the smart devices. Generally, a smart phone is used to securely transfer this information to the devices. An advanced approach has been developed to provision a BLE Mesh network without using a smart phone. Same BLE interface used in the mesh nodes is used to provision the nodes to reduce the cost and removing the need of a smart phone. This helps in making the mesh network easy to use for those who are not familiar with smart phones like old age and blind people.
BLE-Mesh is an IoT (Internet of Things) application for connecting multiple BLE (Bluetooth Low Energy) devices in Mesh networking. It enables the Bluetooth enabled devices into a powerful, integrated, range-extending Mesh network with true two-way communication. Multiple devices can be controlled and monitored in a secure network very efficiently using this technology.
Provisioning is the process of authenticating and providing basic information of the BLE mesh network to a device. A device must be provisioned to become it a node. Once provisioned, a node can transmit or receive messages in a BLE mesh network.
Provisioner is a node that is capable of adding a device into mesh network. It manages allocation of addresses to make sure no duplicate unicast addresses are allocated. Provisioner invite an unprovisioned device into a mesh network after it has been authenticated, converting the unprovisioned device into a mesh node. Provisioner is typically a smart phone or other smart computing device. Bringing the provisioning capability into an embedded board made the whole system autonomous, required minimal input from the user and enhanced security with reduced cost.
PROVISIONING PROCEDURE
Provisioning is a process of installing the device into a network. It is a mandatory step to build a Bluetooth Low Energy Mesh network.
In the provisioning process, a provisioner securely distributes a network key and a unique address space for each device. Provisioning protocol uses P-256 Elliptic Curve Diffie-Hellman Key Exchange to create a temporary key to encrypt network key and other information. This provides security from a passive eavesdropper.
Provisioning uses a layered architecture to send provisioning PDUs (Protocol Data Unit) using Provisioning Protocol as shown in Fig. 3.
A. Provisioning bearer
To provision a device, a provisioning bearer must be established between a Provisioner and a device. Provisioner identifies a device by its Device UUID or any other supplementary information that may also be provided. A provisioning bearer layer enables the transportation of Provisioning PDUs (Protocol Data Unit) between a Provisioner and an unprovisioned device. There are two provisioning bearers defined in BLE Mesh standard:
• PB-ADV is a provisioning bearer used to provision a device over the advertising channels using Generic Provisioning PDUs. The provisioning mechanism is session based. A session is established using the Link Establishment procedure.
• PB-GATT is a provisioning bearer used to provision a device using Proxy PDUs to encapsulate Provisioning PDUs within the Mesh Provisioning Service. It uses data channels to exchange the information between two devices.
B. Generic Provisioning Layer
Generic Provisioning layer is responsible for transport of Generic Provisioning PDUs over an unreliable connectionless provisioning bearer. This layer ensures reliable delivery of provisioning protocol packets using defined Generic Provisioning PDUs. Generic Provisioning PDU format consists of a Generic Provisioning Control (GPC) field followed by a variable length Generic Provisioning Payload.
C. Proxy Protocol
GATT bearer is provided to enable devices that are not capable of supporting the advertising bearer to participate in a mesh network like mobile phone. The GATT bearer uses the Proxy protocol to transmit and receive Proxy PDUs between two devices over a GATT connection.
D. Provisioning Protocol
Provisioning PDUs are used to communicate between a Provisioner and an unprovisioned device during provisioning process. First octet of the Provisioning PDU is the Type field and defines the format of the parameters of the Provisioning PDU as shown in Fig 4.
After establishing the provisioning bearer, Provisioner starts provisioning procedure by sending Provisioning invite PDU to the device. Device acknowledges it by sending its supported provisioning capabilities to the Provisioner.
Provisioner selects among the device’s supported capabilities and sends Provisioning Start PDU. Provisioner sends Provisioning Public Key PDU to deliver the public key to be used in the ECDH calculations.
Optionally device sends Provisioning Input complete PDU when the user completes the input operation.
Provisioner or the device sends Provisioning confirmation PDU to the peer to confirm the values exchanged so far including the Authentication value and the random number that has yet to be exchanged. A Provisioner or device sends Provisioning random PDU to enable the peer device to validate the confirmation. Provisioner sends provisioning data PDU to deliver encrypted provisioning data to the device. Finally device sends provisioning complete PDU to indicate that it has successfully received and processed the provisioning data.
Various types of provisioning PDU types used in provisioning protocol are shown in Table 1.
| Provisioning PDU types | |||
| Type | Name | Description | |
| 1 | 0x00 | Provisioning Invite | Invites a device to join a mesh network |
| 2 | 0x01 | Provisioning Capabilities | Indicates the capabilities of the device |
| 3 | 0x02 | Provisioning Start | Indicates the provisioning method selected by the Provisioner based on the capabilities of the device |
| 4 | 0x03 | Provisioning Public Key | Contains the Public Key of the device or the Provisioner |
| 5 | 0x04 | Provisioning Input Complete | Indicates that the user has completed inputting a value |
| 6 | 0x05 | Provisioning Confirmation | Contains the provisioning confirmation value of the device or the Provisioner |
| 7 | 0x06 | Provisioning Random | Contains the provisioning random value of the device or the Provisioner |
| 8 | 0x07 | Provisioning Data | Includes the assigned unicast address, a network key, NetKey Index, Flags and the IV Index |
| 9 | 0x08 | Provisioning Complete | Indicates that provisioning is complete |
EMBEDDED PROVISIONER IMPLEMENTATION
Embedded provisioner is based on STMicroelectronics’s BLE Mesh solution called STSW-BNRG-Mesh. It has been developed to add devices in the mesh network, at which point they become nodes.
Provisioning is performed using a five-step process:
• Beaconing
• Invitation
• Exchanging public keys
• Authentication
• Distribution of the provisioning data
as shown in Fig 5.
A device that supports PB-ADV, has not been provisioned, and is not in the process of being provisioned, advertises the Unprovisioned Device Beacon. Embedded provisioner continuously scanned BLE beacons to search for any unprovisioned device in the range.
After getting the Device UUIDs of all the unprovisioned devices, Embedded provisioner used PB-ADV provisioning bearer to establish a link using generic provisioner layer.
After the provisioning bearer is established, Provisioning of the device is initiated using the provisioning protocol. Provisioner used provisioning PDUs to communicate with the device.
Provisioner invited the selected device to begin the provisioning process. After getting the provisioning capabilities from the device, Provisioner determined that it can provision the device. It send the selected supported security algorithm, availability of public key using an 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 input by the user, and if the device has a block of OOB data that can be used for authentication.
As public key was not available using an OOB technology, the public keys were exchanged between both devices.
Once the Public Key of the peer device is known, Both Provisioner and device used the calculated Diffie-Hellman shared secret ECDHSecret and generated a session key from that shared secret.
ECDHSecret = P-256(private key, peer public key)
This session key has been used to encrypt and authenticate the provisioning data. It then authenticated the device using information that is specific to that device. Both devices exchanged the confirmation followed by a random number. The confirmation values are a cryptographic hash of all the values exchanged so far and the random number. Once the device has been authenticated, the provisioning data has been sent to the device encrypted with a key derived from that shared secret.
Upon receiving the Provisioning Data PDU from the Provisioner, the device decrypted and authenticated the provisioning data. Upon successful completion of the address assigning procedure, the device responded with a Provisioning Complete PDU to confirm that it has been provisioned. Upon receiving the Provisioning Complete PDU from the device, the Provisioner assumed that provisioning process is completed successfully and the device is using the value of the unicast address.
Provisioner didn’t reuse unicast addresses that have been allocated to a device and sent in a Provisioning Data PDU until the Provisioner receives an Unprovisioned Device beacon or Service Data for the Mesh Provisioning Service from that same device, identified using the Device UUID of the device.
Embedded provisioner application run on the top of BLE stack along with the BLE Mesh application. To make embedded provisioner application working on the same chip as of nodes which has limited device memory, optimized coding approach is used.
In Embedded provisioner application, a state machine has been used to handle the different provisioning process states. It starts with scanning the BLE beacons state in which provisioner scans the unprovisioned device beacon, establishes link with the chosen device, performs provisioning procedure, assign address to device and save device information in the flash memory. This state machine work in cyclic manner to provision multiple unprovisioned devices in the range as shown in Fig 6.
RESULTS & USAGE OF EMBEDDED PROVISIONER
After powering on the embedded provisioner node for the first time, It creates the network credentials including network key, application key, IV Index etc. required to send and receive data packets in mesh network.
A serial UART interface is available to interact with the provisioner node. After successful creation of network credentials, an informative message appears on the serial interface showing the node as provisioner node as shown in Fig 7.
In BLE Mesh, Unprovisioned device beacon is used by devices that are unprovisioned to allow them to be discovered by a Provisioner. Devices broadcast their own unique Device UUID for their identification.
To check the presence of any un-provisioned device, provisioner node needs to scan available beacons. Scanning process can be initiated by sending a scan command using the serial terminal defined as ATEP SCAN. Embedded provisioner starts scanning the BLE advertising channels for available Unprovisioned Device beacons.
In reply to this command, provisioner node provides the list of Device UUIDs of all the available unprovisioned devices on the serial terminal. Scan command response for two Unprovisioned Devices available in the range of provisioner identified using their Device UUIDs of has been shown in Fig 8.
This information can be used to select any of the available unprovisioned devices for provisioning. To begin the provisioning of selected node, another command defined as ATEP PRVN-XX can be used and sent through serial terminal. Here XX indicates the device location in unprovisioned device received list during scan stage. XX is a zero based offset, thus for provisioning the first device, XX becomes 00.
After issuing the provisioning command, provisioner node establishes a link over PB-ADV provisioning bearer with the device identified by the Device UUID. Over this link, all required provisioning protocol messages has been sent using Provisioning PDUs.
Generic Provisioning layer ensures the reliable delivery of provisioning messages using Generic Provisioning PDUs over an unreliable connectionless provisioning bearer.
After successful provisioning of the device, provisioner prints a provisioning successful message along with the calculated device key of the node. This device key information and allocated unicast address of node which are unique for each node in the mesh network has been saved in flash memory by the provisioner as network information and used later for network or node configurations.
Finally after getting the successful provisioning complete message from the device provisioner closes the established link as shown in Fig 9.
Embedded provisioner application is developed in such a way to make it working on the same chip as used for nodes. This required an optimized coding approach to fit the full Embedded provisioner application into limited device memory. An optimized coding approach is used which required only 3Kbytes of flash memory in addition to BLE Mesh application for Embedded Provisioner feature.
CONCLUSION
With the growing market of IoT devices, more and more devices are becoming part of the network for remote controlling and monitoring. With increasing number of smart devices in mesh network, Embedded provisioner is a good alternative which can help in saving both time and cost.
In a big mesh network with hundreds of devices, It is really a big challenge to do provisioning of all devices. Embedded provisioner can easily handle this problem by provisioning the nodes with the help of a small automation script.
Also It can be included in embedded systems like smart speakers, smart TVs to help them in creating the mesh network, provision and control the mesh nodes. Thus with the new developments more and more different types of devices can be added in the mesh networks with simplicity.
REFERENCES
[1] Mesh Profile Bluetooth Specification, Revision: v1.0, Revision Date: 2017-Jul-13, pp. 227-259
[2] Mesh Model Bluetooth Specification, Revision: v1.0, Revision Date: 2017-Jul-13
[3] Bluetooth Core Specification, Version 4.2, Publication Date: 2014-Dec-02
[4] Website – https://www.bluetooth.com/blog/provisioning-a-bluetooth-mesh-network-part-1/
[5] Website – https://www.bluetooth.com/blog/provisioning-a-bluetooth-mesh-network-part-2/
[6] Website – https://en.wikipedia.org/wiki/Bluetooth_mesh_networking
