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. Security in part is provided by the application or by the communications layers. It can also utilize transport layer security. Each of these options provides a different set of security objectives and are described in the following sections.
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 (see 4.11 for more detail on 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 SecureChannel 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 SecureChannel and has to be activated before it can be used, the binding of users, Sessions, and SecureChannels is flexible.
Impersonation allows a user to take ownership of an existing Session.
If a SecureChannel 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 SecureChannel. Otherwise, the Session closes after its lifetime expires. The requirements for re-establishing connections are described in OPC 10000-4
The Communication Layer provides security mechanisms to meet Confidentiality, Integrity and application Authentication as security objectives. In some cases, it also meets the Perfect Forward Secrecy security objective. One essential mechanism to meet these security objectives is to establish a SecureChannel (see 4.13) that is used to secure the communication between a Client and a Server. The SecureChannel provides encryption to maintain Confidentiality, Message Signatures to maintain Integrity and Certificates to provide application Authentication. In addition, the SecureChannel provides Perfect Forward Secrecy when the SecureChannel is used with Elliptic Curve Cryptography (ECC) and the Diffie Hellman Key Exchange. 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 SecureChannel Services that are specified in OPC 10000-4.
The security mechanisms provided by the SecureChannel 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. Other details are provided as part of Profiles which are described in OPC 10000-7 (and available on-line at REF SecurityPolicies \h OPC Security Policies).
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 SecureChannel are similar to the TLS specifications, as described in OPC 10000-6.
Additional communication mappings are described in OPC 10000-6. These mappings can 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 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 transport layer can also be used to implement Confidentiality and Integrity by using HTTPS (HTTP messages over a TLS connection) 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 (defined in OPC 10000-4 overview and see OPC 10000-6 for details). The session-less communication provides User Authentication via an Access Token. The communication channel provides Confidentiality and Integrity. The communication channel could be an OPC UA SecureChannel (without a session). It could 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).
Session-less communication is restricted to encrypted communication channels. It could also be restricted to specific endpoints that are dedicated for session-less communication.
The PubSub can be deployed in two environments, one in which a broker exists and one which is broker less. OPC 10000-14 defines the details of this model. 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 SymmetricKeys 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. An SKS could be part of a Publisher or Subscriber. It could also be a centrally managed SKS that is part of a GDS. A key point related to SymmetricKeys is that they will need to be replaced periodically, where the period is determined by the number of Publishers in a SecurityGroup and the frequency of messages. To ensure that Publishers and Subscribers can maintain communication, they need to be able to interact with an SKS. The SKS can push keys to a Server and a Client can pull keys from the SKS.
See OPC 10000-14 for more details on an SKS.
A benefit of using shared SymmetricKeys is the high performance they offer, but a drawback is that for a group of applications that use a shared SymmetricKey, 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 could 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 could 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 OPC UA specification. The configuration of SecurityGroups requires careful consideration when deploying systems to ensure security. The model is illustrated in Figure 4.
Figure 4 – Boker-less communication
When using a Broker in the PubSub model, the same shared SymmetricKey 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 SymmetricKey concepts, the message content is visible to the Broker which creates some risk of man-in-the-middle attacks. The use of the shared SymmetricKeys eliminates this risk. For complete details on share SymmetricKeys (SKS) and securing PubSub message in Broker based transports see OPC 10000-14. The model is illustrated in Figure 5.
