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.
plgd ecosystem supports various provisioning scenarios, including Zero-touch provisioning handled by the DPS. It’s your perfect choice when you try to solve:
Provision huge number of devices without hard-coding plgd hub connection
Distribute devices across different plgd hub instances based on custom identifier (e.g. serial number)
Distribute devices to customer specific environments while securing the communication using customer’s custom certificate
Distribute devices based on a use-case to support solution isolation use-cases
Drive custom ACL and Identity Certificate for devices based on a security requirements or use-cases
Reprovision the device when it is not able to connect to the plgd hub
Blacklist devices which were compromised, discontinued, …
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.
Note
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 retrieves connection configuration and OAuth2.0 access token which authorizes the device to communicate with the plgd hub APIs.
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.
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.
Note
Step number 4 and 9 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.
The DPS supports multiple PLGD Hubs or CoAP Gateways. This feature enables users to configure multiple PLGD hubs or CoAP gateways for the device through enrollment group configuration.
To configure multiple CoAP gateways, set the helm value .enrollmentGroups.[].hub.gateways to the list of CoAP gateways in the format SCHEME://HOST:PORT. For example, [ "coaps+tcp://plgd.cloud:5684", ... ].
To set multiple PLGD hubs, set the helm value .enrollmentGroups.[].hubs to the list of PLGD hub objects, which contain the same values as the .enrollmentGroups.[].hub object in the enrollment group configuration.
Note
For multiple hubs, it is expected that the hubs are different instances.