Note
To govern the issuance of digital certificates in a scalable way, public key infrastructure (PKI) is required.
Most important part of the zero-touch provisioning is the attestation mechanism, a method used to confirm a device’s identity. Each enrollment group needs to have the attestation mechanism configured. Selected method and it’s configuration is used to identify to which enrollment group the device opening the connection to the DPS belongs to. The Device Provisioning Service supports 2 forms of attestations:
Digital certificates allow individuals, organizations, as well as devices to establish trust in the digital world. As the foundation for all digital identities, X.509 certificates are everywhere and are essential to every connected process from websites to applications to devices and online documents. This level of trust is established both by how X.509 certificates work and by how they are issued. The key usage architecture lets certificates verify that:
When a certificate is signed by a trusted CA, the certificate user can be confident that the certificate owner has been validated.
By using X.509 certificate as an attestation mechanism, a device’s manufacturer certificate is used to verify it’s identity. This certificate is typically arranged in a certificate chain of trust in which each certificate in the chain is signed by the private key of the next higher certificate. This arrangement establishes a delegated chain of trust from the CA certificate down through each intermediate CA to the manufacturer, end-identity leaf certificate installed on the device.
The way how the certificate chain of trust is built is usually reflected by the physical or logical hierarchy of your devices / products. For example, a device manufacturer may:
To govern the issuance of digital certificates in a scalable way, public key infrastructure (PKI) is required.
The manufacturer certificate is the leaf certificate signed by the manufacturer’s root / intermediate CA. It uniquely identifies the device. This certificate is used only during the provisioning process to verify that the device was manufactured by that particular company. The device connecting to the DPS needs to authenticate using this client certificate during what the DPS verifies it’s the public key against the root CA / intermediate CA registered in the matching enrollment group. The device must present the leaf certificate or the certificate chain from leaf certificate all the way to the certificate verified with proof-of-possession, otherwise authentication will fail. Successful verification of the public key results in successfully connected device, developed by the declared manufacturer, eligible for the provisioning. Verification of the DPS server certificate by the device is configurable. To learn more, see DPS Client API. Successfully provisioned device switches from using Manufacturer certificate to Identity certificates, both for communication with the plgd hub / other devices in the network or when connecting to the DPS service again.
To uniquely identify each device it’s recommended to set the certificate common name (CN) to a unique product identifier, e.g. serial number. This allows you to whitelist or blacklist devices, what’s configurable on the enrollment group level. To know more about this feature, see Whitelisting / BlackListing.
A certificate chain is a list of certificates followed by one or more CA certificates. In RFC 5280 the certificate chain or chain of trust is defined as “certification path”. In other words, the chain of trust refers to your certificate and how it is linked back to a trusted Certificate Authority. In order for a certificate to be trusted it has to be traceable back to the trust root it was signed off, meaning all certificates in the chain—server, intermediate, and root, need to be properly trusted. There are three parts to the chain of trust:
Certificate chains are used in order to check that the public key and other data contained in an end-entity certificate (the first certificate in the chain) effectively belong to its subject. In order to ascertain this, the signature on the end-target certificate is verified by using the public key contained in the following certificate, whose signature is verified using the next certificate, and so on until the last certificate in the chain is reached. As the last certificate is a trust anchor, successfully reaching it will prove that the end-entity certificate can be trusted.
Part of the enrollment group configuration is the certificate chain, used for both authentication and enrollment group selection. The device authenticating against the DPS is required to provide the certificate chain from the end-entity certificate up to a the leaf-most certificate present in the certificate chain configured on the enrollment group. Otherwise the authentication will fail.
For example, consider a manufacturer uses the following certificate chain:
If the device sends the following manufacturer certificate chain:
… while the certificate chain configured on the enrollment group looks like:
authentication fails because the DPS can’t attempt authentication assuming the validity of the Intermediate CA #2.
If the device authenticates using the manufacturer certificate chain containing certificates up to Intermediate CA #2, or the certificate chain configured on the enrollment group would contain certificates up to Intermediate CA #2, the authentication would be successful.
The DPS supports creation of multiple enrollment groups what allows the operator to distribute devices based on the Intermediate CAs. When configuring the certificate chain on the enrollment group, an operator has a possibility to select a certificate from the chain to represent the enrollment group during the search. Selection of the enrollment group is done after successful device authentication, after which the full verified certificate chain is assembled. Search for the matching enrollment group starts by taking the leaf-most intermediate certificate from the verified certificate chain and finding the match across list of certificates representing enrollment groups. If no match was found, the next parent authority certificate from the verified certificate chain is taken and search is repeated. This process is repeated until last root CA certificate present in the chain is reached. If there wasn’t any match across enrollment groups, the device is disconnected.
For better understanding, consider 2 enrollment groups configured on the DPS (certificate with yellow border represents the enrollment group):
Enrollment Group #A
Enrollment Group #B
The device after it authenticates using the following manufacturer certificate chain:
will be provisioned as configured in the Enrollment Group #A.
The device after it authenticates using the following manufacturer certificate chain:
will be provisioned as configured in the Enrollment Group #B.
The device after it authenticates using the following manufacturer certificate chain:
will be disconnected as no matching enrollment group was found.
plgd makes it simpler to build a successful IoT initiative – to create a proof of concept, evaluate, optimize, and scale.
