-

Security terms and background information

This topic contains the following sections:

Integrity, Authentication, Authorization

The main goals of all security-related efforts are:

Private and public key

Asymmetric cryptography is based on individual key pairs. Each communication party possesses its own unique private key which belongs to exactly one public key as counter part.

  • Using its private key, a party can sign data (for example, a certificate). The signing party is referred to as issuer.

    When realizing data integrity by data encryption/decryption, the receiver of encrypted data uses its private key to decrypt the data which where encrypted before by the sender of the data using the related public key.

  • Using the relating public key of the issuer (which exclusively belongs to the private key), this signature can be verified by other parties.

    For encrypting data, a public key can be used. To decrypt this data, the related private key is required.

The private key must be kept secret by the party (subject). The public key can be distributed in a certificate. By giving the certificate (with the contained public key) to other parties, these recipients are enabled to verify the identity of the subject.
See next section for details.

Certificate

A certificate is an electronic, digitally signed and forgery-proofed identity document (data structure).
A certificate...
  • is specifically created and only valid for the particular owner.

    The owner of a certificate is referred to as subject. This could be, for example, a server or a client application instance.

    The creator of a certificate is referred to as issuer.

  • describes the capabilities the subject has.
    For example, the certificate can only be used for authentication purposes, or a subject may become an issuer and act as CA.
  • confirms that the subject exclusively possesses a private key.
  • contains (quotes) the public key of the subject which exclusively belongs to the private key of the subject.
  • is signed by the issuer with a signature. For creating the signature, the issuer has used its private key. The signature attests that the public key belongs to the subject.
    See the section "CA-signed certificates vs. self-signed certificates" below for details.
  • does not contain the private key of the subject.
Authentication using certificates:
  • A subject (application) can authenticate its identity to other applications by means of its certificate in combination with its private key.
  • The recipient of the certificate verifies the signature of the certificate (and thus the identity of its owner) with the public key of the issuer.
  • The verification is done as challenge response authentication procedure. For example, the subject is asked to sign a random number with its private key. The signature is then verified with the public key.

Following the mutual verification of applications, a secure communication channel between the authenticated applications can be established.

Certificates do not contain encrypted content but plain text. Due to their signature, they do not need to be secured. Therefore, they can be distributed (to involved applications/administrators), for example, by e-mail.

CA-signed certificates vs. self-signed certificates

A Certificate Authority (CA) is an administrator, organization or application that issues certificates, i.e, that creates certificates for other subjects and signs them using the private key of the CA. Subject (owner) and issuer (creator) in this certificate are not identical. The issuing CA writes the public key of the subject for which the certificate is going to be created into the certificate, instead of its own public key when "self-signing".

A self-signed certificate results, if an application creates its own certificate and signs it with its own private key. In a self-signed certificate, the subject (owner) and issuer (creator) are identical. For securing the communication between a small number of applications, the use of self-signed certificates may be practicable. To secure the communication in large distributed networks with many applications, certificates issued by a Certificate Authority (CA) are recommended. Also hierarchical certification structures are possible with one or several issuers and sub-issuer levels.

Note
For the communication between PLCnext Technology controller and PLCnext Engineer, no self-signed certificates can be used.

Certificate Signing Request (CSR)

A Certificate Authority (CA) generates and signs a certificate only on request. This request is called Certificate Signing Request (CSR). With the CSR, the CA receives detailed information on the subject that requests the certificate (subject/owner attributes) as well as the subject's public key in order to include these data in the certificate.

Certification hierarchy, certification path, and Trusted Anchor (root certificate)

When a CA issues a certificate for a particular subject it has to define the future capabilities of the subject. Possibly, the certificate can only be used for authentication purposes, or (by granting further capabilities) a subject may become an issuer and is also able to issue certificates for other subjects. This way, a hierarchical certification structure can be created.

In a hierarchical certification structure, the CA is considered as root node. The CA certificate (root certificate) is called Trusted Anchor. In the next lower level, further issuers (sub-CAs) can follow, each of them with the right to issue certificates. Their own certificates are called issuer certificates. Further sublevels with subsub-CAs are possible. The certificates on application level (e.g., controller and PLCnext Engineer, or OPC UA server and clients) are called application certificates.

In a hierarchical certification structure, a certificate (for example the device certificate of a PLCnext Technology controller, or the application certificate of an OPC UA client) can only be verified by authenticating the entire certification path from the particular certificate up to the Trusted Anchor (root certificate).

For the communication between PLCnext Technology controller and PLCnext Engineer, this is done by
  • installing the entire certification path in the PLCnext Technology controller starting with the controller certificate via all issuer certificates involved up to and including the Trusted Anchor (root certificate).
    and
  • providing the certificate for validating the Trusted Anchor in PLCnext Engineer.

    Note
    Installing only the Trusted Anchor avoids unnecessary subsequent installations in PLCnext Engineer when modifying the certification hierarchy of the device certificate (for example, by inserting or replacing any issuer certificate (generated by a sub-CA).

Certificate Revocation List (CRL)

A Certificate Revocation List (CRL) is a list which describes the invalidity of certificates. A CRL specifies certificates that must not be accepted by application instances or devices. A certificate can be revoked if the relating private key (which is the property of the certificate subject) has been compromised or if the certificate contains content that is no longer valid (e.g. an outdated application instance URI after migrating the application to another computer).

CRLs can be created by any issuers (CA or sub-CA) which are endowed with the rights for issuing CRLs ("Sign CRL"). To revoke a certificate, the CA adds the respective serial number of the certificate (and potentially more) to the CRL. To secure the CRL, it is also signed by the CA using the private key of the CA and it contains a time stamp. This way, applications can verify the authenticity, integrity and validity of a CRL before evaluating its content.

Because usually authentication only happens during connection establishment, an application instance only evaluates the CRL each time when authenticating a certificate.

Consequently, existing connections are not disconnected if a certificate, which was used during connection establishment is revoked later. Such connections must be disconnected manually, for example, after a private key has been compromised or stolen. The disconnection may also be done by restarting the affected devices or application instances.

Example illustration

A CA has issued certificates for a server and a client application on request. This represents a two-level certification hierarchy.

Mutual authentication: To authenticate their identities, each application verifies the certificate of the other application using the public key of the other application. Following the successful authentication, a secure communication channel can be established.

The CA has additionally issued a CRL. The application can use this CRL during authentication to ensure that a certificate that to be authenticated is not revoked. Communication is only established if the involved certificate is not listed in the CRL.