The OPC UA security architecture is a generic solution that allows implementation of the required security features at various places in the OPC UA Applicationarchitecture. 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/ Servercommunication is structured in an Application Layer and a Communication Layer atop the Transport Layer as shown in Figure 2.

image005.png

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.

image006.png

Figure 3– OPC UA security architecture- Publisher - Subscriber

Client/ Servercommunication can include both Sessionand session-less communication.

The routine work of a Clientapplication and a Serverapplication to transmit information, settings, and commands is done in a Session in the Application Layer. The Application Layer also manages the security objectives user Authenticationand user Authorization. The security objectives that are managed by the Application Layer are addressed by the Session Servicesthat are specified in OPC 10000-4. A Session in the Application Layer communicates over a Secure Channelthat 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 Channelsis flexible.

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

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

The Communication Layer provides security mechanisms to meet Confidentiality, Integrityand application Authenticationas 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 Clientand a Server. The Secure Channelprovides encryption to maintain Confidentiality, Message Signatures to maintain Integrityand Certificatesto 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 ChannelServices that are specified in OPC 10000-4.

The security mechanisms provided by the Secure Channelservices 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-6which 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 Channelare similar to the SSL/TLSspecifications, 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 Confidentialityand 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, such as disabling of SSLv2. HTTPS does not require application Authentication, if this is required it can be included as part of Sessionestablishment.

OPC UA provides a session-less Serviceinvocation (see OPC 10000-4overview and see OPC 10000-6for details). The session-less communication provides User Authentication. The communication channel provides Confidentialityand 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 Authenticationand/or Application Authenticationcan also be established by the use of an AccessTokenwhich is obtained from an AuthorizationService (see OPC 10000-6for details).

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

The PubSubcan 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-14The two environments have different security considerations associated with them, and each will be described separately.

The broker-less PubSubcommunication model provides Confidentialityand Integrity.This is accomplished using Symmetric Encryptionand signature algorithms. The required symmetric keys are distributed by a Security Key Server (SKS) (see OPC 10000-14for additional details). The SKS makes use of the standard Client/Serversecurity described in 4.5.2to establish application Authentication as well as user Authentication. This approach allows all applications (Publishersand/or Subscribers) in a SecurityGroupto 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 (Publisheror Subscriber) in the group can publish a message and any application (Publisheror 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 Brokerin the PubSubmodel, the same shared symmetric key concepts as defined in 4.5.3.2can be used to provide Confidentialityand Integrity. Furthermore, communication to the Brokercan 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 Middlewarerequires the authorization of both the Publishersand the Subscribersbefore they can interact with the Broker. The Brokerinteractions can provide security mechanisms to meet Confidentiality, Integrityand application or user Authenticationas security objectives. If the published message is not secured using the shared symmetric key concepts, the message content is visible to the Brokerwhich creates some risk of man-in-the-middle attacks. The use of the shared symmetric keys eliminates this risk.