Theoretical Background#

Certificates#

A digital certificate is simply a small, verifiable data file that contains identity credentials and a public key. That data is then signed either with the corresponding private signing key, or a certificate authority’s private signing key. The digital certificate can be used to prove the ownership of a public key.

  • If it is signed using the corresponding private key, it is called a self-signed certificate.

  • If it is signed by another private key, the owner of that private key is acting as a Certificate Authority (CA).

  • A Certificate Authority (CA) is a trusted third party by both the owner and party relying on the certificate.

Concatenation of digital certificates builds a chain of trust.

  • At the root of the chain is a self-signed certificate called a root certificate or a CA certificate.

  • The root or CA certificate can be used to sign another certificate.

Digital Certificates and Chain of TrustDigital Certificates and Chain of Trust

The private key is never included as part of the certificate. It must be stored separately and kept private. The security of the scheme relies on protecting the private keys.

Key Usage#

Version 3 of the X.509 standard provides the ability to restrict the purposes that a certificate’s public key can be used for. Bluetooth Mesh CBP certificates must allow the ‘Key Agreement’ usage for the public key. This allows a shared secret to be established between the provisioner and provisionee.

To learn more about certificates, see AN1268: Authenticating Silicon Labs Devices Using Device Certificates, which addresses certificates in detail.

Bluetooth Mesh Certificate-Based Provisioning#

Bluetooth Mesh Provisioning is described in the Bluetooth Mesh 1.1 Protocol specification. Refer to this document for specifics of provisioning messages and certificate requirements. A certificate chain is used as the out-of-band (OOB) data for provisioning. Provisioning related information is stored on a device as provisioning records. The device certificate can either be requested from the device during provisioning or obtained by the provisioner from a URI indicated in the provisioning record. The provisioner requests the device certificate by sending a Provisioning Record Request message with the ID set to ‘Device Certificate’ to the device to be provisioned. The provisionee responds with a Provisioning Record Response message which includes a device certificate. If intermediate certificate(s) are present, they will be requested by the provisioner and sent one at time. Up to fifteen (15) intermediate certificates can be used in the certificate chain. The provisioner verifies the certificate chain before proceeding with the provisioning process. In case the certificate chain cannot be verified, the provisioning process is terminated.

Obtaining Device Certificates from URI#

Device certificates and intermediate certificates may be retrieved by the provisioner from the internet using HTTPS protocol. The base uniform resource indicator (URI) of the device certificate can be included provisioning record.

Requirements for Provisioners and Devices#

The provisioner of the network must store the root-of-trust certificate for each chain of trust. The root certificate must not be sent from device to provisioner during the provisioning process nor be able available for retrieval from the URI. It is the responsibility of the provisioner to ensure the integrity of the root-of-trust certificate.

Verifying the Device Certificate#

The provisioner must verify the authenticity of the device certificate received. In addition to verifying the authenticity of the certificate, as defined in RFC5280, the Bluetooth Mesh protocol specification requires that the following criteria must be met:

  • The device certificate must be verifiable, directly, or indirectly, by the root CA

  • The device certificate is not expired

  • The device certificate has not been revoked by any certificate revocation list (CRL)

The following table summarizes the fields of the device certificate which shall be present:

Certificate Field Requirements

tbsCertificate

As defined by RFC5280 with additional requirements as defined in this table

signatureAlgorithm

Set to “ecdsa-with-SHA256”

SignatureValue

Signature computed as in RFC5280

Version

“2”

serialNumber

Must meet the requirements detailed in RFC5280

issuer

Identifies the signer of the certificate. See RFC5280.

validity
  • notBefore time should not be earlier than the manufacture date of the device
  • notAfter time shall be set by the manufacturer

subject

Shall contain a valid distinguished name (DN) with the following restrictions:

  • organization name of the DN shall be set to the vendor name
  • common name of the DN shall contain the device UUID

subjectPublicKeyInfo

As defined by RFC5280 with the following constraints:

  • algorithm field shall contain “id-ecPublicKey” as the algorithm and secp256r1 curve as the parameters. See RFC5480 for details.
  • subjectPublicKey field shall contain the public OOB key of the device

basicConstraints Extension
  • cA field shall be present and set to FALSE
  • pathLenConstraint shall not be present

keyUsage Extension

keyAgreement bit shall be set as defined in RFC5280

The following table summarizes the optional fields in the device certificate which may be included. These fields shall be used as defined in RFC5280 without additional constraints.

Optional Certificate Fields

Authority key identifier

Subject key identifier

Certificate policies extension

Issuer Alternative Name

Subject Directory Attribute extension

CRL distribution points extension

Freshest CRL extension

Authority Information Access extension

Subject Information Access extension

All other fields defined by RFC5280 shall not be present in the device certificate.