Communication – encryption

After the recent support of Sparkplug payload in MQTT protocol, we started thinking about supporting encryption in MQTT protocol (in practice, an encrypted MQTTS version of MQTT protocol is often used, similar to HTTPS - an encrypted version of HTTP protocol). In today's blog you will learn how it turned out.

The goal was to integrate support for encrypted connections directly into the D2000 Kom process, which would simplify configuration. It would not be necessary to use, for example, an external utility such as stunnel for encryption, as described in the MQTT in practice blog.

Moreover, it was not a complicated matter, since the Ipesoft D2000 real-time application server already integrates the OpenSSL cryptographic library - it uses it, for example, to encrypt communication between D2000 processes.

The implementation worked, we communicated encrypted with the publicly available MQTT brokers broker.hivemq.com and test.mosquitto.org without any problems. The following parameters were added to the protocol configuration:

TLS TrustedCerts - path to the file/files with the MQTTS server certificate.
TLS KeyFile - path to the private key of the D2000 Kom process.
TLS CertFile - path to the certificate (public key) of the D2000 Kom process.

The first parameter was mandatory (it allowed verification of the MQTT server's trustworthiness), the other two were optional (they allowed authentication to the MQTT server based on our certificate, which the MQTT server trusted).

Then we started to think about whether these parameters could be used for other communication protocols. And we came up with the following:

We expanded the configuration of the TCP/IP-TCP and TCP/IP-TCP Redundant communication lines. A section called "TLS – Certificates" was added, featuring three parameters:

Partner certificate(s) - path to the file(s) with the other party's certificate. This can be a server (for client protocols such as IEC-104 or Modbus Client) or a client (for server protocols such as IEC-104 Server or Modbus Server).
My certificate - path to the certificate (public key) of the D2000 Kom process.
My key - path to the private key of the D2000 Kom process.

Additionally, a section "TLS – pre shared key" has been added with a single parameter:

Pre shared Key - the key shared between the D2000 Kom process and the other party, which will be used to encrypt the connection.

Figure 1 - TCP/IP-TCP line configuration with added TLS parameters

If the "Pre shared key" parameter is specified, the specified text (up to 80 characters) is used to encrypt the connection. The advantage is that there is no need to generate certificates and keys and take care of them.

If the "Partner certificate(s)" parameter is specified, or the "My certificate"/"My key" parameter pair is specified, encryption is activated and the other party is authenticated based on the partner certificate and the D2000 Kom can be authenticated based on its certificate.

If none of the TLS parameters are specified, a standard TCP connection without encryption is used.

The following figure shows the Wireshark tool recording network communication between two communication lines within D2000 Kom process when encryption is used. The "Protocol" column shows the TLS protocol version 1.3 being used.

Figure 2 - establishing TLS communication between the client and server line of the D2000 Kom process

The advantage of moving encryption to the communication line level is that encryption is automatically applicable to all protocols using TCP/IP-TCP and TCP/IP-TCP Redundant lines. And not only protocols built into the D2000 Kom process, but also OEM protocols implemented as dynamic libraries using the D2000 KomAPI interface!

Now, surely some of you have a question: TCP/IP-TCP and TCP/IP-TCP Redundant lines support IPv6 in addition to IPv4. So how does TLS encryption work with IPv6?

Good news - TLS works with both IPv4 and IPv6.

I have to slow down all enthusiastic supporters of the new D2000 features and advocates of increasing security a little now. This new feature is certainly useful. It can be used without any problems to encrypt communication between two D2000 systems (e.g. via IEC-104 protocol). But if we communicate e.g. with a PLC via Modbus, it will not be so easy. A standard PLC certainly does not support TLS encryption. But ... even there, at least a partial solution can be considered. For example, if an existing server in a network with a PLC, or an existing firewall/router in this network, could implement the functionality of the utility to wrap TCP communication in the TLS layer (e.g. using the stunnel utility), communication would be protected from the source (D2000 Kom) to the last network segment - without affecting the PLC and without the need to make any changes on PLC side!

Conclusion

In today's increasingly dangerous digital world, where viruses, malware, ransomware, and other digital threats are everyday bread, increasing the security of control systems is extremely important. Encryption of communication is one of the points that contribute to increasing security. Incidentally, the use of appropriate programming languages in order to prevent, for example, buffer overflow errors is similarly important. A document published this year by the American NSA agency recommends the use of memory-safe languages, among which it also lists the Ada language, in which the Ipesoft D2000 real-time application server is written.

January 8, 2024, Ing. Peter Humaj, www.ipesoft.com