Provisioning millions of devices in a secure and scalable manner without requiring any human interaction is what our plgd Device Provisioning Service (DPS) solves. Doesn’t matter if you’re running the plgd hub on-premise, off-premise or a fully managed instance, the DPS makes sure it trusts only your devices and provision them to the right plgd hub instance. Exactly no human interaction, zero-touch to provision and pre-configure millions of devices just-in-time and securely, using manufacturer certificates or TPMs.
To successfully attest the device’s identity during the provisioning process, a manufacturer certificate or/and a TPM need to be available on the device. It’s a key to verify if the device is trusted and belongs to the enrollment group created in the DPS.
Creation of the device’s manufacturer identity usually occurs towards the end of the manufacturing process. At this point, hardware assembly is complete and the initial software has been loaded. A manufacturing PC is connected to the device and requests from the PKI a unique manufacturer certificate using the unique device identifier (e.g. serial number, depends on the manufacturer). In case the device contains the TPM, manufacturing PC stores the TPM’s endorsement key, required for it’s individual enrollment.
Process described above varies from manufacturer to manufacturer. Nevertheless, the unique device’s manufacturer identity is expected as the result. Additionally, formulation “Creation of the device’s manufacturer identity” was used to not confuse the reader if using more accurate term - “Provisioning of the device’s manufacturer identity”.
DPS does not introduce a new step in the manufacturing process. It ties into the existing step creating the unique identifying key information - the device’s manufacturer certificate or TPM’s endorsement key used for device attestation during the zero-touch provisioning by the DPS.
Creating an Enrollment Group in your plgd DPS instance is required in order to make sure the DPS can properly attest to the device’s identity when it comes looking for its provisioning configuration. The operator is responsible to include the identifying key information described in the manufacturer step and add it to the enrollment group. Part of the enrollment group configuration is among others also initial resource and ACL configuration, useful for the device-to-device scenarios where the plgd hub is not involved at all. Once the enrollment group is configured, DPS is ready to automatically provision devices. Unless the use-case or list of devices changes, the DPS service / enrollment group does not have to be modified. Number of enrollment groups is not limited; different set of devices can be attested by different enrollment groups containing different provisioning configuration.
The Enrollment Group created during the operation setup state has a set of required and optional configuration options, supporting various use-cases or security requirements. The following sequence diagram describes what goes on under the hood to get a device securely provisioned. This flow is dependent on the Enrollment Group configuration, which is a prerequisite.
The device application or external tool which discovered the device using CoAP multicast requests the DPS Client to start the provisioning process by setting the DPS endpoint. The DPS endpoint can be also configured at the factory.
The device opens the connection to the DPS and proves it’s identity using a Manufacturer Certificate or TPM’s endorsement key.
The DPS finds the Enrollment Group with matching Manufacturer Certificate CA or TPM’s endorsement key.
In order to validate TLS certificates and rotate them, the device synchronizes its clock with the DPS by obtaining the current time.
The device’s owner is granted access by the DPS, enabling the device to operate in Device-to-Device scenarios.
The device issues Certificate Signing Request (CSR) for the unique device Identity and requests the DPS to sign it. The CSR is signed by the separate service, running next to the DPS or within the plgd hub deployment. Custom Identity CA can be used. Identity Certificate is then securely stored on the device and used to for unique identification and secure connection to the plgd hub.
The device requests resources’ ACLs for the Device-to-Device as well as Device-to-Cloud communication and applies them.
If the operator provided initial configuration for device resources, the devices retrieves and applies it.
The device retrieves connection configuration and OAuth2.0 access token which authorizes the device to communicate with the plgd hub APIs.
The device connects to the configured plgd hub instance, authenticates and encrypts the session using Identity Certificate and authorizes using the OAuth2.0 access token.
Step number 4 and 10 are optional.
Time synchronization is not required when device is synchronized time by another method like NTP. In such a case, the device can skip this step.
Device provisioning doesn’t require to connect the device to the plgd hub. In such a case, device is ready to be securely used for your Device-to-Device scenarios.