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.
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:
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.