Devices Enrollment To Azure IoT Hub Using Azure Device Provisioning Service (DPS)

Published in

Globant

11 min readJul 25, 2024

I recently had the opportunity to participate as a DevOps engineer in a project. The project involved designing and implementing an IoT solution to provide automated processes for enrolling and managing IoT devices and automatically deploying applications to those devices.

In this article, I will share my experience using Azure IoT Hub and Device Provisioning Service (DPS) to solve the mass enrollment for IoT devices.

This client already had an IoT solution launched using Raspberry Pi 3+ hardware as an IoT device. Within each IoT device were web applications and databases deployed from binaries. If an IoT device needed to be replaced or a web application or database needed to be updated, the support engineer had to perform those actions manually on one or all the devices.

For these reasons, the client was looking for an intelligent solution that would allow it to meet its needs using a stack of technologies and resources in Azure that was easy to implement.

The first challenge was to design a cloud-based IoT solution that would enable mass enrollment of IoT devices using a standard, automated mechanism that was easy to configure. The second challenge was to design a cloud-based IoT solution that would allow the automatic build of web applications and databases using standards-based tools, and that would also allow automatic deployments over groups of IoT devices.

Prerequisites

It is suggested to take a look at the following concepts to have a basic knowledge and understanding of the Azure services to use, as well as to be familiar with the terminology used:

Brief Description Of The Solution

The following diagram shows how DPS interacts as middleware to allow the enrollment of IoT Devices to Azure IoT Hub:

This diagram shows the process of enrolling an IoT Device (Raspberry Pi 3+) to an Azure IoT Hub using the Device Provisioning Service

The use of DPS allows the bulk mass registration of devices. This is not a “plug-and-play” or “automatic” process. Performing specific manual actions on each device and Azure subscription is necessary to ensure that the IoT Hub can properly identify devices and streamline the enrollment process for multiple devices.

There are key aspects to consider in ensuring successful enrollment between IoT Hub and the devices, that we are going to discuss next.

Devices Configuration

Every IoT Hub enrollment requires the provisioning and configuration authentication credentials and the assigned device provisioning service ID and endpoint. To accomplish this, we have to perform the following tasks:

Device Provisioning Service setup

When a DPS is created on Azure, it uses two key values. These values are the Global device endpoint and ID Scope :

The following image shows the structure for a DPS page in the Azure Portal. You can find in the Overview tab, the location for both Global device endpoint and ID Scope parameters:

*Overview tab for DPS page in Azure Portal*

IoT Edge Configuration File

IoT Edge uses the config.toml file to initialize settings for the device. The file can be found in the /etc/aziot/config.tomlpath. Each of the sections of the config.toml file has several options. Not all options are mandatory, as they apply to specific scenarios. To use the DPS, we just need to set up the following parameters:

[provisioning]
source = "dps"
global_endpoint="https://global.azure-devices-provisioning.net/"
id_scope="0ne000705x8"

[provisioning.attestation]
method="x509"
registration_id="182-con"
identity_pk="file:///var/lib/aziot/keyd/182-con.key.pem"
identity_cert="file:///var/lib/aziot/certd/182-con-full-chain.cert.pem"

Use of a Full-chain X.509 Certificate

A full-chain certificate is required to register IoT devices through the DPS using enrollment groups. To achieve successful enrollment, the IoT device sends the certificate chain to compare with the certificates configured in the DPS. If the IoT device certificate is successfully verified, the DPS completes the enrollment and recognizes the management device. Otherwise, if the verification fails, device enrollment stops. The full-chain certificate has the following hierarchy:

Let’s review each of the hierarchy’s elements:

The important thing about working with full-chain certificates to ensure successful DPS enrollment is to pay special attention when creating the private key and CSR certificate for each device with its respective common name. The subject’s Common Name (CN) of the device certificate must be set to the registration ID that the device will use to register with DPS. In IoT Hub, the device ID for group enrollments is the same as the registration ID.

This project involves a defined workflow to help me create the X.509 certificates for IoT devices, describing roles and tasks. In this workflow, two roles are involved. IoT Device Manufacturer and Certified Authority. Both roles can be executed by different departments in the same company, or each role can be a department in different companies. In my project, both roles were inside the company. The IoT Device Manufacturer was the IT Department, and the Certified Authority was the Security Department.

Workflow to generate X.509 certificates for IoT Devices

