Security with OPC UA

Introduction

Security Mechanisms

Example

Security Mechanisms

Components of the OPC UA Security Concept

Basic Principles

OPC UA is based on a client-server model. Client applications call services provided by an OPC UA server to retrieve information about the server, read or write data or invoke methods. As an example, an OPC UA server can make information from a Programmable Logic Controller (PLC) available to an ERP system that integrates an OPC UA client.

Today, many modern controllers and other industrial devices come with built-in OPC UA servers. At the same time, industrial software systems often provide OPC UA client functionality.

The transport protocol and data encoding used in OPC UA communication are determined by the selected profile, which also influences certain security mechanisms. For an OPC UA server and client to communicate, they must support at least one common profile (servers and clients can implement multiple profiles).

The most commonly used profile relies on TCP as the transport protocol, with data encoded using the OPC UA Binary protocol. For security, it uses UA Secure Conversation (UA-SC). UA-SC applies security to OPC UA messages and establishes a SecureChannel for message exchange.

In addition to TCP connections, OPC UA also supports HTTP(S) for improved compatibility with web applications. In this case, data can be encoded in JSON, XML, or UA Binary, while security is ensured through TLS Transport Security Profiles.

Communication Process – Application Authentication and Data Encryption

An OPC UA connection over TCP consists of three layers that build on one another.

1. TCP Connection
2. Secure Channel
3. Session

First, an OPC UA client establishes a TCP connection to the server’s hostname and port.

Next, the client sends an OpenSecureChannel request. In this step, both sides exchange their X.509 certificates, which are used for authentication and signature validation. The actual session key for communication is securely exchanged using an asymmetric encryption method (e.g. RSA) and then applied for symmetric encryption of the message traffic (e.g. AES).

OPC UA defines three Message Security Modes: Sign & Encrypt, Sign, and None. With None, no encryption is applied (intended only for testing environments and not recommended for production). With Sign, messages are digitally signed. With Sign & Encrypt, they are both signed and encrypted.

Once a Secure Channel has been established, the client can create and activate a session for data exchange using the CreateSession and ActivateSession services. This session builds on the Secure Channel and its message encryption.

At this stage, user authentication also takes place (see next section). Authentication data is transmitted securely over the established Secure Channel.

User Authentication and Role-Based Access Control

OPC UA provides several options for authenticating users. This refers to the actual users of the client application – the application itself has already been authenticated earlier through its certificate.

When activating a session, the OPC UA client sends a token containing the user’s authentication data to the OPC UA server.

This may consist of a username and password or an X.509 certificate, which the server then validates.

Another option is anonymous login, which provides no additional security and is therefore not recommended for production environments.

An OPC UA server defines different user roles with corresponding permissions. During authentication, the server checks the user’s role and assigns the appropriate rights to the session.

Each node on an OPC UA server can specify its own permissions (such as read, write, and method calls) for each user role. This allows OPC UA to enforce fine-grained access control down to the level of individual data points.

From a security perspective, it is best practice to restrict access rights to the required minimum.

Support for Audit Logging

OPC UA supports the logging of activities by OPC UA servers.

Log entries provide insights into which users performed specific actions and when they occurred.

OPC UA defines a wide range of audit events that can be recorded, including established connections, security incidents such as invalid certificates or configuration changes. Each audit event contains standardized attributes such as a timestamp and information for event localization (e.g. ClientUser ID, Server ID, and the affected node).

The actual implementation of audit logging is left to OPC UA application vendors and users. Audit entries may, for example, be written to log files. Alternatively, an OPC UA server can publish audit events via the OPC UA Events mechanism, allowing any OPC UA client to subscribe to them and process them further.

Certificates and OPC UA

As described in the previous sections, OPC UA uses certificates to authenticate both applications and users.

OPC UA supports certificates based on the X.509 standard. These certificates can either be self-signed or issued by a trusted Certificate Authority (CA).

When certificates are exchanged for the first time, a user in the OPC UA application must decide whether to trust the certificate of the other application. A certificate contains information such as issuer, intended usage and validity period. In more complex environments where certificates are used frequently, it is often advisable to rely on a company-owned CA to issue trusted certificates.

Beyond application and user authentication, certificates are also used for signing and encrypting messages.

Certificates include a public/private key pair, with the private key never being shared. After the client and server exchange public keys, each can use its private key to generate a signature that can be validated with the corresponding public key. This signature is then used to confirm that a message originates from the correct application.

If a message is modified during transmission, the signature will no longer match and cannot be validated. Signing therefore protects the integrity of messages.

The same principle applies to asymmetric encryption: The sender encrypts a message with the recipient’s public key, ensuring it can only be decrypted with the corresponding private key (and thus by the recipient).

As previously explained, OPC UA uses this method to securely establish a shared session key. The shared session key can then be used for the (less resource-intensive) symmetric encryption of subsequent communication.

Examples

Practical Implementation of the OPC UA Security Concepts

In practice, an OPC UA server provides information about its available security configurations – consisting of the Message Security Mode (None, Sign, Sign & Encrypt) and the Security Policies (cryptographic algorithms used) – through the GetEndpoints service.

For communication to be established, both the server and the client must support the combination of security policy and message security mode that is used for the connection.

The example below illustrates the configuration of an OPC UA connection with our cloud platform manubes.

Users can choose between the security modes Sign, Sign & Encrypt or None. An additional dropdown field allows the selection of the cryptographic algorithm to be used.

In addition, the type of user authentication can be selected before entering the corresponding information. The available options are anonymous login, username and password or certificate-based authentication.