Key exchange
Secure ADS offers three ways of providing the keys required for encryption; these are described here with their advantages and disadvantages.
What they all have in common is that the respective device has to be isolated with respect to access to the secrets (Pre-Shared Keys, certificates). If these secrets are compromised, the system has to be set up again in order to restore the integrity of the complete system.
Self-Signed Certificates (SSC)
When starting for the first time (e.g. after the installation), TwinCAT generates a self-signed certificate.
The use of such certificates has the advantage that they are generated and are available locally. In order to establish a basis for trust, however, a check of the certificates must be performed among all communication devices.
These certificates are thus suitable for the initial commissioning or also for static machines that can make do without dynamics in the system structure or the entity authorized to access.
From TwinCAT 4024.0 these certificates will be provided as standard when used. The chapter Configuration describes how they are used to establish an ADS route.
Validity periods of the certificates
The certificates generated have a fixed validity period from 1/1/2000 to 1/1/2061. From the point of view of security this is too long, meaning that organizational measures have to be taken to meet the security demands. With this excessively long validity period, Beckhoff ensures that communication does not fail, even if, for example, incorrect times are set in the local system.
If this behavior is not desired, you can generate and use your own certificates (see Certificates provided by the customer).
Pre-Shared Keys (PSK)
Pre-Shared Keys can be stored in a TwinCAT system. These are used to authorize the incoming ADS routes when establishing the connection.
As the Pre-Shared Keys have to be configured they are particularly suitable for granting access, for example, to maintenance staff. The Pre-Shared Keys can be bound to a specific person.
Pre-Shared Keys do not have a validity period like that foreseen for certificates. They are also stored directly in files so that they are not stored as a hash value (as is usually the case with passwords). They are therefore not protected against direct viewing.
The chapter Configuration describes how Pre-Shared Keys are used on both sides of the communication.
Certificates provided by the customer (CA with certificates)
Secure ADS also provides customers with the option of generating and managing their own certificates.
As a result, dynamic constellations in particular are easily mappable, because there can be a common Certificate Authority (CA). All devices that trust this CA can communicate in encrypted form with one another with no further configuration, even if they have never encountered one another before.
The chapter Configuration describes how these certificates can be integrated into TwinCAT.
Notice | |
Expiry of the certificates Certificates have an expiry date. Organizational measures must be taken to replace certificates before their expiry. |