Secure Communication by Encryption and Authentication
This topic contains the following sections:
- Main goals: Integrity and Authentication
- Secure communication
- Owner-specific certificate instead of Phoenix Contact certificate
- Available measures
- Implementations
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
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.
| Note
If you have implemented a hierarchical certification structure in your application, at least the Trusted Anchor (root certificate) of the certificate path must be provided to the communication partners. Based on the Trusted Anchor, it will then be able to validate the entire certification path including all Issuer Certificates. 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. |