Secure communication by encryption and authentication
Main goals: integrity and authentication
The implementations described in this chapter serve to pursue two main objectives of security engineering: to achieve data integrity and to authenticate users and data sources.
- Integrity: is the data unchanged?
Checksums indicate the integrity of data thus allowing tamper detection. By verifying checksums, manipulations and data corruption can be detected.
- Authentication: where does the data come from/go to or who accesses the system/data?
In communication networks, certificates can be used for authentication purposes. Here, private and public key pairs are relevant.
By requesting a user role and password, users can be authenticated. Since each user has been granted authorization for certain operations and accesses (in the central user management), access to both data and system components (e.g. network-capable devices such as a controller) can be restricted.
Furthermore, signing certificates with a private key can be used for distributing data (e.g., releasing libraries). The resulting signature is used to verify both the integrity and the authenticity of the released data.
Secure communication
Communication connections between participants in your ICS must be secured. Participants can be, for example:
- Server or client applications, such OPC UA, HMI, etc.
- Engineering tools, such as PLCnext Engineer
- Devices used to build automation infrastructures and systems, such as PLCnext Technology controllers, switches, etc.
For protection purposes, certificates can be used for authentication of such connections.
To secure the communication between devices and applications, certificates must be provided (installed) on these devices or in the applications.
When establishing a communication connection between two communication partners, both have to provide authentication to each other by means of their certificate which exclusively belongs to the particular participant. The respective other participant then verifies the validity of this certificate.
In many cases, only the server authenticates itself with its certificate (HTTPS, LDAPS etc.), so the client can be sure that the data provided for login (username, password) cannot be intercepted. Mutual authentication via client certificate eliminates the risk of password disclosure.
This authentication allows the establishment of a secure channel (within one so-called security domain) and the connection is only established if the certificate is valid. If the authentication fails, no secure communication connection can be established.
By securing a communication connection this way, also potential man in the middle attacks between the participants can be recognized.
Example: PLCnext Technology controller
When establishing a communication connection between a PLCnext Technology controller and PLCnext Engineer, the controller has to provide authentication to PLCnext Engineer by means of this certificate which exclusively belongs to this particular device. PLCnext Engineer then verifies the validity of this certificate.
The user authenticates himself to the controller with a user role and password: He has to log on to the controller via the engineering tool when initiating the connection between PLCnext Technology controller and PLCnext Engineer. The authorizations (permitted operations and data accesses) for each user role are stored in the controller.
If such a man in the middle attack is detected between PLCnext Engineer and a connected PLCnext Technology controller, you have the choice to stop the connection or to continue if the communication breach is intended and needed to support the chosen network architecture.
Owner-specific certificate instead of Phoenix Contact certificate
Some devices may come with a preinstalled manufacturer-defined certificate.
PLCnext Technology controllers by Phoenix Contact are equipped with a manufacturer-defined certificate issued by Phoenix Contact (in accordance with the IEEE 802.1AR standard).
This manufacturer-defined device certificate should be replaced in the device by an owner-specific device certificate which can be configured and issued by the device owner (Certification Authority). Installing an own certificate increases the degree of security as the device is "customized". The replacement ensures that your automation system can only be controlled by your software tools (e.g. your particular PLCnext Engineer instance).
After implementing an owner-specific device certificate in a device (or a hierarchical certification structure), the relevant certificate(s) (at least the root certificate) must be provided to the potential communication partners to enable it to validate the controller as trusted device.
Example: PLCnext Engineer must be adapted accordingly after installing an owner-specific device certificate on a PLCnext Technology controller. You have to deposit the corresponding certificate for validating the customer-specific controller certificate in PLCnext Engineer.
Installing only the Trusted Anchor (but not the Issuer Certificates of the path) avoids unnecessary subsequent installations for the communication partners when modifying the certification hierarchy of the device certificate (for example, by inserting or replacing any Issuer Certificate (signed by a sub-CA).
Refer to the topic "Certificates" for details.
Available measures
Possible measures and technical means are described in the following topics:
Implementations