en
cz

TLS Security - in general

Basic principles

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:

  • making the communication between the client and the server unreadable to outsiders (encryption),
  • that the client and possibly the server know that the counterparty is really who it claims to be (authentication).

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".

Keys

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.

Certificates

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:

  • self-signed – a self-signed certificate ("business card"), the client either accepts it without further doubts, which is the case of a connection without certificate validation, or compares it with the same certificate that is uploaded to the directory with trusted certificates (user_ca).
  • signed by authority:
    • own - verification against the authority to which it is bound. The domain certificate or its root authority must be uploaded to the user_ca client. If the certificate is uploaded at the client, the author of the entire security concept had to upload it there, and the client therefore trusts it,
    • public - verification against some public authority, which is the highest level of trustworthiness. The certificate of the relevant authority must be uploaded again to the client in the user_ca standard authority certificates directory. The Windows operating system usually includes basic (root) certificates, otherwise they can be imported.

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.

How are certificates created?

The certificate is generated by the certification authority based on a certificate signing request (CSR), which contains:

  • public key,
  • information about the certificate holder, such as name, company, email, country, etc.,
  • information about the type and length of the key, e.g. RSA 2048.

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.

Certificate validity

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.

The communication

For interest and deeper understanding - communication takes place approximately as follows:

  • the client establishes a connection with the server, requests a secure connection,
  • the server sends the public key and the certificate, then sends a randomly generated key,
  • the client combines this key with its randomly generated key,
  • the client uses the public key to encrypt the entire combination,
  • the client sends the encrypted combination to the server,
  • the server decrypts using its private key (which no one else knows),
  • obtains the client's random key,
  • this client random key is therefore known by both parties and at the same time could not be read by anyone else on the way,
  • with the help of a (symmetrically) encrypted exchange of information.

For a more detailed description, see e.g. https://tls13.ulfheim.net/.

Uploading certificates and keys to the PLC

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.

The upload process in Domat IDE does not check the format, consistency of the file, etc. Any .pem 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
Default CA def_ca 
User CA usr_ca
Server Private Key srv_key 
Server Certificate srv_cert
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!

What CA certificates are factory loaded in the PLC?

  • Default CA - a Domat certification authority certificate is uploaded from the factory. It is required to connect to the Proxy server and database within the hosted Domat services, if the Certificate Validation option is checked.
  • User CA - factory default, it is possible to optionally upload an authority certificate used by the user here.
  • Server private key, required for secure SSCP connections (from IDE or other PLCs). The private key is loaded at the factory.
  • Server certificate, required for secure SSCP connections (from IDE or other PLCs). In production, a server certificate signed by the Domat certification authority is uploaded.
  • Web server certificate and Web server certificate key are required for secure access to the website (https://). The certificate and key for production operation must be provided by the administrator of the domain on which the PLC web server is operated (e.g. plc.firma.cz). The default ones are for the plc.domat.cz domain, so they are mainly used for connection testing.

In the next part, we will look at individual communication scenarios and show what security options they have.