Azure IoT Device Provisioning with TPM (DPS)

When it comes to the rollout and deployment of IoT devices in the field, customers often experience a bunch of challenges. One of them is the fact, that in most situations you need to have a qualified engineer in the field who can analyse and solve issues that might occur due to unexpected conditions. Assuming, that you have a well-qualified and experienced engineer that is deploying your devices, we are still talking about a human, not a zero-failure machine. So, either way there is a chance that something goes wrong due to human interactions beside the fact, that you have a higher risk to be compromised somehow.

If you think this trough in different deployment environments and scenarios, there are more challenges like the above mentioned which can be imagined.

The Device Provisioning Service (DPS)

To attack these challenges Microsoft provides a service called “Device Provisioning Service” (DPS) which takes care of your rollout challenges in the field.

You can use the DPS to:

• Register your Devices
• Connect and route your devices to a specific IoT Hub
• Specify your enrolment scenarios and settings
• Deploy your docker based applications to the IoT Edge-Runtime

The service itself only must be configured once for your entire IoT environment and can be connected to different IoT Hubs based on geo-locations, traffic routing or many more. Once you have established your instance of the DPS, you can identify it by the global unique Scope-ID. In general, the service provides a just-in-time deployment without touching every single device one by one. So, in fact it does not really matter if you want to deploy ten, hundreds or even millions of devices. The process of the deployment is the same and scales with your infrastructure and number of devices.

The DPS offers two ways of deployment scenarios:

• Individual enrolment
• Group enrolment

Group enrolment does not support TPM attestation and will therefore not be covered in this document.

Individual enrolment

Individual enrolments are designed to pre-define a device with specific settings, even before you bring it into the field. As for attestation mechanisms you can choose between x509 certificates, SAS-Token or TPM.
Since TPM is the most secure way but therefore also the most challenging for the customer, we at Welotec took care about these fact in the implementation of our IoT Edge Gateways.

Trusted Platform Module (TPM)

Before we start, lets clarify a few things about the Trusted Platform Module (TPM). In general, the TPM is a hardware chip that is part of the mainboard of Welotec Edge Gateways. The TPM can be used for secure-boot, store security sensitive data like Keys, Certificates and many more. When it comes to provisioning scenarios, especially at Azure DPS, only the Registration-ID as well as the Endorsement-Key (EK) is relevant. The Registration-ID is an alphanumeric string and provided by the TPM itself. The Endorsement-Key is created during the manufacturing process and is unique for a TPM. It consists of two parts, a public and a private part. As usual, but most important, the private one is never exposed outside of the TPM. This leads to the fact, that the TPM module is often treated as some kind of “hardware-anchor” or “hardware-security-anchor”.

For more information check the Azure website: https://docs.microsoft.com/de-de/azure/iot-dps/concepts-tpm-attestation

Provisioning of Edge Gateways

When we are talking about provisioning of IoT devices – more specific “auto-provisioning”, different roles take place in this concept. Based on where you and your company are based in regards of the roles, different operations should belong to you or should be left for others. But if you look at a real-world use-case, this concept and it´s boarders and responsibilities are not that easy to apply. Therefore, we implemented the provisioning services to have the highest flexibility, usability, and security for our customers.

Considering attestation with TPM, you need three values:

• DPS Scope-ID – global ID
• Public Part of EK – device specific
• Registration-ID – device specific

We can deliver the Edge Gateways to the customer with a pre-defined configuration that e.g. contains his DPS Scope-ID. As an alternative, you can of course place it by yourself.

• DPS Scope-ID – done

Afterwards you want to extract the relevant public part of the EK and the Registration-ID from your TPM.
To do so, again just execute one single command. The command will fetch the data from your TPM, so you can easily paste them into Azure.

• Public Part of EK – done
• Registration-ID – done

The next and final step is to create an individual registration for your new device. You can specify right away which Device-Twin state it should have, which modules should be deployed and to which IoT Hub the device should connect. After this is done, your device connects to the DPS, receives proper deployment parameters, connects to the IoT Hub, fetches assigned modules for example Containers for the Azure Edge Runtime and starts operating.

The 3 steps you need

1. Set DPS Scope-ID
2. Extract registration data from TPM
3. Create registration

Summary:

If security, authenticity as well as flexibility is important in your rollout, DPS provisioning using TPM attestation is a good decision. It may sound difficult in the first step, but as you can see, it does not have to be. Find out more about Azure IoT Edge.

Azure IoT Edge Appliance

You can learn more about the Azure IoT Edge Appliance EG500 and EG600 here. If you need further information about Edge computing, IoT Hub and IoT Central with Azure please get in contact with us.