From the IoT Device Manufacturer side, the first step is to execute the following OpenSSL instructions to perform the three tasks related to the creation of the CSR file:

:~$ openssl genrsa -out ./private/device-01.key.pem 4096
:~$ openssl req -new -key ./private/$device_id.key.pem -subj '/CN=$device_id' -out ./csr/$device_id.csr.pem

Now, suppose we are IoT Device Manufacturers, and creating certificates for an IoT device named “182-con” is essential. The OpenSSL commands for creating a private key and CSR files look as follows:

:~$ openssl genrsa -out ./private/182-con.key.pem 4096
:~$ openssl req -new -key ./private/182-con.key.pem -subj '/CN=182-con' -out ./csr/182-con.csr.pem

The following image shows the output for files after the commands were executed:

*Example of private key and csr files created for an IoT Device*

Next, the CSR must be signed by the Certified Authority (in this case, the Security Department). Once the CSR is signed, the CA returns the device certificate in .pem or .crt formats or to the IoT Device Manufacturer:

Finally, the IoT Device Manufacturer takes the signed .pem certificate for the device and creates the full-chain certificate using the root CA and intermediate CA certificates. The full-chain certificate must include all of these certificates:

:~$cat ./$folder/tmp_signedcerts/$device_id.pem root_CA.cer intermediate_CA.cer > ./$folder/certs/$device_id-full-chain.cert.pem

Following the example, the command for creating the full-chain certificate for an IoT Device is as follows:

:~$cat ./$folder/tmp_signedcerts/$182-con.pem root_CA.cer intermediate_CA.cer > ./$folder/certs/$182-con-full-chain.cert.pem

When finished, the IoT Device Manufacturer should have a pair of files like the following: 182-con.key.pem and 182-con.full-chain.cert.pem:

Example of a full-chain certificate created

These files should only be copied to the IoT device for which they were created. Remember that the Device ID is the same name defined in the CN and is the name that will be used to identify the IoT device once it is attached to the enrollment group in the DPS.

The following image shows the output of a full-chain certificate created with OpenSSL commands:

*X.509 full-chain certificate output for an IoT Device*

The two key aspects to review after creating the certificates are the values of the Issuer and CN parameters, respectively. The values of the Issuer parameter come from the root or intermediate certificates. It is also important to verify that the value of the Subject Common Name parameter is the same as that of the IoT device to be enrolled. This guarantees the right identification of the IoT Device in the DPS and the IoT Hub.

Creation of Azure IoT Hub

Azure IoT Hub is a cloud-hosted managed service that acts as a central message center for communication between an IoT application and its connected devices. You can connect as many devices as you need to their backend solutions reliably and securely. I will not go into details about the creation of the IoT Hub. Please refer to the following link to review how to create an Azure IoT Hub.

Once the IoT Hub was created, I could perform actions for device management through the Azure console. In this case, I used it as a centralized hub and console where I could manage all the linked IoT devices by checking their connectivity state as well as the deployment history for each IoT device:

Overview for IoT Hub page in Azure Portal

Later I will show how the IoT Hub page looks when IoT devices are connected.

Creation and Configuration of the Device Provisioning Service Instance

Once the IoT Hub is created, the next task is to create a Device Provisioning Service in Azure. The Device Provisioning Service can only provision devices to IoT hubs that have been linked to it. Linking an IoT hub to a DPS instance grants read/write permissions to the IoT hub’s device registry. The DPS will help enroll IoT devices into the desired IoT Hub by using enrollment groups. An enrollment group is a group of devices that share enrollment information, such as:

The attestation mechanism used by the device (X.509 certificate).
The optional initial desired configuration (IoT Edge Runtime configuration).
The desired IoT hub (The IoT Hub selected to link the devices).
The desired device ID (The name of the IoT device).

Creating a DPS is simple, please refer to the following link to see how to create a DPS.

The following image shows how to create a DPS resource in the Azure portal. At the beginning of the process, it is crucial to define the name of the DPS instance, as well as the values for the Azure subscription and the resource group where it will be hosted:

*Creation of a DPS instance in Azure Portal*

The important keys to pay attention to after creating the DPS are the following:

Link the IoT Hub to the DPS instance: Specify the name of the IoT Hub to link with the DPS instance. By doing this, all IoT devices enrolled through DPS will be managed by this IoT Hub:

