OPC UA Security: Siemens S7-1500 and UA Expert Client

The goal is to move from an OPC UA connection that works but leaves information visible to a communication path with mutual trust and an encrypted channel.

In the previous article we left the Siemens PLC OPC UA server running and validated from UA Expert. Here we continue from that point: certificates, trust and the comparison between None, Sign and Sign & Encrypt.

Tools: Wireshark, TIA Portal V20, PLCSIM Advanced V7.0 and UA Expert.

We start with the UA Expert connection configured as None. In this mode the communication works, but the application traffic can be inspected from the machine where the client is running.

In Wireshark we can see the negotiation, the OPC UA messages and the activity between the client and the simulated PLC.

When we enter the credentials and authentication is completed, the session becomes active. The user appears in the trace and, although the password is not shown as plain text in this capture, the process data still travels without effective encryption.

To make it clear, we set values in the PLC and change them manually. When the server publishes the change, we capture a PublishResponse from the PLC to the client.

The nesting path inside the Wireshark packet is:

1. OpcUa Service: root block of the OPC UA payload.
2. PublishResponse: server response to the client subscription.
3. NotificationMessage: main container for the published data.
4. DataChangeNotification: confirms that this is a value change.
5. MonitoredItemNotification: monitored item that has changed.
6. DataValue / Variant: real variable value and its metadata.

The same happens with a Real variable. If the channel is not encrypted, Wireshark lets us follow the packet down to the published value.

With this we confirm that anyone capturing the traffic between server and client could see the packets and their content, with the risks that this implies.

When we talk about security here, we are protecting the communication in several ways:

signature, encryption and certificate.

• Signature: validates integrity and authenticity. If someone modifies the message, it is detected.
• Encryption: hides the content. Even if someone captures the frame, they cannot read variables or values.
• Certificate: identifies an application or server and allows trust to be established. In OPC UA there are old policies and algorithms that are now obsolete or weakened; they are easier to attack, so it is better to avoid them and use current policies supported by the PLC and the client.

In the first OPC UA Server security test, we enable a policy with Sign. It is useful to understand the trust flow, but by itself it does not encrypt the process data.

The next step is to enable Certificate Manager in the TIA Portal project. Before generating certificates, we compile to see which errors appear and separate the problems.

After enabling it and compiling the project, TIA Portal reports compilation errors derived from that activation.

When certificate management is enabled, TIA Portal forces us to create a user for project management. After that, the required Security features become available.

An engineering administration user has been created.

This activates the project security features.

At this point we need three things:

• Create the project Certificate Authority.
• Create the OPC UA Server certificate.
• Assign the certificate to the PLC so the OPC UA server can use it.

The Certificate Authority issues, signs and validates the project certificates. In a local test it can be the project CA itself; in a real plant this should fit the site's certificate policy.

Now we create the OPC UA Server certificate. We select the corresponding usage, define a common name and add the required Subject Alternative Names: application, IP and/or URI.

The SAN is important because it gives the client more proof that this certificate belongs to that specific server. It does not only say "I am the PLC"; it also says "I am valid for this IP, this name or this OPC UA URI".

Then we assign the certificate to the PLC so it is stored in the controller and can be selected in the OPC UA server configuration.

We assign it as the OPC UA Server certificate.

After compiling again, the specific OPC UA error for a missing certificate disappears. The OPC UA server now has an associated certificate.

Although it is not the main goal of this article, we also generate the certificate for PG/PC and HMI communications. This prepares the path for other scenarios, for example WinCC Unified.

Again, we assign it to the certificates stored in the PLC.

To assign it to the service, we go to Protection & Security and associate it in the corresponding connection mechanisms.

We compile again and there are no more errors related to the security we enabled.

We download the PLC and return to UA Expert. The first warning is expected: the client no longer considers the server certificate trusted.

If we try to use the previous connection in None, it is no longer valid. We rebuild the connection by selecting the secure policy we want to test and entering the user credentials.

