Secure provisioning of IoT devices

When it comes to provisioning IoT devices in particular, security and usability do not have to be opposites. This article aims to show how this can be achieved and which typical problems need to be solved during provisioning.

Provisioning: what exactly is it?

In the context of IoT, provisioning refers to the initial setup of a device. On the device side, this usually includes the network configuration and setting up the upstream connection. This can be a connection to the cloud or an edge system, for example. On the cloud or edge side, the required resources are usually set up for the device when the connection is first established (just-in-time provisioning). The device is given access to the communication endpoint and is assigned to the user or client so that they can manage and monitor it.

Depending on the solution concept, further steps are carried out during provisioning. For example, it may be useful to transfer additional context information with which the device can be assigned to a specific building or system. It is also possible to load certain software components during provisioning that are required for the customer's setup or have been booked by the customer as additional features.

The goal is to make the provisioning process as simple as possible for the user. It should therefore be automated as much as possible.

What makes a provisioning process secure?

When selecting a commission process, it is important that it provides all the necessary information in the most user-friendly way possible and is also as secure as possible. But what criteria must a secure provisioning process fulfill?

1. Proof-of-Identity

The basis of all provisioning procedures is that each device has a unique and cryptographically secured device identity. This is required for subsequent authentication with the upstream system. To do this, the device needs a unique ID that is linked to cryptographic proof, such as a device certificate. 
Depending on the provisioning process, the device identity is pre-provisioned by the manufacturer, generated automatically during provisioning or assigned manually by the user. Generating the device identity during provisioning also enables the connection of legacy hardware or open systems without an identity assigned by the manufacturer.

2. Proof-of-Possession

If the upstream system is a client system, the device must be assigned to the correct client during provisioning. One possibility is that the device owner is already known to the manufacturer. This is particularly common in the B2B environment if the order process was recorded in an ERP system or the upstream system is not a client system but was developed for a specific customer. 
If the final whereabouts of the device are unclear or the provisioning is carried out via an insecure channel, the user should prove that they are actually in possession of the device and wish to carry out a provisioning. This can be done, for example, by pressing a button on the device, by transmitting a pairing code via a secure alternative channel or by logging in as a user on the device.
 

3. Establishing the communication relationship

To enable communication with the upstream system, the corresponding communication endpoint is configured on the device during provisioning.
For cloud systems, this is either a fixed communication endpoint or a provisioning service is used. The latter in turn has a fixed communication endpoint known to the device and informs the device of the actual communication endpoint during provisioning. The use of a separate provisioning service makes it possible, for example, to assign all devices of a client to a specific communication endpoint or to use regionally different endpoints in order to reduce latency.
In edge systems, the communication partners often do not have fixed addresses. Here, mechanisms such as mDNS or device scans can be used to find the respective communication partner. This allows the user to select the communication partner from a list instead of having to enter the endpoint addresses manually.
 

4. Building a relationship of trust

Before the device and upstream device can communicate with each other without restriction, a trust relationship must be established between the two communication partners. 
In many provisioning procedures, this is already done implicitly. For example, when using TLS and device certificates, this is usually ensured by signing the certificates with a CA that is trustworthy for the respective side. As an additional security mechanism, some systems also use a staging area in which newly registered devices are listed and must then be confirmed by the user.
For edge systems and systems without a pre-provisioned device identity, on the other hand, explicit or implicit user confirmation is often necessary. This can be done explicitly through a pairing process, for example. An implicit variant is to evaluate the selection of the device as a communication partner by the user as a trust decision. The trust-on-first-use procedure is also frequently used here.

When selecting a suitable provisioning procedure, care should be taken to ensure that the complexity of the provisioning procedure remains hidden from the user. The selected procedure should be easy to understand and tailored to the use case. It is worth creating an individual concept that takes into account the technical conditions and user habits of the respective use case. In the next Techshorty, some selected provisioning concepts will be presented as examples.

We will help you select a suitable provisioning procedure and also support you with the implementation. Simply contact us.