Add the CA certificates to the DPS instance: Using a CA certificate as part of a certificate chain grants the permissions required to generate device certificates (leaf certificates) for IoT devices that will be registered in the enrollment groups defined in DPS. Upload an intermediate certificate or root certificate for each DPS instance:

*Adding and verifying Root certificates*

The following image shows the certificates added to DPS. You can see all certificates in the Certificates section of the DPS page in Portal Azure:

The X.509 certificates listed in the “Certificates” section on the DPS instance page after uploading

Create an enrollment group: The root or intermediate certificate configured in an enrollment group must be a verified certificate or must be part of a verified certificate in the certificate chain that an IoT device presents when it authenticates with the DPS service:

*Creation of an enrollment group on DPS using X.509 Root and Intermediate certificates*

After defining the attestation mechanism and the X.509 certificates involved, it is mandatory to link the new enrollment group with the IoT Hub used as the destination for all IoT devices enrolled in this group:

*Link the IoT Hub associated with the enrollment group*

All the enrollment groups created for a DPS instance are listed in the Manage enrollments section. Here, you can see a brief description of each enrollment group showing the group name, the attestation mechanism used, the state of the enrollment group, and creation and update dates:

*List of enrollment groups created for a DPS instance*

Provisioning IoT devices using the IoT Edge Runtime CLI

After the IoT Hub and DPS have been successfully configured, the last step is to execute the IoT Edge CLI instructions to provision each IoT device. Remember that you previously configured the config.toml file with the settings for the DPS. To do the provisioning, run the following command:

:~$ sudo iotedge config apply -c ‘/etc/aziot/config.toml’

*The output of the IoT Edge Runtime CLI command to provision an IoT device (Raspberry PI3+) to the DPS instance using config.toml file*

Once the IoT devices are successfully enrolled, you can see them in the Azure Portal by going to the IoT Hub page to review the list of linked devices as well as the connection status:

*List of IoT Devices linked to an IoT Hub in Azure Portal*

Azure IoT Hub was created to have a centralized console where it is possible to manage all linked IoT devices. Once the IoT Hub is properly configured with the Device Provisioning Service, it is possible to manage each one of the IoT devices. As I mentioned, the definition of the Common Name is crucial to help identify the IoT Devices enrolled in the IoT Hub.

Next, you can see the relationship between the full-chain certificate, the config.toml in the IoT Device for enrollment, and the IoT Device enrolled in the IoT Hub:

Example of a full-chain certificate for an IoT Device named “182-con”

The following image shows the configuration file for the IoT Edge runtime inside the IoT Device. This file contains the settings for enrollment with the DPS:

*Example of confg.toml inside IoT Device named “182-con”*

The following image shows the page for the IoT Hub resource in Azure Portal. You can check the overview of the IoT Hub and manage the IoT Devices linked to this IoT Hub:

*Example of IoT Device named “182-con” enrolled and connected to IoT Hub via DPS*

This procedure allows the enrollment of several IoT Devices (Raspberry PI3+) to a specific IoT Hub using DPS and enrollment groups. When the enrollment is completed, you can manage all your IoT Devices using the IoT Hub page in Azure Portal:

*List of IoT Devices linked to an IoT Hub by using DPS and enrollment groups*

Conclusion

After I completed implementing the solution for mass registration of IoT devices, I can assure you that Microsoft has powerful tools in Azure for IoT. When I started reading Microsoft’s documentation on this topic, I wondered what they meant when they discussed mass enrollment. I thought it was anything like connecting all your IoT devices to the network, turning them on parallelly, and waiting for Azure IoT Hub to “magically” find them.

But in reality, it is not like that. It is necessary to perform several manual configuration tasks on each device. The important thing here is to understand how the Azure IoT Hub and DPS are integrated, besides the use and importance of certificates. Once this relationship has been understood, it becomes easy to know the configurations to make, and the “magic” happens. Another essential point is to clearly understand the provisioning mechanism, in this scenario the use of DPS was selected, and the configuration of the config.toml file required a few parameters.

Finally, the successful creation of leaf and full chain certificates for each IoT device allows for easy enrollment and quick identification of all devices within the IoT Hub. All this allowed me to define the process and the series of procedures delivered to the client so that they could independently register the IoT devices that were necessary to be deployed.

In the first phase, pilot tests were developed in production to enroll 10 IoT devices in the IoT Hub, and the planned projection was to enroll 150 devices in total.