OPC UA
From SCADApedia
OPC Unified Architecture (UA) is defined in a multi-part specification written, published and maintained by the OPC Foundation. Currently there are 12 parts listed below.
- Part 1 Concepts
- Part 2 Security Model
- Part 3 Address Space Model
- Part 4 Services
- Part 5 Information Model
- Part 6 Service Mappings
- Part 7 Profiles
- Part 8 Data Access
- Part 9 Alarms and Conditions
- Part 10 Programs
- Part 11 Historical Access
- Part 12 Discovery
Parts 1 through 7 are called the “Core Specification Parts” and apply to all access types, including Data Access, Historical Data Access and Alarms and Events in the original OPC application. Parts 1 through 7 are the Unified Architecture of OPC UA. Parts 8 through 11 specify the Information Models available through the Unified Architecture. Part 12 is labeled as an access type by the OPC UA specification, but it is a management feature of OPC UA that helps clients find and get information required to begin the process of establishing an OPC UA Secure Channel.
Contents |
OPC UA Security
Understanding the security controls in OPC UA can be a challenge because OPC UA security information and requirements are spread throughout the parts. While Part 2 is named Security Model, the most important security information and requirements are in Parts 4, 6 and 7. If a reader had limited time, Digital Bond recommends reading Part 4, Sections 5.4 to 5.6, which cover the Discovery, Secure Channel and Session Service Sets and Part 6, Section 6, which steps through the security process.
Security Goals
The security goals for OPC UA are listed and described in Part 2 of the specification. OPC UA claims to provide authentication, confidentiality, integrity, auditing, and non-repudiation and have features that improve availability. Below is a brief summary of the goals and provided protection.
- Message Integrity – The Secure Channel has the ability to verify that each message is authentic and has not been modified in transit.
- Application Instance Authentication – The set-up and renewal of the Secure Channel includes exchanging and verifying Application Instance Certificates. If an effective certificate infrastructure is in place, this will provide strong application authentication and identify if an attacker or rogue client or server is impersonating an OPC UA client or server.
- User Authentication – The OPC UA client and server can require user authentication as part of the Session Services. The specification supports username/password, X509 certificate and WS-security token as authentication credentials.
- Confidentiality – Encryption of OPC UA messages for confidentiality is an option in the Secure Channel. Additionally encryption of the OPC UA transport layer can be provided by the HTTPS protocol. In fact it is possible to implement double encryption, but this is of little security benefit.
- Security Audit Logs – The OPC UA specifications require logging of all Secure Channel and Session establishment and renewal attempts. There are numerous additional security related log events.
- Replay Protection – A sequence number is included with each message “chunk” or fragment. This offers the possibility of detection and rejection of replayed messages, but the specification is vague and conflicting on the requirements in this area.
- Malformed Message Protection – The specification has some general statements on the rejection of malformed messages, but this is another area that is vague and something that will likely need to be reviewed for each OPC UA client and server implementation.
- Availability / Denial of Service Protection – Some of the features in OPC UA help to make a server more resistant to resource exhaustion attacks. For example, an OPC Server will only attempt to process FindServers, GetEndpoints and OpenSecureChannel requests from an unauthenticated application. All other requests will be rejected without processing.
The Part 2 specification is equally clear on what security features will not be provided by OPC UA. Most importantly, the OPC UA Communication Stack does not provide authorization. Users are authenticated, but what an authenticated user is authorized and able to do is left to the vendor implementation of the OPC UA server application.
OPC Protocol Stack
The OPC UA protocol architecture is a three-layer architecture that uses some of the same terms as the OSI 7 layer model, but is not directly comparable to this model. In fact, the terminology in the specification can be confusing on its own.
- Application Layer (also referred to as the Session Layer)
- Communications Layer (most often referred to as the Secure Channel)
- Transport Layer (not to be confused with Layer 4 of the OSI 7-layer model)
The two diagrams in this section, taken from the OPC UA specification, provide good overviews on the OPC UA protocol stack. Figure 1 below shows the Session and Secure Channel layers, but the UA Transport Layer is not shown. An OPC UA client and server establish a Secure Channel, and the code for creating a Secure Channel is part of the OPC UA Communication Stack that is provided in the OPC Foundation’s SDK. Vendors may choose to use the SDK or develop their own OPC UA Communication stack. Once this Secure Channel is established an OPC UA client application can establish a Session with an OPC UA server application. There are security controls in both the Session and Secure Channel layers.
Figure 2 is another way to look at the OPC UA protocol stack and provides more information on the options and functions of each layer, although the Session layer is not explicitly shown in this drawing. Note that the there are different methods for encoding request and response messages (UA Binary and UA XML), different methods for securing the Secure Channel (UA Secure Conversation and Web Services Secure Conversation), and different methods for transport (UA TCP and SOAP/HTTP(S)). The security ramifications of these choices will be discussed in this document.
OPC UA Encoding
OPC UA supports two methods of encoding: UA Binary and UA XML. UA Binary encoding is aimed at UA applications with stringent performance requirements. The design reduces the time to encode and decode messages as well as the number of bytes that must be sent over the wire as compared to the UA XML encoding method. The UA XML encoding method is primarily the XML Schema with a small number of modifications and restrictions.
OPC UA Transport Layer
Perhaps the most confusing thing about the OPC UA specification is the OPC UA Transport Layer. It is not the layer 4, the transport layer, in the OSI 7-layer model. Instead it is for the transport of OPC UA messages and is actually part of the application layer in the OSI model. The OPC UA Transport Layer breaks an OPC UA message into message chunks if a message exceeds the maximum packet length and reconstructs the OPC UA message at the receiving end. There are two possible transport protocols in OPC UA:
- OPC UA TCP – Again this is not TCP as in TCP/IP. This is a very simple transport protocol with Hello, Acknowledge and Error messages. The OpenSecureChannel and CloseSecureChannel messages are what cause an OPC UA TCP socket to open and close under normal operations. Errors can also cause an OPC UA TCP socket to close.
- SOAP/HTTP – Both XML and UA Binary encoded OPC UA messages are placed in the body of a SOAP message. SOAP’s XML based syntax handles the exchange of these messages. This transport also supports use of HTTPS for encryption at the OPC UA Transport Layer. The specification states that use of SOAP as the Transport Protocol with UA Binary encoding is primarily to allow OPC UA client / server communications through a firewall via HTTP or HTTPS.
Server Discovery
The first step in establishing an OPC UA connection is for the OPC UA client to learn the URL of an OPC UA server. In many implementations this information will be entered as part of the client installation. OPC UA has plans to specify a Discovery Server in a yet to be published Part 12 of the specification.
The Discovery Server concept is OPC UA servers will send a RegisterServer request to a Discovery Server. OPC UA servers are required to register periodically; the default is every ten minutes. An OPC UA client sends a FindServer request to a Discovery Server to identify the OPC UA servers in the system.
Of course, this is an avenue of an attack. If an attacker can corrupt the information in the OPC UA Discovery Server, she could lure OPC UA clients to attach to a spoofed OPC UA server, implement a man-in-the-middle attack, or a number of other attacks. The RegisterServer request requires a Secure Channel between the OPC UA server issuing the request and the Discovery Server, but there are currently no requirements for the Message Security Mode of this Secure Channel.
Once the URL of the OPC UA server is available either through configuration, a Discovery Endpoint on an OPC Server, or from a Discovery Server, the OPC UA client and server need to exchange parameters to describe capabilities and establish a Secure Channel. This process begins with the OPC UA client issuing a GetEndpoints request to the OPC UA server. The UA server will respond with its information required to establish a Secure Channel in an EndpointDescription response. The information included in the EndpointDescription response includes:
- Application Instance X.509 Certificate
- Message Security Mode
- NONE_0
- SIGN_1
- SIGNANDENCRYPT_2
- Security Policy
- URL’s to the overall security policy and crypto algorithms as well as minimum and maximum key lengths. These are defined in Part 7 of the specification.
- Supported User Identity Tokens
- ANONYMOUS_0 (No token is required)
- USERNAME_1 A username/password token
- CERTIFICATE_2 An X.509v3 certificate token
- ISSUEDTOKEN_3 Any WS-Security defined token
- Supported Profiles
- Profiles are defined in Part 7. A Profile is a set of OPC UA conformance units. Conformance units include communication stack requirements (such as transport protocol), security requirements, and functionality requirements (such as DA, HA or Subscription)
- Security Level
- This is an interesting concept where the server ranks the security of the EndpointDescription’s available on the server. In theory a client could be written to select the highest ranking / most secure EndpointDescription that it is compatible with, but this detail is not included in the specification.
Certificate Infrastructure
Secure Channel
An OPC UA Secure Channel is a long running connection between a client and server. There is mandatory encryption and authentication in the process of establishing and renewing a Secure Channel , and there are optional security services available for all or some of the request and response messages sent through the Secure Channel. The Secure Channel Service set is where the majority of the OPC UA security services and parameters are selected and established.
An OPC UA client takes the information from the EndpointDescription response and uses it to issue an OpenSecureChannel request. An OpenSecureChannel request is also sent by an OPC UA client to renew a Secure Channel. The lifetime of a Secure Channel is based on RequestedLifetime in the OpenSecureChannel request, which may be modified by the server and sent as a RevisedLifetime in the response. This lifetime is the cryptoperiod for a set of keys used for message encryption and digital signature.
There are measures in the protocol to limit the impact to client / server clock differences or failed renewal attempts. The keys used in a Secure Channel have a finite lifetime as specified in the SecurityTokens. Clients “should” request a new SecurityToken after 75% of its lifetime has passed. Servers, contrarily, should use a SecurityToken until its lifetime expires even if a new SecurityToken is available. This provides an overlap period when the current and new token are both available to the OPC UA client and server.
Important fields in an OpenSecureChannel request include:
- Application Certificate – The X.509 certificate of the OPC UA client.
- Requested Message Security Mode – The OPC UA client will know what modes the OPC UA server supports from the EndpointDescription response. The OPC UA client can request NONE, SIGN or SIGNANDENCRYPT. There is some security even in the NONE selection because an authenticated Secure Channel must be established and periodically renewed.
- Security Policy – A selection of one of the crypto algorithms and parameter strength from one of the Profiles in Part 7.
- Requested Lifetime – The maximum cryptoperiod of the Secure Channel before renewal / rekeying is required.
There are a variety of Status Code errors related to OpenSecureChannel requests such as Bad_CertificateUntrusted or Bad_RequestTypeInvalid. These security log events are useful for attack detection. There is also a CloseSecureChannel request and response message that, as the name indicates, closes a Secure Channel. This request must be signed to prevent an attacker from closing Secure Channels for a denial of service attack.
The keys used for symmetric encryption and digital signatures are derived based on the client and server nonces using a key derivation method specified in the Security Profile. The nonces are exchanged via encrypted OpenSecureChannel messages and are only known to the client and server.
Security Profiles
Each OPC UA Secure Channel has a Security Profile that describes the algorithms and security parameters that will be used for the Secure Channel and Session. The Security Profile includes the:
- Symmetric Digital Signature Algorithm
- Symmetric Encryption Algorithm
- Asymmetric Digital Signature Algorithm
- Asymmetric Key Wrap Algorithm
- Asymmetric Encryption Algorithm
- Key Derivation Algorithm
- Derived Signature Key Length
Part 7 of the specification contains a list of Profiles. A Profile is made up of Conformance Units that are used to specify and test compliance with the Profile. A number of the Conformance Units, beyond the Security Conformance Unit, have security ramifications including the Auditing, Discovery, Protocol and Encoding, and Session Services Conformance Units. The details of each Conformance Unit will be in files on the OPC Foundation web site. The URL’s are in Part 7, but the files are not on the OPC Foundation as of 18 July 2008 so the details and compliance testing cannot be evaluated in this paper.
There are currently three different Security Conformance Units that may be included in a Security Policy
- SecurityPolicy – None
- SecurityPolicy – Basic128Rsa15
- SecurityPolicy – Basic256
The numbers in these Basic descriptions indicate the key lengths for the algorithms. The Profiles for the Standard UA Client and Server require the SecurityPolicy – None and SecurityPolicy – Basic128Rsa15 Conformance Units. Compliance with a Profile will be documented and exchanged between applications in additional software certificates that are digitally signed by the organization that tested compliance. This could be the OPC Foundation, an independent test organization or the application vendor. The level of testing is included as a field in the certificate.
Secure Channel Digital Signature
Verifying the source of a request or response message and the data in the message has not been altered, either maliciously or due to a communication error, in transit is typically much more important in a control system than protecting the confidentiality of the message by encryption. OPC UA provides the source and data authentication service with a signature. Early draft versions of the OPC UA documents were only applying a digital signature to the message header, which obviously would allow an attacker to modify the message data without being detected. This has been corrected in the specifications and now the entire message, including the message header, message body and message footer, are included in and protected by the Digital Signature.
The digital signature used in Secure Channel establishment is calculated using the sender’s private key and verified by the sender’s public key that was exchanged during the Secure Channel establishment.
Secure Channel Encryption
A method to encrypt OPC UA messages is included in the protocol, and, like most security in the OPC UA specification, it is optional.
The encryption process takes place after the signature process. A signature is calculated and placed in the Secure Channel footer. The encryption process would then encrypt the Secure Channel body, which is the entire OPC UA message, and the Secure Channel footer that includes the signature. Encrypting the signature adds little in security because message content cannot be determined from a well designed digital signature and a single bit change to signed message will change approximately half of the digital signature bits.
Session
An OPC UA Session represents the application layer where an OPC UA client application gets data, sends requests or performs other actions on an OPC UA server application. An OPC UA Session is bound to a single Secure Channel, and the Session will need to know how to access the Secure Channel via its globally-unique identifier (GUID) or other identifier. A CreateSession request initiates a new session, but first a Secure Channel must exist between the OPC UA client and server. If a Secure Channel does not exist, it is triggered by the CreateSession request. The implementation of this trigger is application specific.
CreateSession requests include a clientNonce of at least 32 bytes, the client application instance certificate and a requestedSessionTimeout in milliseconds. Interestingly the request is not signed - - because this is only a precursor to an ActivateSession request. The CreateSession is somewhat useless especially in a single session per Secure Channel environment where the certificate used for the Secure Channel is the same as used for the CreateSession. It is possible to change the user associated with an existing session by sending a new ActivateSession request.
The CreateSession response is digitally signed and includes the server certificate, serverNonce, timeout and additional software certificates. These additional software certificates represent certification by a testing authority such as the OPC Foundation. Each software certificate has a compliance level indicating the level of compliance testing that has taken place.
- UNTESTED_0
- PARTIAL_1
- SELFTESTED_2
- CERTIFIED_3
The important Session request from a security perspective is the ActivateSession request. The ActivateSession request is used to authenticate a user and associate a user to the Session. The associated user for a session can be changed through another ActivateSession request. The user authentication method is determined by the Secure Channel setting and can be NONE. If the user authentication method is NONE, the client certificate used in the Secure Channel establishment is considered the user for the Session. The ActitivateSession request passes a UserIdentityToken that is verified by the OPC UA server application. There are three types of UserIdentityTokens as well as the NONE selection for no user authentication.
- USERNAME_1: username / password authentication
- CERTIFICATE_2: X.509 certificate
- ISSUEDTOKEN_3: WS-Security Token
Interestingly, the authentication of the UserIdentityToken is left up to the application vendor. So the specification requirements are on the establishment of the Secure Channel, and the specification only supports the secure passing of user credentials.
Security Event Logging
The OPC UA specification requires a level of security event logging unprecedented in the control system protocols. This logging will be very useful in after incident analysis and cyber attack detection. Each service set has event logging requirements, referred to as audit in the specifications. There are requirements to log most failures, and importantly there are requirements to log some successes. For example, OpenSecureChannel and CloseSecureChannel requests must be logged for both success and failure.
There is also a rich set of failure descriptions provided as Status Codes in a response message and also stored in the OPC UA server. The Status Codes are defined in Part 4, Section 7.33 in Tables 194 and 195. Each Status Code begins with Good_, Uncertain_, or Bad_. This makes searching the logs and possible log forwarding decisions easy. For example, all the log events starting in Bad_ could be forwarded to a SEM, while Good_ and Uncertain_ events could remain on the server for a period of time.
An OPC UA server can send all audit events to a log server, historian, SEM or other log aggregator via syslog or some other log forwarding protocol. A second approach would be for an aggregator to be an OPC UA client and subscribe to specific security log events. These events would be published to the OPC UA client in the log aggregator.
Another notable feature of OPC UA logging is the ability to correlate client logs with server logs, which could be very helpful in after incident analysis. OPC UA clients provide their audit record ID as part of the request to an OPC UA server. The OPC UA server records the client audit record ID as part of a logged event.
