D



 

 

 

SDO - Secure Device Onboarding

Also frequently called ZTO – zero touch onboarding.

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 always is 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.

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:

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.

From Azure Description:

Along with authentication, securely signed remote credentials are a key component in the end-to-end security path for any IoT device. Authentication can prove that a device is a genuine Azure Sphere product, but it does not guarantee that the device is running an approved and trusted software stack. Securely signed remote authentication credentials certify to the Azure Sphere Security Service that the device's software is not compromised. After the DAA verifies the device's identity and state, it issues a short-lived authentication certificate to the device.
If a device has not yet received a device authentication certificate, the DAA service requires remote confirmation before the device and Azure Sphere Security Service exchange additional messages, work, or other information.
Remote confirmation (attestation), combined with authentication, is a powerful tool to guarantee the integrity and authenticity of any device communicating with Azure IoT services.

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/