The OPC UA security architecture is a generic solution that allows implementation of the required security features at various places in the OPC UA Application architecture. Depending on the different mappings described in OPC 10000-6, the security objectives are addressed at different levels. The OPC UA security architecture, for Client / Server communication is structured in an Application Layer and a Communication Layer atop the Transport Layer as shown in Figure 2.

Figure 2 – OPC UA security architecture – Client / Server

OPC UA also supports a Publish - Subscribe communications architecture (PubSub) and the security architecture for that communication is illustrated in Figure 3.

Figure 3 – OPC UA security architecture- Publisher - Subscriber

Client / Server communication can include both Session and session-less communication.

The routine work of a Client application and a Server application to transmit information, settings, and commands is done in a Session in the Application Layer. The Application Layer also manages the security objectives user Authentication and user Authorization. The security objectives that are managed by the Application Layer are addressed by the Session Services that are specified in OPC 10000-4. A Session in the Application Layer communicates over a Secure Channel that is created in the Communication Layer and relies upon it for secure communication. All of the Session data is passed to the Communication Layer for further processing.

Although a Session communicates over a Secure Channel and has to be activated before it can be used, the binding of users, Sessions, and Secure Channels is flexible.

Impersonation allows a user to take ownership of an existing Session.

If a Secure Channel breaks, the Session will remain valid for a period of time allowing the Client to re-establish the connection to the Session via a new Secure Channel. Otherwise, the Session closes after its lifetime expires.

The Communication Layer provides security mechanisms to meet Confidentiality, Integrity and application Authentication as security objectives. One essential mechanism to meet these security objectives is to establish a Secure Channel (see 4.13) that is used to secure the communication between a Client and a Server. The Secure Channel provides encryption to maintain Confidentiality, Message Signatures to maintain Integrity and Certificates to provide application Authentication. The data that comes from the Application Layer is secured and passes the “secured” data to the Transport Layer. The security mechanisms that are managed by the Communication Layer are provided by the Secure Channel Services that are specified in OPC 10000-4.

The security mechanisms provided by the Secure Channel services are implemented by a protocol stack that is chosen for the implementation. Mappings of the services to some of the protocol stack options are specified in OPC 10000-6 which define how functions in the protocol stack are used to meet the OPC UA security objectives.

The Communication Layer can represent an OPC UA connection protocol stack. OPC UA specifies alternative stack mappings that can be used as the Communication Layer. These mappings are described in OPC 10000-6.

If the OPC UA Connection Protocol (UACP) is used, then functionality for Confidentiality, Integrity, application Authentication, and the Secure Channel are similar to the TLS specifications, as described in OPC 10000-6.

The Transport Layer handles the transmission, reception, and the transport of data that is provided by the Communication Layer.

To survive the loss of the Transport Layer connections (e.g. TCP connections) and resume with a new connection, the Communication Layer is responsible for re-establishing the Transport Layer connection without interrupting the logical Secure Channel.

The transport layer can also be used to implement Confidentiality and Integrity by using HTTPS as described in OPC 10000-6. It is important to note that HTTPS certificates can be (and often are) shared by multiple applications on a platform and that they can be compromised outside of the OPC UA usage of them. All applications on the platform that use the same shared certificate have the same settings. HTTPS does not require application Authentication, if this is required it can be included as part of Session establishment.

OPC UA provides a session-less Service invocation (see OPC 10000-4 overview and see OPC 10000-6 for details). The session-less communication provides User Authentication. The communication channel provides Confidentiality and Integrity. The communication channel might be an OPC UA Secure channel (without a session). It might be a communication channel, such as HTTPS, which relies on transport protocols to provide security. In addition, User Authentication and/or Application Authentication can also be established by the use of an AccessToken which is obtained from an AuthorizationService (see OPC 10000-6 for details).

Additional communication mappings are described in OPC 10000-6. These mappings may rely on transport protocols to provide Confidentiality and Integrity. One example is Websockets, which utilizes HTTPS transport layer security to provide Confidentiality and Integrity.

The PubSub can be deployed in two environments, one in which a broker exists and one which is broker less. For a detailed describe of this model see OPC 10000-14 The two environments have different security considerations associated with them, and each will be described separately.

The broker-less PubSub communication model provides Confidentiality and Integrity. This is accomplished using Symmetric Encryption and signature algorithms. The required symmetric keys are distributed by a Security Key Server (SKS) (see OPC 10000-14 for additional details). The SKS makes use of the standard Client/Server security described in 4.5.2 to establish application Authentication as well as user Authentication. This approach allows all applications (Publishers and/or Subscribers) in a SecurityGroup to share information

A benefit of using shared symmetric keys is the high performance they offer, but a drawback is that for a group of applications that use a shared symmetric key, all of the applications in the group have the same rights. All applications must trust all other applications in the group. Any application (Publisher or Subscriber) in the group can publish a message and any application (Publisher or Subscriber) in the group can decode the message.

For example, a system might be composed of a shared symmetric group that is composed of a controller (Publisher) and three Subscribers (say HMI’s). The controller is publishing messages and the HMIs are receiving the messages. If one of the HMIs is compromised, it might start publishing messages also. The other two HMIs will not be able to tell that the message was not sent from the controller. One possible solution to this situation could be if the shared symmetric group is composed of just the controller and one HMI. Additional groups would be created for each HMI, then no HMI could affect the other HMIs. Other possible solutions could also involve the network architecture and services, such as unicast restricted network communication, but these are outside the scope of the of OPC UA specification. The configuration of SecurityGroups requires careful consideration when deploying systems to ensure security.

When using a Broker in the PubSub model, the same shared symmetric key concepts as defined in 4.5.3.2 can be used to provide Confidentiality and Integrity. Furthermore, communication to the Broker can be secured according the rules defined for the Broker. These rules are not defined in the OPC UA specification but are defined by the Middleware. In many cases the Middleware requires the authorization of both the Publishers and the Subscribers before they can interact with the Broker. The Broker interactions can provide security mechanisms to meet Confidentiality, Integrity and application or user Authentication as security objectives. If the published message is not secured using the shared symmetric key concepts, the message content is visible to the Broker which creates some risk of man-in-the-middle attacks. The use of the shared symmetric keys eliminates this risk.