As technical possibilities continue to advance, the intelligence in the automation pyramid is increasingly expanding in the direction of field devices. Correspondingly, data exchange between analog connections is shifting to increasingly powerful communication protocols. Within this context, the spread of OPC UA is bringing a modern architecture into the field of automation that guarantees secure data transfer (lead).
The more powerful components become, the faster the OPC UA communication protocol is establishing itself as the industry standard on the field level. Alongside Ethernet-based communication, IT security is playing an increasingly important role in automation. It supports and protects business processes that demand corresponding measures. The need to protect these processes is expressed in terms of the three most crucial pillars of security: confidentiality, integrity, and availability. Depending on the application, additional considerations, such as authenticity, are also taken into account. In the field of automation, availability is generally the focus of deliberations because production processes form the core of value creation. The integrity of the systems and data transmission is important in order to guarantee the quality of the manufacturing processes and products. The degree of importance attached to confidentiality depends on the application in question. The three main pillars of security can also conflict with one another in practice.
The exchange of confidential data is typically encrypted, making it impossible for unauthorized users to decode. This makes troubleshooting in a local network significantly more difficult because the transfer of data can no longer be analyzed using network diagnostic tools. Furthermore, in the event of an attack, encrypted communication also makes it impossible to differentiate between legitimate and dangerous data transfers. For this reason, the IEC 62443 series of standards “Security for Industrial Automation Systems” (1) views requirements to protect the integrity and to protect the confidentiality of information separately. As a result, it would appear important not to model security measures based on the principle of “more is more”. On the one hand, placing additional requirements on systems and processes leads to unnecessary expenses. On the other, this approach could expose operators to new risks, such as in the aforementioned example of encrypted data transfer.
Connection establishment and data transfer
With this in mind, data is exchanged between the OPC UA client and sever on the application layer in OPC UA sessions. In the communication layer, secure channels are established to protect the integrity and confidentiality. Security in the communication layer is reflected in the functions offered by the protocols. In terms of OPC UA, this is expressed through Security Mode (2), which offers the options None, Sign, and Sign and Encrypt.
For the secure transfer of data, OPC UA relies on established algorithms such as AES (Advanced Encryption Standard) and SHA (Secure Hash Algorithm) for the transfer, and RSA (Rivest, Shamir, Adleman) as an asymmetrical cryptographic algorithm for authentication of communication partners. OPC UA defines the use of these methods in the Security Policy, in which the acceptable combination of algorithms for connection establishment and transfer are described. One example is “Basic256Sha256”, which involves an RSA key of 2048 to 4096 bits, a 256-bit AES key, and a SHA2 key with at least 256 bits, and complies with the latest technological standards. Expansion to include ECC keys (Elliptic Curve Cryptography) is currently in progress.
In order to establish a secure connection, the asymmetrical electronic keys used have a public and a private component. The public component is embedded in an electronic certificate that may include additional information about the owner of the key, such as the name of a system, an application, or a user. When a connection is being established, the key and certificate are checked against trusted lists and/or certificate hierarchies. Based on the results of the authentication, access may be granted to the information of the OPC UA end point. The standard describes objects and methods that can be used to independently manage authorizations via OPC UA. Since each object and each method can be assigned an authorization, even the authorization to grant authorization can be designed to be as fine-grained as necessary; however, this is not currently well supported by the available tools.
Electronic keys and certificates
As described above, in the current versions, OPC UA comprises the basic mechanisms for secure use of the architecture. In practical use, however, the challenges become clear, especially in terms of management of the electronic keys. Secure integration of OPC UA into a local network is considered in the discussion paper “Secure Implementation of OPC UA for Operators, Integrators and Manufacturers” (3). This paper examines all aspects of the life cycle of a component, from procurement on the part of the integrator right through to decommissioning. In the analysis, it became clear that the management of electronic keys and certificates resulted in the greatest difficulties. This includes, in particular, support during commissioning in the form of a manufacturer certificate as proof of authenticity, initial installation of electronic keys and certificates, as well as management of multiple certificates for different applications. Up to now, as a rule, the latest standard of specifications has not been implemented in existing applications, which means that the latest security mechanisms cannot be fully used in practice.
Since the start of the OPC UA standard, certificates have been used to authenticate OPC UA applications. In the field of automation, use of electronic keys and certificates is generally viewed as a challenge. Part 12 of the OPC UA standard describes a manufacturer-independent way to automatically equip OPC UA applications with certificates. This process is referred to as Certificate Management in the standard. The only aspect that requires a certain amount of manual effort is establishing the trust relationship between the certificate issuer and the application. Part 12 of the OPC UA standard also outlines an approach for industrial devices that contain OPC UA technology. The fact that provision of certificates is not only possible for the OPC UA protocol, but also for other protocols and services that a device or system can be equipped for, is particularly interesting. This means that the web server integrated into a device can also be standardized and be automatically issued a new certificate at regular intervals.
For OPC UA applications, Part 12 also defines under Certificate Management how a trust relationship with a remote peer can be managed automatically using “trust lists”. For this purpose, the respective certificates and revocation lists are distributed independently. Certificate Management is generally carried out by a Global Discovery Server (GDS). The location of this server can be freely selected. The description of the GDS in the standard allows for a cascade-style implementation or the connection of Certificate Management to an existing certificate authority within the respective enterprise.
Client–server or publish–subscribe model
As part of the forward-looking Industry 4.0 project, cross-company data transmission is becoming increasingly important. As an architecture, OPC UA has proven itself to be a key element in this area. For this reason, corresponding use of the standard with the client–server model is examined in the discussion paper “Secure Cross-Company Communication with OPC UA” (4). The collaboration between an operator and a service provider was analyzed as an example of Condition Monitoring and possible parameterization.
In this example, the greatest challenge was determining which aspects of security were to be prioritized. In order to transfer data via the Internet, the connection must guarantee confidentiality and integrity. However, if communication between the machine and the service provider is encrypted end-to-end, the operator has no way to monitor the connection or to detect unauthorized data transmission. The aggregating server model, which manages all access, could be of use here. However, this requires us to consider the issue of scaling if multiple service providers need to access machines from different suppliers under a single operator. On the whole, the client–server model does not appear to be ideal for this application. DIN SPEC 92222 “Reference Model for the Industrial Cloud Federation” (5), which is nearly complete, focuses on the publish-subscribe OPC UA model (PubSub), which was released with Part 14 of the 2018 specification.
The demands placed on the security of communication relationships must be tailored to the specific need for protection. OPC UA offers mechanisms, for which there are recommendations in terms of implementation (2) and further development (3), to support widespread implementation. However, the focus is on local application. The use of OPC UA in cross-company data transmission is currently in development and will be advanced within the context of Industry 4.0.
Standardized security through the entire process chain
Phoenix Contact provides automation components with OPC UA interfaces. Through its involvement in specialist bodies and associations, the company is playing an active role in the further development of the standard and ensuring that the products that they manufacture meet the requirements of the user.
The Blomberg-based automation specialist supports its customers through the entire process chain with standardized security. When it comes to establishing secure networks, secure controllers and the corresponding security components, such as firewalls – which work in combination with the security functions of other devices – are key. From a secure development process right through to continuous vulnerability management on the part of Phoenix Contact PSIRT (Product Security Incident Response Team), security is firmly rooted in the complete life cycle of all Phoenix Contact products and solutions. Moreover, the company’s experience and high degree of vertical integration help the user to reach their security quality benchmarks.
(1) Security for industrial automation and control systems. IEC 62443.
(2) Practical Security Recommendations for building OPC UA Applications. Scottsdale, AZ: OPC Foundation, 2018.
(3) Discussion paper “Secure Implementation of OPC UA for Operators, Integrators and Manufacturers”. Berlin: Industry 4.0 platform, 2018.
(4) Discussion paper “Secure Cross-Company Communication with OPC UA”. Berlin: Industry 4.0 platform, 2019.
(5) DIN SPEC 92222 “Reference Model for the Industrial Cloud Federation”. Berlin: DIN, 2019.
More information: www.phoenixcontact.com/security