Because the certificate authority has not been imported correctly yet, UA Expert shows the trust warning.

We can accept it temporarily to see variables, but that is not the clean solution because the connection is not fully trusted.

The solution is to make UA Expert trust the Certificate Authority that signed the PLC certificate. We export the CA from TIA Portal and copy it to the UA Expert issuers folder.

We enter the export password:

Then we save it in the UA Expert client path and move the CA certificate there.

We verify that it appears as an issuer.

Then another warning appears: the certificate revocation list, or CRL, is missing. Copying the CA is not enough; the client also expects to check whether a certificate issued by that CA has been revoked.

We go back to Certificate Manager to export, but now we select the CRL file type.

In the UA Expert client folder, we place it in the corresponding path, in this case crl.

Once the CA and its CRL are imported, the UA Expert side is correct and the PLC OPC UA server can be validated cleanly.

It keeps running and the UA Expert log confirms that there are no errors.

There is one important question left: why did we not have to import the UA Expert client certificate into the PLC during the first test?

In other words, we had not told the PLC that this specific client was going to connect to its OPC UA server.

The reason was this PLC option: Automatically accept client certificates during runtime. With this option enabled, the PLC accepts client certificates during runtime. It is convenient for tests, but it is not ideal if we want controlled trust.

After disabling automatic acceptance, we download the PLC again and the connection no longer works. Now we do need to explicitly register the UA Expert client certificate in the project.

To do that, we go to UA Expert's own certificates, inside own, and locate the client application certificate.

We import that certificate into the project Certificate Manager, together with the other certificates we generated before.

Once imported, we assign it as an OPC UA client certificate.

Now we can see that it is used for OPC UA.

We download the PLC and repeat the connection. The path is now complete: UA Expert trusts the PLC CA and CRL, and the PLC trusts the UA Expert client certificate.

With the certificates now in order, it is time to look at Wireshark again. In the test with Sign, both sides trust each other and the messages are signed, but the content is not encrypted.

This is the fine point of the article: signing is not encrypting.

The signature protects against modification, but it does not stop the data from being read if the selected mode does not encrypt the channel.

We then change the channel security to Sign & Encrypt, download the PLC and rebuild the connection from UA Expert using the new policy.

Now the connection is immediate and everything communicates correctly on the first try because the certificates are the same. What changed is the policy, in other words, the way the communication is protected.

When we capture again, we can no longer follow the same route down to the monitored values. It is not even as obvious to locate the publish responses. The conversation is encrypted.

This is the result we wanted: certificates correctly distributed, mutual trust between client and PLC, and an OPC UA channel with active encryption.

1. None policy in OPC UA: useful for quick tests, but it leaves the conversation observable in Wireshark.
2. User and password: control access, but they do not replace channel encryption.
3. Certificate Manager: enables formal certificate management inside the TIA Portal project.
4. Project CA: issues and signs the certificates that client and server must later trust.
5. OPC UA Server certificate: identifies the PLC as the server and should include coherent alternative names for IP, name or URI.
6. UA Expert: must trust the PLC CA and have the revocation list available.
7. Client certificate: if the PLC does not accept clients automatically, the UA Expert certificate must be imported as a trusted client.
8. Sign: signs the message and helps with integrity, but it does not hide the data.
9. Sign & Encrypt: this is where the capture stops showing process values.

Mental model: first we make the parties know each other through certificates; then we make them trust the CA and CRL; finally we choose a security mode that actually encrypts. If one of those pieces is missing, the connection can fail or it can work while being less protected than we think.

Notes:

- Depending on the OPC client used, different certificate security requirements may apply.

- Not every client supports the most modern security policies.

- Old security policies are more vulnerable to attack, so current policies should be used when the PLC and client support them.

• Siemens S7-1500 OPC UA Server: TIA Portal V20 and PLCSIM
• Secure OPC UA connection flow under IEC 62443
• Temperature control system (III) - OPC UA