gmichaud-verreault

PI Connector and OPC UA Security

Blog Post created by gmichaud-verreault on Jun 29, 2020

In the last OPC UA blog post I wrote, Migrating from OPC DA to OPC UA, Roger Palmen mentioned the 'security and management puzzle' that many have used as a reason to delay the move from OPC DA to OPC UA. Hopefully, this helps clarify a few things. Also, from my experience, setting up an OPC UA connection is much simpler than configuring DCOM and provides additional flexibility and so, so many better security features. It also makes it relatively easy to install the connector in a DMZ instead of needing it on the control network (where opcda interfaces generally reside) since they are MUCH more firewall friendly.

I will admit that it does involve a bit more management - certificates expire at some point, and some security policies and hash algorithm eventually deprecate, but it is very little for how much positive it brings.,

Obviously, as it is security-related, the material here is pretty dense, so I will try to answer as many questions as possible.

 

OPC UA provides a number of different security features for different levels of security between the OPC UA Server and Client. In this post, the terms 'OPC UA Client' or 'PI Connector' may be use interchangeably.

Since there are many more security features (thankfully) than OPCDA, it may seem more complicated at first, but it actually offers a high degree of security with limited complexity, especially when compared with DCOM and OPC DA.

 

In this post, I will be focusing on the following features and walkthrough the initial connector setup when most features are used:

  • Application Authentication based on Certificates
  • Secure communication channel with message signing and encryption based on Security Policies
  • User Authentication and Authorization
  • Access control (node and attribute level)

I am purposefully not going over auditing mechanism as it does not involve the PI Connector, but the OPC UA Server itself.

 

Endpoint

To connect to a server, a client needs information like network address, protocol, and security settings. For this purpose, OPC UA defines a set of discovery features. All information which is required to establish a connection between client and server is stored in a so-called endpoint. A server can provide several endpoints, each containing:

  • Endpoint URL (protocol and network address)
    • As compared to OPC DA (DCOM), all connections are established against the one OPC UA Server port. No need to leave the firewalls wide open or use a tunneler for DCOM anymore
  • Security Policy (defines the algorithms for signing and encryption, the algorithm for key derivation and the key lengths used in the algorithms)
  • Message Security Mode (security level for exchanged messages)
  • User Token Type (types of user authentication supported by the server)

 

Thus, when configuring the PI Connector, one only needs to know the endpoint URL of the server or the discovery server. The PI Connector will perform the discovery of the available endpoints:

 

Network Level Security

As mentioned above, OPC UA is much more firewall friendly than OPC DA and its underlying DCOM technology. The client connection will always perform its initial 'Hello' from an ephemeral port to the target OPC UA Server port defined in the endpoint. The session will be established in the same TCP stream. The server will not establish a new independent connection like it would in OPC DA.

 

Transport Level Security

In the list endpoint presented, one can see all the SecurityModes available on the server and their associated SecurityPolicy.

 

SecurityMode

The security mode defines the type of security that apply to all messages. Other than testing, troubleshooting or development work, one should always use Sign&Encrypt.

  • None
    • For testing only
    • Supports connecting to servers without certificate (not very common)
    • Connector does not perform Server Certificate Validation
  • Sign
    • Ensures the message integrity and authenticity
  • SignAndEncrypt
    • Ensures the message integrity and authenticity
    • Prevents eavesdropping (messages are encrypted)

SecurityPolicy

A well-managed OPC UA Server should only return secure Security Policies. At minimum, one should use ‘Basic256Sha256’.

Weaker security policies using outdated algorithms such as SHA-1 should not be used.

 

Application Level Security

When the endpoint has been selected, before any session can be established, both applications (server and client) need to trust each other.

OPC UA requires a bidirectional authentication of the Client and Server applications with X.509 application instance certificates during the establishment of a secure communication connection. Application instance certificates are required to uniquely identify each installation or instance of an application. All activities in the application layer are based on a secure channel that is created in the communication layer. Applications rely upon it for secure communication in addition to application authentication. The secure channel is responsible for messages integrity, confidentiality and application authentication. The application layer manages user authentication and user authorization. Clients may pass a user identity token to the OPC UA Server. The Server verifies that this user is allowed to access and what resources it is authorized to use. 

SecurityLayers.jpg

Source: OPC Foundation

 

To identify itself to communication partners, each installed OPC UA application or devices needs an Application Instance Certificate and an associated public/private key pair. The public key is distributed with the certificate. The private key has to remain secret and is used to sign and/or decrypt messages. A communication partner can use the public key to verify the trust relation, check the signature of messages, and encrypt messages. The Application Instance Certificate (self-signed) for the OPC UA Connector is located in %PIHOME64%\Connectors\OPCUA\pkiclient\own\certs.

 

The OPC UA Connector uses a file-based certificate store with the following format. OPC Servers may follow a similar structure, or can  handle it in the application itself.

 

Own

Application Instance Certificate and private key of the application. For the PI Connector, this contains the certificate that will need to be trusted by the OPC Server

