Integrating devices with IIoT platforms

In this article:

• You will learn how to integrate your devices with Industrial IoT (IIoT) platforms.
• You will get an overview on prepping device SW to enable zero-touch device setup so your devices can start working with the platform automatically once deployed to the field.
• You will get an understanding of why the common method of using one secret to authenticate your devices with the platform is inflexible, insecure, and error-prone. We will explain some alternatives.

Why is this important?

• Manually setting up your devices in the field results in significant labor costs.
• There is no need for an experienced workforce to set up a new device if you use an automated way. A technician moves a device to the field, powers it up, and connects it to a network. That’s it. Connectivity with the IIoT platform is established automatically without requiring manual configuration.
• Manual device setup is prone to errors.
• When selecting an IIoT platform, it must fit your device manufacturing process. Some functionalities, such as programmatic provisioning of secrets, are necessary during factory operations.

For the sake of this article, we assume that your devices are already capable of connecting to the outside world, such as the Internet network. That can be achieved by equipping your device with, e.g., Wi-Fi or SIM modules.

Options for integrating devices with IIoT platforms

Generally speaking, there are two options for integrating devices with IIoT platforms:

• Embedding IoT protocol clients into device SW.
• Embedding platform-specific Device SDK into device SW.

IoT protocol clients

The platforms typically support a range of IoT protocols enabling your devices to interact with them, such as MQTT or AMQP protocols. Your device software developers can include support for these protocols in the device software, allowing you to configure a connection to your selected platform in case the platform supports the protocol. For instance, you can add the "Eclipse Paho MQTT client" for the C language to a device SW.

Remember that even if protocols are standard, each platform requires a different contract, e.g., message payload format, MQTT topic names, etc. Also, the platform's functionality is evolving, and (security) bugs are being fixed.

It is hard to keep the protocol client updated and secure.

Device SDKs

Certain platforms offer Device SDKs as a part of their offering. Device SDKs are the libraries meant to be installed on your device SW. The purpose of a Device SDK is to enable the functionalities of an IIoT platform without additional coding. Device SDK typically bundles protocol libraries to establish a connection with the platform.

It is worth noting that Device SDKs are specific to the platform vendor. However, if you have already chosen a partner to supply the platform, you can confidently incorporate it into your device SW. In addition to the basic integration offered by the protocols mentioned earlier, Device SDKs provide platform-specific features that can be used immediately without additional development.

A comprehensive comparison of the Device SDK approach and approach via IoT protocol clients is out of the scope of this article.

Integrating devices using Device SDK

You downloaded a Device SDK for your selected platform and are ready to start. Great! To ensure the security of your devices and protect them from potential security threats, they need to authenticate with the platform. There are several ways to achieve device authentication, but we will focus on token-based authentication for now.

In simple terms, token-based authentication involves putting a secret string into your device's software. This string is needed to authenticate a device with the platform so it can connect. We recommend including the string in your device's software image so all your devices manufactured in the future are platform-enabled and can connect to the platform without your intervention. Remember that this secret is designed never to expire. The expiration of this top-level secret would disconnect your devices from the platform, rendering them unavailable. For devices already deployed in the field, a visit by a technician may be required to update the secret. However, this may not always be feasible, especially if you have dozens of devices spread across the globe.

Using one secret to authenticate your devices with the platform is inflexible and insecure if used in production. Using this approach in the development stage or in your PoC is okay.

We suggest implementing a more secure and flexible approach. Let's jump straight into the whole process to gain a better understanding.

We use Spotflow IIoT platform in the example. Even though concepts will be similar in other platforms, the implementation can differ.

1. When a device is manufactured, the SW image is uploaded to the device. It includes device SW with Device SDK installed and preconfigured with top-level secret. We will call this token “Provisioning Token“ (PT).
2. The device is deployed to the desired location and starts the device software. Device SDK requests access to the platform.
3. An on-site technician installing a new device approves access to the device, usually using the platform's UI interface by simply hitting the button or entering the verification code shown on a display of the actual device.
4. Once approved, the device receives a “Registration Token” (RT) with limited configurable validity.
5. The device registers in the platform using the RT.
6. The device starts working with the platform. E.g. sending data to it.
7. Device SDK automatically refreshes the RT using top-level secret.

We touched upon a few more concepts and artifacts. Let me summarize its functions:

Provisioning Token (PT)

It is a top-level secret (token) embedded into the devices when manufactured. The token has unlimited validity and can only be used to request an RT. It’s recommended to have one PT per device.

Registration Token (RT)

It is a secret obtained after successful device provisioning. It bears the device's identity (device id) in the platform. It usually has a limited lifetime and needs to be periodically refreshed. However, the lifetime can vary from days to months to support IoT devices that can be offline for extended periods.

Provisioning Operation

An attempt from a device that would like to receive an RT. It starts in a pending state and must be approved by a human. The safest way for the technician to determine whether the provisioning operation is legitimate and can be approved is by reading the Verification Code from the device's display. Optionally, the device can also send arbitrary attributes about itself to prove it is eligible to receive credentials for the platform. Only after successful approval, the device receives a valid RT containing the identity of the device.

What is happening on the backend?

Curious about what's going on under the hood? Let's explore a simpler scenario without using Verification Codes displayed on devices (not all devices have displays).

1. PT is created and embedded into one or more devices.
2. The device starts up and initializes a new provisioning operation using PT.
3. The device periodically starts polling the complete provisioning operation endpoint using the provisioning operation id from step 2.
4. A technician lists pending provisioning operations, validates the request, and approves or rejects it.
5. The device gets a successful response from the complete endpoint with the registration token.
6. The device registers in the platform using the registration token from step 5.

Here is the flow visualized:

The process seems complex and may have room for error. It would require a considerable development effort to implement, especially when covering all the possible edge cases, such as multiple parallel provisioning operations caused by firmware bugs or malicious third parties. However, the good news is that the entire process is already implemented in the Device SDK that comes with the platform. You only need to create PT in the UI and embed it in your device. The Device SDK will take care of everything else.

BONUS: What if secrets are compromised?

Given the nature of environments to which IoT devices are deployed, the risk of leaking secrets is always present. No matter whether we’re talking about our example with PT and RT, or X.509 certificates.

Secure IIoT platform should provide users with tools that allow them to detect leakage and let them disable compromised devices.

Following the example of the provisioning process in Spotflow IIoT platform, the platform allows the revocation of the PT or/and the RT from the cloud. Revoking PT is the safest option. However, in a real-world scenario, it would require that each device has its own PT. Otherwise, if one PT is used by many devices and is revoked, it would render the devices unavailable. For such a situation, the RT for the device can be revoked. Once revoked, the platform features become unavailable for the device, and the device is forced to start a new provisioning operation. During the approval process, a technician can reevaluate a device's eligibility and potentially block access to the platform.

Best practices for integrating IoT devices with IIoT platforms

• Starting at the design stage is recommended to prepare your devices to work with IIoT platforms.
• When selecting an IIoT platform, it’s important that it fits your device manufacturing process. Some functionalities, such as programmatic provisioning of secrets, are required at the factory.
• You can enrich the device SW images to support major IoT protocols or embed Device SDK that facilitates communication with your preferred IIoT platform.
• Using Device SDKs over IoT protocol client libraries is a more secure approach as it fully implements the device provisioning process covering all edge cases.
• Device SDKs unlock all platform features without extra coding and are usually offered as a part of the IIoT platform.
• Using just one secret with unlimited validity to work with the IIoT platform is inflexible and insecure.

Interested in this article? Read more articles on our blog.