OPC UA Security Concepts

The security features of OPC UA are based on the widely used X.509 certificates and the concepts of Public Key Infrastructure (PKI).

Certificates are filed in a Certificate Store, containing trusted and own certificates as well as certificates from certificate authorities (CAs). On Linux, a file based store is used, defined by four specific locations for certificates and revocation lists.

In the basic, explicit form, trusting a certificate usually means that the certificate (file) is moved into a specific folder in the certificate store.

When using certificate authorities (CAs), a certificate is trusted if it is signed by a trusted CA. This approach is preferable for a larger installation, as it does not require updating all servers and clients when new peers with new certificates are added.

A good analogy to certificates are passports: In a world with only a handful people, fabricating your passport yourself is reasonable. In reality, with millions of passport holders, it helps a lot that passports are fabricated by government agencies and this fact can be verified by checking holograms, watermarks etc.

Self-signed Certificates

Servers often come with preloaded self-signed server certificates and a setting that will generously trust any valid self-signed client certificate. Generic clients typically offer an easy way to create a self-signed client certificate.

These settings are intended to get users started with security easily and create minimal frustration during development. Such “simple” self-signed certificates are good enough for securing the communication, but they are not very practical for authentication: every self-signed certificate must be trusted explicitly - or be accepted by default.

Communication Security

Each OPC UA application (server and client) needs an Application Instance Certificate and a related public/private key pair to identify itself to its communication peers. The public key is contained in the certificate; the private key is secret and used for signing and encryption of messages.

For a secure communication to be established, both peers must trust the certificate of the other.

OPC UA defines three Message Security Modes:

Message Security Mode
None	No security is applied.
Sign	All messages are signed, but not encrypted.
SignAndEncrypt	All messages are signed and encrypted.

As security algorithms are getting obsolete, an increasing number of Security Policies (sets of security algorithms and key lengths) are defined, identified their unique URIs:

Security Policy	URI
None	http://opcfoundation.org/UA/SecurityPolicy#None
Basic128Rsa15 (obsolete)	http://opcfoundation.org/UA/SecurityPolicy#Basic128Rsa15
Basic256	http://opcfoundation.org/UA/SecurityPolicy#Basic256
Basic256Sha256	http://opcfoundation.org/UA/SecurityPolicy#Basic256Sha256
Aes128_Sha256_RsaOaep	http://opcfoundation.org/UA/SecurityPolicy#Aes128_Sha256_RsaOaep
Aes256_Sha256_RsaPss	http://opcfoundation.org/UA/SecurityPolicy#Aes256_Sha256_RsaPss

Client Authentication (Identity)

For client authentication related to managing the authorization of access to a server, OPC UA defines four User Token Types (methods of user authentication):

User Token Type
Anonymous Identity Token	No user information available.
Username Identity Token	User identified by name and password.
X.509 Identity Token	User identified by an X.509v3 certificate.
Issued Identity Token	User identified by a WS-SecurityToken.

Endpoint Discovery

In order to establish a secure connection, the client has to find out which security features the server provides. This process is called Discovery.

In its answer to a discovery request, a server provides a list of Endpoints for the client to connect to, with different sets of security features.

As a debugging tool, the iocShell command opcuaShowSecurity runs the discovery service and displays the available endpoints with their features and their security level (used by the IOC to find the endpoint providing the best security).