The following sub clauses reconcile the objectives that were described in 4.2 with the OPC UA functions. Compared to the reconciliation against the threats of 5.1, this reconciliation justifies the completeness of the OPC UA security architecture.

OPC UA Applications support Authentication of the entities with which they are communicating. As specified in the GetEndpoints and OpenSecureChannel services in OPC 10000-4, OPC UA Client and Server applications identify and authenticate themselves with X.509 v3 Certificates and associated private keys (see [X509]). Some choices of the communication stack require these Certificates to represent the machine or user instead of the application.

For publish subscribe communications Client Server communications is required to obtain the shared keys from a SecurityKeyService (SKS). Although the application authentication is not directly between the Subscriber and the Publisher, the SKS ensures that only authenticated applications can obtain the keys used by the Publisher and Subscriber.

OPC UA Applications support Authentication of users by providing the necessary Authentication credentials to the other entities. As described in the ActivateSession service in OPC 10000-4, the OPC UA Client accepts a UserIdentityToken from the user and passes it to the OPC UA Server. The OPC UA Server authenticates the user token. OPC UA Applications accept tokens in any of the following forms: username/password, X.509 v3 Certificate (see [X509]), or JSON Web Token (JWT).

As specified in the CreateSession and ActivateSession Services in OPC 10000-4, if the UserIdentityToken is a Certificate then this token is validated with a challenge-response process. The Server provides a Nonce and signing algorithm as the challenge in its CreateSession response. The Client responds to the challenge by signing the Server’s Nonce and providing it as an argument in its subsequent ActivateSession call.

Authorization maybe provided via Roles (4.12) and supplied by a GDS. In an environment of mixed vendor products, the GDS can provide a consistent Authorization management. OPC UA Applications that are part of a larger industrial automation product may manage Authorizations consistent with the Authorization management of that product. Identification and Authentication of users is specified in OPC UA so that Client and Server applications can recognize the user in order to determine the Authorization level of the user.

OPC UA Servers respond with the Bad_UserAccessDenied error code to indicate an Authorization or Authentication error as specified in the status codes defined in OPC 10000-4.

In PubSub interactions user Authorization can be used as part of the key distribution (SKS). This allows the Publisher and SKS to restrict access to specific users

OPC UA uses Symmetric and Asymmetric Encryption to protect Confidentiality as a security objective. Thereby Asymmetric Encryption is used for key agreement and Symmetric Encryption for securing all other Messages sent between OPC UA Applications. Encryption mechanisms are specified in OPC 10000-6 and OPC 10000-14.

OPC UA relies upon the site CSMS to protect Confidentiality on the network and system infrastructure. OPC UA relies upon the PKI(public key infrastructure) to manage keys used for Asymmetric Encryption which is then used to establish symmetric session keys. The length of the certificate chain is defined by the site CSMS (only local TrustList with self-signed Certificates or a full CA/CRL infrastructure).

OPC UA uses Symmetric and Asymmetric Signatures to address Integrity as a security objective. The Asymmetric Signatures are used in the key agreement phase during the Secure Channel establishment. The Symmetric Signatures are applied to all other Messages including PubSub messages.

OPC UA relies upon the site CSMS to protect Integrity on the network and system infrastructure. OPC UA relies upon the PKI to manage keys used for Asymmetric Signatures which is then used to establish symmetric session keys.

As specified in the UA Auditing description in OPC 10000-4, OPC UA supports Audit logging by providing traceability of activities through the log entries of the multiple Clients and Servers that initiate, forward, and handle the activity. OPC UA depends upon OPC UA Application products to provide an effective Audit logging scheme or an efficient manner of collecting the Audit Events of all nodes. This scheme may be part of a larger industrial automation product of which the OPC UA Applications are a part.

OPC UA minimizes the impact of Message flooding as described in 5.1.2.

Some attacks on Availability involve opening more Sessions than a Server can handle thereby causing the Server to fail or operate poorly. Servers reject Sessions that exceed their specified maximum number. Other aspects of OPC UA such as OPC UA Secure Conversation can also affect availability and are discussed in OPC 10000-6.