Bluetooth^® Mesh Certificate-Based Provisioning

Technical Overview

View Table of Contents

Release :	1.0.0
Document Version :	1.0
Last updated :	September 19, 2023
Authors :	Martin Woolley, Bluetooth SIG Erik Anderlind, KiteSpring Inc. Hannu Mallat, Silicon Laboratories Omkar Kulkarni, Nordic Semiconductor

Revision History

Version	Date	Author	Changes
1.0.0	September 19, 2023	Martin Woolley, Bluetooth SIG Erik Anderlind, KiteSpring Inc. Hannu Mallat, Silicon Laboratories Omkar Kulkarni, Nordic Semiconductor	Initial version

 

Note The Bluetooth Mesh Profile Specification has been renamed and is now called the Bluetooth Mesh Protocol Specification. References in this and related papers will use this name when referring to the version 1.1 specification but continue to refer to the version 1.0 specification as the Bluetooth Mesh Profile Specification.

 

1. Background

Bluetooth Mesh Certificate-based Provisioning was introduced in version 1.1 of the Bluetooth^® Mesh Protocol Specification. To fully appreciate the capabilities and benefits of Bluetooth Mesh Certificate-based Provisioning, it is necessary to understand some aspects of Bluetooth Mesh version 1.0. This section provides context and background which will support the examination of Bluetooth Mesh Certificate-based Provisioning.

1.1 Provisioning

Provisioning is the procedure by which a device becomes part of a Bluetooth Mesh network. Provisioning is carried out by a user during the act of commissioning the network or adding new devices to it. It is often carried out in busy work environments and commonly after devices have been physically installed.

1.2 Device Identification and Credentials

Unprovisioned devices identify themselves with a unique Device UUID. They may also have a unique factory-assigned provisioning code or a static public-private keypair. If present, the (raw) public key does not have a trusted association with the device identity. A device manufacturer may, when supported, provide a code in a human-readable format, support scanning of the code or public key via NFC, or as a QR-code read using the Provisioner’s camera.

1.3 Authentication

The provisioning procedure includes an authentication step which is designed to allow the user of the Provisioner to verify that the device being provisioned (the Provisionee) is the physical device that they intend to provision. This provides protection against human error and the possibility of man-in-the-middle attacks.

Several forms of authentication were defined in version 1.0 of the Bluetooth^® Mesh Profile Specification. As an alternative to utilizing the credentials mentioned above, a random number or letter sequence may be generated, and the end user must input the corresponding sequence. For example, Output OOB authentication requires the Provisionee to output a randomly selected number of some required size using an action that the device supports. Alternatively, the device manufacturer could provide a human-readable or machine-readable Static OOB authentication code with the device. For example, a camera-equipped Provisioner could scan a QR code printed on the device. A Provisioner may also choose to accept authentication using an all-zeros authentication value. A confirmation exchange which involves the authentication value then takes place over the provisioning bearer, and, if successful, this authenticates the Provisionee, and the remainder of the procedure may proceed.

1.4 Practical Issues

There can be certain practical issues with using the authentication options supported in Bluetooth^® Mesh 1.0. A Provisionee device might be out of sight or difficult to see and the options require direct end-user interaction for each individual device. Furthermore, actions such as flashing an LED to indicate the authentication value are only suitable in practical terms, for use with small numbers. Small authentication values provide low levels of entropy and are not particularly secure. Long number sequences can be a burden due to the data entry requirements and can make products more costly if a suitable display is added.

To address these issues, the use of Digital Certificates as a part of provisioning procedure is introduced in Bluetooth^® Mesh v1.1. The next section provides a general overview of Digital Certificates, followed by a section describing specifics for how they are used for Device provisioning.

1.5 Digital Certificates

Digital certificates (certificates for short) are used to verify the claimed identity of an entity. In addition to an identity, each entity has a pair of mathematically related keys. The public key can be freely distributed to anyone, without compromising security. The corresponding private key is never disclosed and is only known by the owning entity. The act of verifying an identity is called authentication, and, in the world of the internet, certificates are the primary way in which servers are authenticated based on domain name or host name. Device certificates are similarly be used to identify a particular device. For example, Bluetooth^® Mesh provisioning uses the combination of a Device UUID and a company (manufacturer) name as the identity.

A certificate is a digital document which contains various fields and values. The X.509 standard defines a format for certificate documents and is commonly used. Certificates work by binding an identity with the entity’s public key value and providing a mechanism upon which a third party can verify that association and thereby determine that the entity they are communicating with is the entity it claims to be.  

A certificate may be created by anyone, but those for which there is a reliable basis for trust being established are issued by a trusted organization, known as a certificate authority (CA). The CA provides confirmation that an entity with a given identity is associated with (bound to) a particular public key value and no other identity is bound to the same key. Essentially, the CA verifies that the entity is who it claims to be. By trusting the CA, we can trust the veracity of all certificates it has issued.