Trusted

Self-signed certificates of trusted OPC UA applications or CA certificates for trusted CAs. Each CA certificate comes with a CRL that requires frequent updates.

Rejected

Certificates from OPC UA applications that tried to connect but were not trusted. Administrators can move certificates from Rejected to Trusted if the application is allowed to connect.

Issuers

CA certificates that are not directly trusted but required to verify a chain of CA certificates. Each CA certificate comes with a CRL that requires frequent updates.

 

To create a secure channel the server needs to trust the client (connector), and the connector needs to trust the server. Only after they both trust each other can a secure channel request be established.

secure_connection.png

Source: https://documentation.unified-automation.com/uasdkdotnet/2.5.2/html/L2UaDiscoveryConnect.html

 

Trusting the client certificate on the server

If the OPC Server rejects the Connector certificate, the following error will be recorded in the message logs:

Please verify that the server trusts the certificate which is provided by the connector. Error: BadSecureChannelClosed Message: Socket was closed gracefully

 

Depending on the certificate store configuration on the OPC Server side, the connector (client) certificate can either be trusted by adding it to the trusted list folder or using the OPC Server application.

Example: Trusting the client (connector) certificate using the OPC Server application (vendor specific)

Status Endpoints Certficate users Sessions Certificates Connection Log Address Space Simulation Debug Log Open Certificate in OS viewer ReqtRes Loq WINTERFELLdevosisottint Own Certticate OpcUQConnectorHost Relettec Trust/Reject of the client certificate in the OPC Server application Valid From: Valid To: Applt.ün Key Size: Filenarne: Serial Signature algorithm: Issuer. SLCect Subject Alternative Name Thumbprint 2111201814:31 2909.202814:31 urn 2048 C: users'tgmicnaud-verreaun. A72EFFgC5B77, PI Connector for OPC LIA SHA256withRSA urn-w.introslsottopcua connectorHost1. [2. GV.INTFI [201 oxaa7ætgc5b774348e83d14agd5de8e9öd732e7e

Trusting the server certificate on the client (connector)

If the PI Connector for OPC UA rejects the OPC UA Server certificate, the following error will be recorded in the message logs:

Connection failed. Please verify that the connector trusts the certificate provided by the server. Error: BadSecurityChecksFailed Message: Error received from remote host: Bad_SecurityChecksFailed (code=0x80130000, description="An error occurred verifying security.")

After rejecting the certificate, the connector places a copy of the rejected certificate in the rejected folder of its file-based certificate store. To trust the server certificate, simply move the certificate to the trusted store.

NOTE: Make sure to inspect the certificate to make sure that it belongs to the OPC Server you want to grant access to.

 C Windows (C:) Program Files PIPC Connectors OpcUa pkiclient rejected SimulaticnSe,ver [U0553EE6012C125266F3C6FC82FBB498F837C9C].der ove ece o e cetts Date modified rusted folder to allow for a secure channel to be _ OpcUa pkiclient trusted PC Windows(C:) Program Files PIPC Simulaticnserver (35FE16FOE016BFF29FB... 4] uaServerCpp@GV.CNCT 188A73CAEU2. cert5 Date if ed 2013259 PM Security Certificate Security Certificate  

User Level Security

Depending on the OPC UA Server implementation, role-based or user-based access control can be implemented. This means, that when connecting with the PI Connector, a username and password will need to be provided. Note that this still occurs after everything else mentioned above, so it is not a something that is done instead of Application or Transport level security, but in addition to.

Similar to PI Data Archive security, identities on the OPC UA Server define what 'user' can do what at a node and attribute level. Since the PI Connector for OPC UA is read-only, it should only be granted a read-only (CurrentRead, HistoryRead) role for the nodes that it will be monitoring.

Keep in mind that the username is not a Windows nor a local account. User management is handled in the OPC UA Server application.

If the username and password fields are left blank, the connector will only be able to connect as an Anonymous user.

 

Recap

To recap, once one select the most secure endpoint, it is expected for the connection to fail twice.

  1. Attempt a connection (wait 1 min, save the data source configuration or force a discovery in PI Connector) -> Fails
  2. The PI Connector will move the OPC UA certificate to its rejected folder. Inspect the certificate information and move it to the trusted folder if it is the OPC UA certificate.
  3. Attempt a connection (wait 1 min, save the data source configuration or force a discovery in PI Connector) -> Fails
  4. The OPC UA Server should reject the client certificate. Trust the connector certificate on the UA Server (the process here will vary widely depending on the vendor)
  5. Attempt a connection (wait 1 min, save the data source configuration or force a discovery in PI Connector) -> Success if the User  is successfully authenticated and will be granted a role on the UA Server
  6. Good to go with the next steps (discovery, data selection, stream naming, etc.)

 

 

Source: https://readthedocs.web.cern.ch/download/attachments/21178021/OPC-UA-Secure-Channel.JPG 

 

Further Reading/Watching

Outcomes