linutronix

Industrial linux

Now it's real(ly) time!

SDO - Secure Device Onboarding

Also known as ZTO – Zero Touch Onboarding

For more information with regard to legislation an industrial standards  see our Explanatory Video 

 

The IIoT (Industrial Internet of Things) raises serious new security challenges that become more acute as the scope and scale of IIoT systems increases. IIoT devices are often equipped with outdated software at the time of commissioning, so they require an update. And, according to their task, they must connect to a server (cloud) to exchange data. To do this, the devices must be uniquely identifiable and able to connect to a dedicated server.

For security reasons, the connection between the server and the IIoT may only be established after both parties have been able to authenticate themselves unambiguously.

One solution hereto is Secure Device Onboarding, also called Zero-Touch-Onboarding. This allows IoT devices to be configured with settings that are stored in a central server. As soon as a device becomes active, it connects to this server and its configuration settings are automatically installed with no need for a technician to intervene. This allows operators a much faster onboarding method while minimising the attack surface on the devices.

Regardless of the ZTO method chosen, except for the SDO method (see below), an exchange of information between production and server-based registration is always necessary.

A secure connection to the (cloud) server requires the IIoT device to authenticate to the cloud backend. This may be based on various procedures:

  • Only in rare cases will a "simple" authentication using 128-bit numbers according to universally unique device identifiers (UUID) be sufficient. The combination of UUID and a key pair will also rarely be sufficient. A hardware ID burned into the firmware is more suitable here.
  • In most cases, the use of an HSM, TPM or fTPM1 will be the preferred solution2 , optionally having only keys or in combination with X.509 certificates. Among others, OPC UA as well as many large cloud providers (for example MS Azure3) rely on this approach. The use of a TPM (fTPM) also has the advantage that a secure/measured boot can be carried out, whereby not only authentication but also an attestation query can be carried out.
  • Alternatively, a challenge/response procedure could be used. Requests from clients are answered by the server with a random byte sequence, the so-called challenge, and an identifier, which is a random number. The client must answer the request correctly by combining it with a password that is known to the server and client and calculating a hash value from it using a hash function, which it sends back to the server. The server also calculates a hash value from the data and compares it with the one sent by the client. If there is a match, the request is executed.

All these solutions have in common that they allow a unique assignment of devices that can be traced back to the current user. This is where the Secure Device On-Board process comes in, which was originally developed by Intel under the name EPID (Enhanced Privacy ID). Since February 2020, this solution has been open source and is hosted by the Linux Foundation4. The onboarding here must run via a dedicated Rendezvous server, the code for which was also provided by Intel.
The advantage of this approach, apart from the improved protection of privacy, is the fact that the target platform (cloud server) need not be known at the time of production.

SDO Provisioning

The key benefits of Secure Device Onboard are:

  • Enables Build-to-Plan Model - ODMs can build identical IIoT devices in high volumes using a standardised manufacturing process. Reduces inventory, delivery cycle times and costs.
  • SDO Late Binding - allows the device's target platform to be selected "late" in the supply chain, at first power-on.
  • It's Open - means the service and the cloud are independent. Devices are bound to the desired ecosystem at installation. Works with existing cloud services, but does not replace them.

The following picture gives an overview of the trust chain in this SDO procedure:

IIoT Supply Chain

Example of an IIoT supply chain
and the associated steps within the SDO process
Source: https://secure-device-onboard.github.io/docs/latest/

 

We would be happy to work with you to find the right solution for your use case.

1 Firmware TPM, mostly consists of Trusted Zone (TZ) and a dedicated memory, which often is an eMMC with a replay protected memory block (RPMB)
2 TCG TPM v2.0 Provisioning Guidance, https://trustedcomputinggroup.org/resource/tcg-tpm-v2-0-provisioning-guidance/
3 https://azure.microsoft.com/de-de/resources/azure-sphere-device-authentication-and-attestation-service/
4 https://www.lfedge.org/projects/securedeviceonboard/
https://secure-device-onboard.github.io/docs/latest/