Secure onboarding: Cyber security in industrial digital transformation with OPC UA

Integrating the equipment needed to enable the digital transformation in industry requires a careful and stepwise approach to cyber security. How can the inbuilt security capabilities of OPC Unified Architecture (UA) assist the secure onboarding of industrial devices?

Subscribe to ABB innovation and technology news

_{Sören Finster, Florian Kohnhäuser, Thomas Gamer ABB Corporate Research Ladenburg, Germany, soeren.finster@de.abb.com, florian.kohnhaeuser@de.abb.com, thomas.gamer@de.abb.com;
Frank Fengler, Ragnar Schierholz ABB Process Automation Minden, Germany, frank.fengler@de.abb.com, ragnar.schierholz@de.abb.com;
Tilo Merlin ABB Process Automation Frankfurt, Germany, tilo.merlin@de.abb.com}

The higher autonomy delivered by the rapidly proceeding digitalization of industry promises higher productivity, lower costs, smaller energy bills and improved health and safety conditions as well as better sustainability [1,2]. But the digital transformation brings challenges, too – that of interoperability, for instance, which requires global standards for connectivity, interfaces, information models, semantics and cyber security. OPC UA is emerging as one of the core technologies that will help achieve this interoperability – and in a secure way →01.

OPC UA addresses interoperability head-on, combining connectivity, modeling, semantics and security by design [3]. The inbuilt cyber security capabilities of OPC UA, while being optional modes, come into play as soon as a new device is integrated into a system – though in most cases, as a prerequisite for secure communication, certain cryptographic assets must be distributed to the participating devices ahead of time →02. Unfortunately, OPC UA’s cyber security capabilities are often ignored due to the complexity of security processes and lifecycle security, as well as perceived limited usability.

Secure device onboarding and OPC 10000-21

While up until now, Ethernet was used in process industries primarily to connect operator stations, engineering stations and controllers in a well-controlled and protected environment, one now sees Ethernet moving into the shopfloor infrastructure and sensor and actuator networks. This trend calls for secure communication with trustworthy identities for all devices, whether related to process control or maintenance and operations.

In such a scenario, so-called onboarding – ie, unboxing a new device and commissioning it into a system – is a critical phase in a device’s life cycle as it creates first relationships, seen as trusted thereafter. The trust in these relationships and related cryptographic assets, however, can only be as strong as the security of the onboarding process that integrates them. During secure onboarding, malicious or erroneous actors must be excluded, so device identification and authentication are important first steps. Afterward, the new device is put into an operational state by configuring the necessary parameters. For a secure functional state, this procedure includes configuring security parameters – for example, a device certificate and matching cryptographic keys – and ensuring connection to legitimate networks only.

In summary, the key challenges in device onboarding are:

• Identity and authentication: Attach a globally verifiable identity to the device to ensure only legitimate devices can connect to an operator’s system.
• Initial key distribution: Supply needed security credentials, configurations and trust relationships to the device to ensure secure operation.
• Lifecycle security: Manage security credentials and configurations over a device’s lifetime, including updates, upgrades, revocations, etc.

The most promising standardization effort for secure device onboarding in industrial automation systems is OPC 10000-21 [4]. This specification enables secure and automated onboarding of OPC UA devices by allowing full authentication of devices toward the operator’s network based on a unique device identity →02.

Manufacturers certify authenticity

During manufacture, OPC UA-compliant devices are equipped with a device-specific, unique asymmetric key pair and an IEEE 802.1AR [5] Initial Device Identity (IDevID) certificate signed by the manufacturer’s certificate authority (CA) →03. Using the certificate, one can make an initial authenticity check of the device’s identity. And by verifying that the device in question holds the corresponding private key, the device can be securely identified and authenticated.

Trust in this process is rooted in the integrity of the manufacturer’s CA. This certificate must be obtained in a secure manner – for example, by downloading it from the secure internet presence of the manufacturer or via a ticketing mechanism specified in OPC-10000-21.

An IDevID certificate is static and, thus, not tailored to the customer who bought the device, so it cannot include information that is only available after deployment, such as IP addresses or host names. While this deployment-specific information is expected to be present and correct in certificates in an operational state of OPC UA, the OPC 10000-21 standard allows for these checks to be omitted during automated secure device onboarding using static IDevID certificates. Still, even without these checks, achieving this first step of secure device identification already delivers significant value and opens up new opportunities.

Solution roadmap for secure OPC UA device onboarding

