Secure communication in PLCs is rapidly gaining importance and in some projects the deployment of PLCs with TLS (Transport Layer Security) security is already a requirement. In the following, we will learn the basics of encryption and authentication and show some scenarios from a design and application programming perspective. More information on the whole issue, detailed descriptions of connection establishment and the like can be found on the Internet, we will only discuss the basic principles and especially the implications for the project organization and the setup of PLCs and other programs. Sometimes we come across the abbreviation SSL (Secure Socket Layer), TLS is its more modern successor.
Simply put, there are two problems to solve in secure data transmission:
Encryption takes place in such a way that when establishing a connection, both parties agree on the rules and procedures for encryption, share the encryption key in a secure manner, and then the data (which would normally be sent unencrypted) is always encrypted on the sender's side and decrypted on the recipient's side. This is taken care of by the TLS protocol, which is "between" TCP and the application protocol, which is, for example, SSCP in the case of communication between Domat IDE and PLC, or HTTP in the case of web access. The result is that any data that travels between the two entities is unreadable by any outside party (who does not have access to the key).
For verification, so-called certificates are used, which are electronically signed statements that the party sending the certificate has some characteristics - for example, "is a web server on a certain domain". An electronic signature is verified using a certificate that the receiving party must trust. Trust means, for example, that the certificate was uploaded to the device storage (PLC, computer) by the programmer during commissioning. But the certificate can "rely" on another certificate, issued by a trusted authority, whose certificate the receiving party has and trusts. This chaining is called a "chain of trust".
For encrypted communication using TLS (more precisely, for the secret exchange of a symmetric encryption key), asymmetric encryption is used, which is built on two keys: private and public.
The private key is stored on the server. Generating a private key is not difficult, it is a text file with a code, independent of anything else (such as username, password, date, MAC address of the computer, etc.). The private key must be kept secret, it should not be possible to read it from the device. Today it is stored normally as a file in the PLC, access to it via SSH can be blocked by changing the password for the root user, in the future SSH will be blocked by default (and for service purposes it can be enabled in the IDE as part of the PLC configuration - i.e. with knowledge of the password for the admin user).
The public key is mathematically derived from the private key when generated and is sent to the counterparty (here the client) as part of the initial communication so that the counterparty can encrypt the message. This can then be decrypted only with the help of a private key, so no one other than its owner (the server here) can do it.
Identity verification is done by a (server) certificate, which, as we said above, is trusted information about what the server is. The certificate also includes a public key so that the counterparty can send back encrypted messages. The trustworthiness of the certificate is ensured by means of an electronic signature. There are several ways to sign the certificate:
Only 1 file with a certificate can be uploaded to each item in the PLC (user_ca, default_ca), the original content will be deleted when the next upload is made. When uploading a new one, the old certificate is overwritten. However, since the certificates are text files, their contents can be merged and if we need to have more certificates uploaded in the PLC (for example, during secure communication between several PLCs on the Internet), it is possible to copy all the necessary certificates into one file and upload this file. At the moment, however, there is a restriction that one certificate file cannot be larger than 4 KB in size.
For now, only the server certificate can be uploaded to the PLC. What does it mean? Client programs can authenticate the PLC as a server, but servers cannot authenticate the PLC as a client, which refers to the connection of the PLC to the proxy server and the PLC to the Merbon DB. Although the connection is encrypted in this case, the server cannot verify that the PLC is who it claims to be. Authentication of the PLC as a client takes place only on the basis of the name and password to the database, not by the certificate system.
The certificate is generated by the certification authority based on a certificate signing request (CSR), which contains:
In a normal installation, the entire process of issuing a certificate is ensured by the IT department that manages the network in which the devices will be installed. When handing over private keys that must be kept secret, it may be required to receive them in person, to protect the import of certificates with a password that is sent via a separate channel (SMS), etc. It is therefore recommended to arrange all the necessary steps in advance so that there is sufficient time reserve for them . The network administrator establishes the necessary security policy and it is necessary to agree with him who will manage and update the entire security system - the operator's IT department, the supplier of the control system, or some external entity.
Certificates and keys have a limited validity period, usually 2 years. The comparison time is taken from the RTC PLC. After the expiration date, the certificate is invalid. Self-signed certificates can be generated for up to 50 years, the domat_CA certificate is also generated for a similar length of time. So it is more for tests and function verification, certificates with a shorter validity period should be deployed in the production environment. At the same time, it is necessary to ensure that certificates are regularly renewed. This is the concern of the equipment operator, who can of course order the service from the implementation company that installed and programmed the control system. The implementation company should inform the operator about this and provide the necessary cooperation.
If certificate validation is required during the connection and the certificate has already expired, the connection is not established. This security feature can become a "time bomb" - the device suddenly stops communicating, although no one has changed anything in the settings. We can recognize the problem by the entry in the PLC system log.
For interest and deeper understanding - communication takes place approximately as follows:
For a more detailed description, see e.g. https://tls13.ulfheim.net/.
The dialogue in the PLC (PLC – Operation with PLC – Uploading certificates) looks like this:
In the IDE, it is not visible whether any certificates are already loaded in the PLC. When uploading, the old ones are overwritten.In the IDE, it is not visible whether any certificates are already loaded in the PLC. When uploading, the old ones are overwritten.
The upload process in Domat IDE does not check the format, consistency of the file, etc. Any .prm file name is changed to a file name specific to the type of certificate or key, and the file is saved to the PLC under this name. When the entry is blank, the original file remains in the PLC.
|Item to upload||The name of the file in the PLC|
|Server Private Key||srv_key|
|Web Server Certificate||web|
|Web Server Certificate Key||web_key|
The Web Server Certificate and Web Server Certificate Key pairs are used for web access. It is independent of Server Certificate and Server Private Key, they are for SSCP server.
If the key is password protected, the password must be entered when importing to the repository. For security reasons, the password should be sent via a special communication channel, e.g. via SMS or verbally. The PLC cannot import an encrypted key, it is necessary to request the key in an unencrypted form or to unlock it using an unlocking program. The unencrypted private key must be protected against misuse!
In the next part, we will look at individual communication scenarios and show what security options they have.