In this article:
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.
Generally speaking, there are two options for integrating devices with IIoT platforms:
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.
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.
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.
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.
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.
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).
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.
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.
Interested in this article? Read more articles on our blog.
The security of IoT devices is complex and has many facets. While there are various types of IoT devices available, there are some fundamental security aspects that every IoT solution designer should bear in mind. To learn more about IoT device security, check out our concise guide.
Learn about challenges that surface when cloud-to-device communication is applied at scale. Devices are typically being continuously added to IoT solutions. Achieving proper and accurate device communication in such a scenario is non-trivial. We show how IoT platforms can help and what are their must-haves.
In this article, you will learn about IoT cloud-to-device communication and its several kinds, including examples. We explain that each kind has its specific purpose and place within an IoT solution. Selecting a suitable kind of cloud-to-device communication is the first step toward a reliable production-grade IoT solution.