The onboarding process described above, a key aspect of OPC 10000-21, comes with some infrastructure requirements: Manufacturers must adjust their manufacturing processes to generate unique device credentials (usually on the target device itself) and sign them via a manufacturer CA as a first step. The reference standard for identities, IEEE 802.1AR, demands the storage of key material in a hardware security module (HSM) to prevent the extraction of private keys and to improve cryptography performance for resource-constrained devices. Using a manufacturer-created “ProductInstanceURI” [6] – a globally unique resource identifier compliant with IEC 61406, a standard dealing with automatic identification of physical objects – within the IDevID SubjectAltName field additionally allows for linking to a device.

In practice, this means that the device contains an HSM, which is used during manufacturing to generate a public and private key pair for the device identity. The device then generates a certificate signing request (CSR), which is submitted through the factory infrastructure to the manufacturer CA. In that process, the ProductInstanceURI is associated with the request. The manufacturer CA issues the IDevID certificate and responds to the CSR with the certificate. The device receives the response through the factory infrastructure and installs the certificate in its memory.

As a second step, a ticket containing metadata about the device is issued and signed in the manufacturer’s infrastructure. This ticket includes the trust anchor – a public key for which trust is known, not derived – needed to validate the IDevID certificate. Finally, the ticket is stored on the device and may be delivered to the device purchaser via an out-of-band channel.

It will be some time before OPC 10000-21 is fully implemented and available at scale, but this first step for secure device identification already opens up new opportunities and shows that OPC 10000-21 can be delivered iteratively, with future generations and further improved security being delivered as software upgrades later.

Quick wins from secure device identities

“Quick wins” build on the assumption that an IDevID certificate of a single device can be verified by the operator, proving it is a genuine device from the vendor.

To verify the IDevID, the operator requires the vendor’s CA certificate with which the IDevID has been signed. OPC 10000-21 tickets can be used to transmit this CA certificate from the vendor to the operator, or it can be pre-installed in software or hardware that the operator is using. This way, IDevIDs can already provide a security benefit without needing a full implementation of OPC 10000-21.

Further, each IDevID is bound to the Product­InstanceURI identifier of the device, provided by the vendor. A ProductInstanceURI identifier typically points to a globally available resource, such as a website that offers additional information about the device. Therefore, this information can be used for authentication using the manufacturer’s backend and to obtain additional life cycle information for the device, which, in turn, allows for some new, trustworthy features, such as

• Access to reliable product information without searching for exact device type or numbering as type- and instance-specific information is available from authentication information. Examples of product information might be mostly static data such as device description, specification, manuals, production data, vendor services, or CO₂ footprint.
• Access to digital twin submodels, which can provide authentic, correct and reliable device data such as runtime data. Such access eliminates manual errors when transferring data between systems and can help fulfill documentation or audit trail obligations.
• Easy and flexible feature enablement by the device being able to authorize features directly or enable service contracting, eg, via manufacturer cloud facilities.
• “Software-ization” of updates, including firmware updates for security reasons and investment protection in long-living and flexible systems.

OPC UA is still evolving

OPC UA, with its built-in security features, contributes to the overall security of the digital transformation, especially device onboarding. While OPC UA security capabilities include full authentication of devices toward the operator’s network, support for authentication of the operator’s network towards devices is not implemented in the current version of OPC 10000-21. The main challenge here is that the customer’s trust anchors are unavailable during device manufacture. The otherwise high level of security and usability achieved, however, will improve deployed security significantly. And there is the possibility of future extensions to the protocol that will bring interoperable solutions for deploying customers’ trust anchors to devices during manufacturing or at a later stage before onboarding.

With features enabled by having secure device identities and the standardization of secure and automated device onboarding, a roadmap emerges that provides solutions with usable and automatable security to ABB customers and equips them for their journey through a demanding and evolving security landscape.

_{References
[1] T. Gamer et al., “The Autonomous Industrial Plant – Future of Process Engineering, Operations and Maintenance,” Journal of Process Control, vol. 88, pp. 101 – 110, 2020.
[2] ABB. “Billions of better decisions,” Study report, 2022. Available: https://stories.ability.abb.com/better-decisions/introduction/. [Accessed September 1, 2022.]
[3] M. Kiener, “OPC UA” ABB Review 1/2023, pp. 80 – 81.
[4] OPC Foundation, “OPC 10000-21 Device Onboarding, Release Candidate 1.05.02 RC1, 2022-07-1.”
[5] IEEE, “802.1AR: Secure Device Identity,” Standard, Revision -2018, 2017. Available: https://1.ieee802.org/security/802-1ar/. [Accessed September 1, 2022.]
[6] OPC Foundation, “OPC 10000-100 Devices – Section 5.5.2 VendorNameplate Interface”, Release 1.02.02, 2020.}

Explore ABB Review