Note
This is the default configuration of the plgd d2d client. Pre-shared key is generated during startup and no authentication to the plgd d2d client is in place.
There are more ways on how to setup authentication between devices, clients and plgd hub, as various deployment models are supported. It’s all about distribution of right credentials. Same applies for the client applications, which needs to authenticate to communicate with devices.
There are more options on how to initialize the client and provision it with the right security credentials. All depends on the deployment scenarios and use-cases. Let’s go through 2 deployment scenarios:
Requirements:
The device client can be your custom application using a device/client Go library, or a plgd d2d client. In such a scenario, the client generates (or it might be preconfigured) credentials for the device it’s going to provision. The client needs to persist these credentials securely (a pre-shared key). In case credentials are lost (reinstallation, disk failure), a factory reset on the device need to be executed; using it’s hardware button or other device native mechanism. It’s API is not accessible, as the client cannot authenticate.
This is the default configuration of the plgd d2d client. Pre-shared key is generated during startup and no authentication to the plgd d2d client is in place.
Requirements:
This scenario allows all clients which are part of the same security domain as well as the plgd hub to communicate securely with devices. Goal is to have all devices, clients as well as plgd hub trusting each other. Comparing to previous use-case, where the client issues it’s own pre-shared key, this use-case requires distribution of Identity Certificates to all entities (devices, plgd hub, clients). The Identity Certificate, used for authentication identifies users / customers and devices. IDs of these entities are known as owner IDs.
If your deployment scenario requires plgd hub and 1..n clients, read further to understand how to provision client with the Identity Certificate.
The Identity Certificate is issued by the Certificate Authority service, which is part of the plgd hub deployment. Default certificate can be delivered with the hub deployment package or the operator can use custom certificate. This certificate is used for authentication as well as data encryption between plgd hub, clients and devices.
But how to provision the client with the Identity Certificate, issued by the Certificate Authority service?
What is the security domain? All entities, the plgd hub, d2d client or devices, which have the Identity Certificate issued by the same Certificate Authority are considered to be in the same security domain.
This option requires that the plgd d2d client or other application using device/client Go library, can access plgd hub API. The client is required to issue the CSR and send it to the certificate signing service to get the Identity Certificate. After retrieving the certificate and initialization, the client becomes the member of the same security domain. This allows him to successfully authenticate and interact with any device which is member of that security domain.
In case the plgd d2d client or other application using device/client Go library cannot access the plgd hub API directly (e.g. it’s running in a different network as a web service), but the user’s PC can, the CSR can be propagated through the browser to the plgd hub API and the response from the certificate authority service can be returned back over the browser to the client. This flow delivers the Identity Certificate to the client, without private key leaving the client. The client can communicate securely with any devices which is part of the same security domain right after receiving the Identity certificate and its initialization.
plgd makes it simpler to build a successful IoT initiative – to create a proof of concept, evaluate, optimize, and scale.
