Electronic keys and certificates

Life cycle phases: Security requirements must be observed at every stage and these must be met by technical and organizational means.

© Phoenix Contact

As already explained, current versions of OPC UA include the basic mechanisms for secure use of the architecture. The secure integration of OPC UA into a local network has been considered in the discussion paper 'Secure implementation of OPC UA for operators, integrators and manufacturers' by Plattform Industrie 4.0. All aspects of a component's life cycle were examined, from commissioning by the integrator to decommissioning. The analysis revealed that the greatest difficulties lie in the management of electronic keys and certificates. In particular, this relates to supporting commissioning with a manufacturer certificate as proof of authenticity, the initial installation of electronic keys and certificates and the management of multiple certificates for different applications.

In response to the above-mentioned analysis, for example, the OPC Foundation is currently working on cross-manufacturer standardization for proof of authenticity. The mechanisms for managing and diagnosing the assignment of different certificates to the communication endpoints of a device that may exist simultaneously are also being further developed. Several communication endpoints are necessary so that one and the same device can communicate with different domains that are managed under different security aspects. For example, a device may need to communicate both with the IT of an operator who produces with the machine and with the IT of a maintenance service provider who monitors wear (condition monitoring) in order to send spare parts in good time. Both the operator and the maintenance service provider may be different legal entities and therefore want to generate and manage their own certificates independently of each other to secure communication. Last but not least, the latest specifications have often not yet been implemented in existing applications, meaning that the current security mechanisms are not yet fully usable in practice.

Example of an automatic certificate supply via certificate management: an essential measure without which a scalable deployment is hardly feasible.

© Phoenix Contact

Since the launch of the OPC UA standard, certificates have been used to authenticate OPC UA applications. In automation, however, the handling of electronic keys and certificates is perceived as a challenge. While certificates have been used in traditional IT for several decades, knowledge of how to use them is not yet widespread in automation technology. This is because there was initially no widespread networking and many field devices are only now becoming powerful enough to cope with the computing effort associated with certificates. Part 12 of the OPC UA standard describes a manufacturer-independent way in which OPC UA applications can be supplied with certificates largely automatically, thus reducing the handling effort and making knowledge of certificates largely superfluous in many places. This approach, known as 'certificate management', only requires some manual work to set up the trust relationship between the certificate issuer and the application.

In addition, Part 12 presents an approach for industrial devices that contain OPC UA technology. What is particularly interesting is that the supply of certificates can be used not only for the OPC UA protocol, but also for other protocols and services provided by a device or system. The web server integrated into a device can also be supplied with a new certificate in this standardized and automatic manner at regular intervals.

For OPC UA applications, Part 12 also defines how the settings for the trustworthiness of remote stations can be automatically maintained via so-called 'trust lists' with certificate management. For this purpose, the respective certificates and revocation lists are distributed automatically. Certificate management is usually handled by a Global Discovery Server (GDS), the location of which can be selected as required. The description of the GDS in the standard allows a cascade-like implementation or the connection of certificate management to an existing certificate administration (certificate authority) in the company.

Client-server or publish-subscribe model?

Cross-company communication on the operator/service provider model: The communication path leads through several areas of responsibility and must be coordinated with all parties involved.

© Phoenix Contact

Cross-company networking is becoming increasingly important as part of the future-oriented Industry 4.0 project. As an architecture, OPC UA is proving to be a key element here. In the discussion paper 'Secure cross-company communication with OPC UA', also initiated by the Industry 4.0 platform, a corresponding use of the standard with the client-server model was therefore considered. For the exemplary case of condition monitoring and a possible parameterization, the interaction of an operator and a service provider was analyzed.

In this context, the protection objectives that can reasonably be assumed present a particular challenge. For data transmission via the Internet, the connection must ensure confidentiality and integrity. However, if the communication between the machine and the service provider is completely encrypted from end to end, the operator has no way of monitoring the connection or detecting unauthorized data traffic. The 'aggregating server' model, which would handle all access, could provide a remedy. However, if an operator wants several service providers to access machines from different providers, this inevitably raises the question of scaling. Overall, the client-server model does not appear to be optimal for this application. DIN SPEC 92222 (Reference Model for Industrial Cloud Federation), which is nearing completion, therefore focuses on the publish-subscribe model (PubSub) of OPC UA, which was released with Part 14 of the 2018 specification. In Plattform Industrie 4.0, the advantages and disadvantages of the models - client-server on the one hand, publish-subscribe on the other - as well as other alternatives are already being considered and discussed in order to meet the challenge of scalability.

In summary, it can be said that The requirements for the security of communication relationships must be based on the need for protection. OPC UA offers available mechanisms for which there are recommendations for implementation and further development in order to support widespread implementation. The focus here is on the local application. The use of OPC UA in cross-company data transmission is still under development and is being driven forward in the context of Industry 4.0.

Authors:
Torsten Förder is Senior Specialist Security at Phoenix Contact Software in Lemgo;
Dr.-Ing. Lutz Jänicke is Product & Solution Security Officer at Phoenix Contact in Blomberg.