The content of the certificate, the secure procedures by which it is created, and the security practices of the issuing organization all contribute to the trust placed in the CA and therefore in the certificates it issues.

When creating the certificate, the CAs generates a digital signature of the body of the certificate using its private key and attaches the signature to the certificate. It is the presence of this issuer signature, which signifies that the CA endorses the association of the entity name and public key in the certificate. For operational and security reasons, a CA will typically create a chain of one or several intermediate certificates and use an intermediate certificate at the end of the chain to sign the end-entity certificate.

To validate a certificate for authentication, the entity performing the authentication procedure must possess the root certificate of the CA and obtain all intermediate certificates, which it then uses to recursively validate the CA’s digital signature in the certificate. The authenticating entity trusts the CA and in validating the signature can conclude that the identity information and the public key in the certificate can be trusted because the trusted CA has indicated this by its signature.

2. About Bluetooth Mesh Certificate-Based Provisioning

2.1 Capabilities and Benefits

The certificate-based provisioning feature allows digital certificates to be used as the basis for device authentication during provisioning and securely verifies the association of a Device UUID with a specific public key value.

Using certificates to authenticate a device does not require the user to be able to physically see or hear the device during provisioning. Since direct user interaction with a specific device during provisioning authentication is not required, there must be some other method for authorizing devices permitted to join the network, such as assembling a list of authorized UUIDs, candidate device certificate hashes, or continuing to rely on static OOB secret. Certificates offer better security in a number of ways and do not suffer from the low entropy associated with methods such as Output OOB. The practical and potential security issues of using other provisioning authentication methods and actions are alleviated by this feature.

2.2 Technical Highlights

2.2.1 Device Certificates

To use certificate-based authentication during provisioning, mesh devices must have an associated digital certificate, known as the device certificate. This is an X.509 format certificate and it contains the mesh Device UUID value in the X.509 Subject Name field. The device’s static public key is also included in the certificate. The certificate may also contain identifiers for the device vendor and product model.

Device certificates are issued and signed by either a third party CA or the device vendor’s in-house CA. Certificates should contain a field indicating the CA policies they adhere to.

2.2.2 Availability of Device Certificates

Unprovisioned device beacons are broadcast by devices to indicate their availability to be provisioned. This type of beacon includes a field called OOB Information which indicates the availability of OOB provisioning information and the source it may be obtained from. If bit 7 is set, then this indicates that the device supports certificate-based provisioning.

2.2.3 Device Certificate Retrieval

The appropriate device certificate must be available to the Provisioner before the Provisioner sends a Provisioning Invite PDU. Device certificates can come from various different sources.

A device may store the certificate itself and optionally intermediate certificates using a new storage mechanism called provisioning records (see 2.2.4). Provisioning records will otherwise contain a URI indicating an internet protocol and address from which the certificates may be downloaded when required. The specification also explains how other sources such as NFC tags and bar codes can be used to provide the download URI.

Downloading and validating certificates is performed by the Provisioner. Certificate validation is performed in accordance with standard Internet Engineering Task Force (IETF) procedures, according to RFC5280. Intermediate certificates that are part of the complete certificate chain may also be stored in provisioning records. The Provisioner must, directly or through its host operating system, provide a mechanism for loading and accessing CA root certificate(s) for each device vendor so that the certificate signature chain can be verified.

In some circumstances, such as when a mesh network is being installed in a new building, there may be no internet access available. To accommodate this situation, a Provisioner may preload the device certificates before going on site to provision the devices in the new network. Procedures for such certificate caching are not part of the current feature definition.

2.2.4 Provisioning Records

Provisioning records provide a read-only mechanism for accessing stored information to be used during provisioning. There are a number of defined record types, each identified by a 16-bit numeric record ID. For example, a record with ID value 0x0000 contains a certificate-based provisioning URI whereas a record with ID value 0x0001 contains a device certificate.

New provisioning protocol PDUs have been defined to allow provisioning records to be listed or retrieved. Long records are retrieved as a series of fragments using offset and fragment size parameters in the PDU.

2.2.5 Bluetooth Mesh Remote Provisioning and Certificates

The Bluetooth^® Mesh Remote Provisioning feature allows devices to be provisioned even when not in direct radio range of the Provisioner. This has practical benefits, especially when a new network is being commissioned. But it also means that sometimes the devices to be provisioned will not be in sight of the user. In fact, they may be situated ten floors above!

Bluetooth Mesh Certificate-based Provisioning may be used with Bluetooth Mesh Remote Provisioning and solves this problem.

3. Close

Bluetooth^® Mesh certificate-based provisioning provides an industry-standard approach to authenticating devices using a public key infrastructure. Certificates reduce the end-user burden of authorizing devices to join the network and decrease likelihood that rogue devices are added to the network. It complements the Bluetooth Mesh Remote Provisioning feature, which allows unprovisioned devices to be provisioned without them needing to be in direct radio range of the Provisioner application and which may therefore be out of sight and earshot.