OPC UA Applications typically have ApplicationInstanceCertificates to provide application-level security. They are used for establishing a secure connection using Asymmetric Cryptography. These ApplicationInstanceCertificates are Certificates which are X.509 v3 Certificates and contain a list of data items that are defined in OPC 10000-4 and completely described in OPC 10000-6. These data items describe the ApplicationInstance that the Certificate is assigned to.
The Certificates include a Digital Signature by the generator of the Certificate. This Digital Signature can be self-signed (The signature is generated by the Private Key associated with X.509 v3 Certificate that is the ApplicationInstanceCertificate) or can be signed by a Certificate Authority (The signature is generated by the Private Key associated the X.509 v3 Certificate of the CA). Both types of Certificates provide the same level of security and can be used in Asymmetric Cryptography. The Signatures can be generated using a variety of algorithms, where the algorithms provide different levels of security (128 bit, 256 bit, 512 bit ...). The algorithm that is required for signing a certificate is specified as part of the Security Policy. Servers and Clients should be able to support more than one certificate since more than one certificate may be required depending on the Security Profiles that are being supported.
Asymmetric Cryptography makes use of two keys – a Private Key and a Public Key. An OPC UA Application will have a list of trusted Public Keys that represent the applications it trusts. The Private Key and the list of trusted Public Keys are stored either in the Windows Registry or a file folder ideally secured using a secure element (e.g. TPM). The OPC UA Application can use a Public Key, from its list, to validate that the signature on a received connection request was generated by the corresponding Private Key. An application can also use the Public Key of the target application to encrypt data, which can only be decrypted using the Private Key of the target application.
The major difference between CA signed and self-signed Certificate in an OPC UA installation is the effort required to deploy and maintain the Certificates. The choice of when to use a CA issued Certificate versus a self-signed Certificate depends on the installation and site requirements.
Figure 9 illustrates the work that is required to maintain the TrustList for self-signed Certificates.
Figure 9 – Manual Certificate handling
An administrator would be required to copy the Public Key associated with all Client applications to all Server applications that they may need to communicate with. In addition, the administrator would be required to copy the Public Key associated with all Server applications to all Client applications that may need to communicate with them. As the number of Servers and Clients grows, the administration effort can become too burdensome. In addition, a Certificate has a lifetime and will need to be replaced with an updated Certificate at some point in time. This will require that new Private Keys and Public Keys be generated and all of the Public Keys to be copied again. In very small installations, explicitly listing what Clients a Server trusts by installing the Public Key of the Client ApplicationInstanceCertificate in the Trusted Certificate store of the Server may be acceptable.
In systems with multiple Servers and Clients the installation of Public Keys in TrustLists can very quickly become cumbersome. In these instances, the use of a company specific CA can greatly simplify the installation/configuration issues. The CA can also provide additional benefits such as management of Certificate expiration and Certificate Revocation Lists (CRL). Figure 10 provides an illustration of this activity.
Figure 10 – CA Certificate handling
The administrator will need to generate a CA signed ApplicationInstanceCertificate for all Clients and Servers that are installed in a system, but he will only need to install the CA Public Key on all machines. When a Certificate expires and is replaced, the administrator will only need to replace the expired Certificate (Public Keys and Private Keys), there will be no need to copy a Public Key to any locations.
The company specific CA allows the company to control the issuing of Certificates. The use of a commercial CA (such as VeriSign) would not be recommended in most cases. An OPC UA Application typically is configured to trust only the other applications determined by the Company as trusted. If all Certificates issued by a commercial CA were to be trusted then the commercial CA would be controlling which applications are to be trusted, not the company.
Certificate management needs to be addressed by all application developers. Some applications may make use of Certificate management that is provided as part of a system wide infrastructure, others will generate self-signed Certificates as part of an installation. See OPC 10000-12 for additional details on system wide infrastructures for Certificate management.
In some systems, a GlobalDiscoveryServer with Certificate Management may be deployed. The GlobalDiscoverServer will either push certificates to Clients and Servers or allow Servers and Clients to pull certificates. The GlobalDiscoveryServer certificate management can manage all certificate deployments; this includes TrustLists, CAs and CRLs.
From a developer point of view, it is a best practice, if your OPC UA Application supports Certificates, that it automatically provides a self-signed ApplicationInstanceCertificate on installation. In addition, the OPC UA Application is able to easily replace the self-signed ApplicationInstanceCertificate with a CA issued ApplicationInstanceCertificate or have the self-signed certificate signed by a CA. The configuration of a TrustList should also be easily accomplished. Typically, TrustLists for Public Keys of ApplicationInstances are kept in a separate list than those of a CA. Also, an OPC UA Application should be able to handle Certificate Revocation Lists (CRL). These are lists of Public Keys that are associated with a given CA that have been revoked. This allows a CA to remove a Certificate that it had signed from circulation. CRLs are provided by a CA and usually distributed in some automatic manner; see OPC 10000-12 for additional details.
From a security point of view, it is essential that the Certificate stores used to store Private Keys are protected and secured only allowing read/write access by an appropriate administrator and /or by the OPC UA Application. TrustLists, CRLs, and trusted CA lists are secured allowing only write access by an appropriate administrator and in the case of pull configuration by the application. Read access may be granted to other valid users, but the list of users allowed read access would be a site decision.
From an Installation point of view, it is a best practice that a standard tool to generate an ApplicationInstanceCertificate is provided. This tool could be one provided by an OPC UA SDK vendor or by the OPC Foundation. The standard tool ensures that the ApplicationInstanceCertificates that are generated include all of the required fields and settings. A particular OPC UA Application should be able to accept and install any valid ApplicationInstanceCertificates generated by external tools. The choice of the actual tool is site specific. Figure 9 provides an overview of some of the key points of Certificate handling.
Figure 11 – Certificate handling
The following is a summary of these key points when a CA based, security required system is deployed:
ApplicationInstance – An OPC UA Application installed on a single machine is called an ApplicationInstance. Each instance has its own ApplicationInstanceCertificate which it uses to identify itself when connecting to other OPC UA Applications (the Public Key and Private Key). Each ApplicationInstance has a globally unique URI which identifies it. The OPC UA Application will also check TrustLists and CRL’s to determine if access should be granted. The OPC UA Application will communicate using a secure channel established using Asymmetric Cryptography with other applications.
Administrator – The person or persons that administer the Certificate handling associated with a UA system and manage the security settings for ApplicationInstances. This includes setting the contents of TrustLists and managing any activities performed by a CA.
Operator – An Operator is person who uses the ApplicationInstance. More than one Operator may exist for any given OPC UA Application. An Operator may have User Credentials which are used to determine access rights and to track activities within the ApplicationInstance.
User Credential – A User Credential is a generic term for an electronic ID which identifies an Operator/User. It may be passed to a Server after the ApplicationInstanceCertificate is used to create a secure channel. It can be used to determine access rights and to track activities (auditing).
Certificate Authority (CA) – A Certificate Authority (CA) is an administrator or organization which is responsible for creating and managing Certificates (it is usually a partially automated software product). The Certificate Authority verifies that information placed in the ApplicationInstanceCertificate is correct and adds a Digital Signature to the Certificate that is used to verify that the information has not been changed. Each CA has its own Certificate which is used to create the Digital Signatures. A CA is also responsible for maintaining CRLs. In most cases it is a software package that an administrator periodically reviews or accesses, usually when the software package generates an alarm or notification that some review action is required.
Certificate – A Certificate is an electronic ID that can be held by an OPC UA Application. The ID includes information that identifies the holder, the issuer, and a unique key that is used to verify Digital Signatures created with the associated Private Key. The syntax of these Certificates conforms to the X.509 specification and as a result these Certificates are also called “X.509 Certificates”.
Self-Signed Certificate – A self-signed Certificate is a Certificate which has no Certificate Authority. These Certificates can be created by anyone and can be used in situations where the administrators of UA Applications are able to verify the claims by reviewing the contents themselves. A system that uses only self-signed Certificates would not have CA or CRL.
Private Key – A Private Key is a secret number known only to the holder of a Certificate. This secret allows the holder to create Digital Signatures and decrypt data. If this secret is revealed to unauthorized parties then the associated Certificate can no longer be trusted or used. It is replaced or in the case of a CA generated Certificate it is revoked.
TrustList – When security is enabled, UA Applications reject connections from peers whose Certificates are not in the trusted list or if the Certificate is issued by a CA that is not in the TrustList.
Certificate Store – A Certificate Store is a place where Certificates and Private Keys can be stored on a file system. All Windows systems provide a registry based store called the Windows Certificate Store. All UA systems can also support a directory containing the Certificates stored in a file which is also called an OpenSSL Certificate Store. In all cases the Certificate Store needs to be secured, in that only administrators are allowed to write new entries. The security should follow the 'least privileged' principle, in that read or write access is only allowed to those who really need the data. This means that an administrator for example can store a Private Key but is not allowed to read them, and conversely an UA application can read such Private Keys, but cannot write them.
Revocation List – A Revocation List is a list of Certificates which have been revoked by a CA and are not accepted by an ApplicationInstance.