This Service Setdefines Servicesused to open a communication channel that ensures the confidentiality and Integrityof all Messagesexchanged with the Server. The base concepts for OPC UA security are defined in OPC 10000-2.

The SecureChannel Servicesare unlike other Servicesbecause they are not implemented directly by the OPC UA Application. Instead, they are provided by the Communication Stackon which the OPC UA Applicationis built. For example, an OPC UA Servermay be built on a stack that allows applications to establish a SecureChannelusing HTTPS. In these cases, the OPC UA Applicationshall verify that the Messageit received was in the context of an HTTPS connection. OPC 10000-6describes how the SecureChannel Servicesare implemented.

A SecureChannelis a long-running logical connection between a single Clientand a single Server. This channel maintains a set of keys known only to the Clientand Server, which are used to authenticate and encrypt Messagessent across the network. The SecureChannel Servicesallow the Clientand Serverto securely negotiate the keys to use.

Logical connections may be initiated by the Clientor by the Server as described in OPC 10000-6. After the connection is initiated, the SecureChannelis opened and closed by the Clientusing the SecureChannel Services.

An EndpointDescriptiontells a Client how to establish a SecureChannelwith a given Endpoint. A Clientmay obtain the EndpointDescriptionfrom a Discovery Server, via some non-UA defined directory server or from its own configuration.

The exact algorithms used to authenticate and encrypt Messagesare described in the SecurityPolicyfield of the EndpointDescription. A Clientshall use these algorithms when it creates a SecureChannel.

It should be noted that some SecurityPoliciesdefined in OPC 10000-7will turn off authentication and encryption resulting in a SecureChannelthat provides no security.

When a Clientand Serverare communicating via a SecureChannel, they shall verify that all incoming Messageshave been signed and encrypted according to the requirements specified in theEndpointDescription. An OPC UA Applicationshall not process any Messagethat does not conform to these requirements.

The relationship between the SecureChanneland the OPC UA Applicationdepends on the implementation technology. OPC 10000-6defines any requirements that depend on the technology used.

The correlation between the OPC UA Application Sessionand the SecureChannelis illustrated in Figure 13. The Communication Stackis used by the OPC UA Applicationsto exchange Messages. In the first step, the SecureChannel Servicesare used to establish a SecureChannelbetween the two Communication Stackswhich allows the secure exchange of Messages. In the second step, the OPC UA Applicationsuse the Session Service Setto establish an OPC UA Application Session.

image016.png

Figure 13– SecureChannel and Session Services

Once a Clienthas established a Sessionit may wish to access the Sessionfrom a different SecureChannel. The Client can do this by validating the new SecureChannelwith the ActivateSession Servicedescribed in 5.6.3.

If a Serveracts as a Clientto other Servers, which is commonly referred to as Serverchaining, then the Server shall be able to maintain user level security. By this we mean that the user identity should be passed to the underlying Serveror it should be mapped to an appropriate user identity in the underlying server. It is unacceptable to ignore user level security. This is required to ensure that security is maintained and that a user does not obtain information that they should not have access to. Whenever possible a Servershould impersonate the original Clientby passing the original Client’suser identity to the underlying Serverwhen it calls the ActivateSession Service. If impersonation is not an option then the Servershall map the original Client’suser identity onto a new user identity which the underlying Serverdoes recognize.

This Serviceis used to open or renew a SecureChannelthat can be used to ensure Confidentialityand Integrityfor Messageexchange during a Session. This Servicerequires the Communication Stackto apply the various security algorithms to the Messagesas they are sent and received. Specific implementations of this Servicefor different Communication Stacksare described in OPC 10000-6.

Each SecureChannelhas a globally-unique identifier and is valid for a specific combination of Clientand Serverapplication instances. Each channel contains one or more SecurityTokensthat identify a set of cryptography keys that are used to encrypt and authenticate Messages. SecurityTokensalso have globally-unique identifiers which are attached to each Messagesecured with the token. This allows an authorized receiver to know how to decrypt and verify the Message.

SecurityTokenshave a finite lifetime negotiated with this Service. However, differences between the system clocks on different machines and network latencies mean that valid Messagescould arrive after the token has expired. To prevent valid Messagesfrom being discarded, the applications should do the following:

  1. Clientsshould request a new SecurityTokenafter 75 % of its lifetime has elapsed. This should ensure that Clientswill receive the new SecurityTokenbefore the old one actually expires.
  2. Serversshall use the existing SecurityTokento secure outgoing Messagesuntil the SecurityTokenexpires or the Serverreceives a Messagesecured with a new SecurityToken. This should ensure that Clientsdo not reject Messagessecured with the new SecurityTokenthat arrive before the Clientreceives the new SecurityToken.
  3. Clientsshould accept Messagessecured by an expired SecurityToken for up to 25 % of the token lifetime. This should ensure that Messagessent by the Serverbefore the token expired are not rejected because of network delays.

Each SecureChannelexists until it is explicitly closed or until the last token has expired and the overlap period has elapsed. A Serverapplication should limit the number of SecureChannels. To protect against misbehaving Clients and denial of service attacks, the Server shall close the oldest SecureChannelthat has no Sessionassigned before reaching the maximum number of supported SecureChannels.

The OpenSecureChannelrequest and response Messagesshall be signed with the sender's private key. These Messagesshall always be encrypted. If the transport layer does not provide encryption, then these Messagesshall be encrypted with the receiver's public key. These requirements for OpenSecureChannelonly apply if the securityPolicyUriis not None.

If the protocol defined in OPC 10000-6requires that Application Instance Certificatesare used in the OpenSecureChannel Service, then Clientsand Serversshall verify that the same Certificatesare used in the CreateSessionand ActivateSession Services. Certificatesare not provided and shall not be verified if the securityPolicyUriis None.

If the securityPolicyUriis not None, a Clientshall verify the HostNamespecified in the Server Certificateis the same as the HostNamecontained in the endpointUrl. If there is a difference then the Clientshall report the difference and may choose to not open the SecureChannel.Serversshall add all possible HostNameslike MyHost and MyHost.local into the Server Certificate. This includes IP addresses of the host or the HostNameexposed by a NAT router used to connect to the Server.

Clientsshould be prepared to replace the HostNamereturned in the EndpointDescriptionwith the HostNameor the IP addresses they used to call GetEndpoints.

Table 11defines the parameters for the Service.

Unlike other Services, the parameters for this Serviceprovide only an abstract definition. The concrete representation on the network depends on the mappings defined in OPC 10000-6.

Table 11– OpenSecureChannel Service Parameters

Name

Type

Description

Request

requestHeader

RequestHeader

Common request parameters. The authenticationTokenis always null.

The type RequestHeaderis defined in 7.28.

clientCertificate

ApplicationInstance‌Certificate

A Certificatethat identifies the Client.

The OpenSecureChannelrequest shall be signed with the private key for this Certificate.

The ApplicationInstanceCertificatetype is defined in 7.2.

If the securityPolicyUriis None, the Servershall ignore the ApplicationInstanceCertificate.

requestType

Enum

SecurityToken RequestType

The type of SecurityTokenrequest:

An enumeration that shall be one of the following:

ISSUE_0creates a new SecurityTokenfor a new SecureChannel.

RENEW_1creates a new SecurityTokenfor an existing SecureChannel.

secureChannelId

BaseDataType

The identifier for the SecureChannelthat the new token should belong to. This parameter shall be null when creating a new SecureChannel.

The concrete security protocol definition in OPC 10000-6chooses the concrete DataType.

securityMode

Enum

MessageSecurityMode

The type of security to apply to the messages.

The type MessageSecurityModetype is defined in 7.15.

A SecureChannelmay have to be created even if the securityModeis NONE. The exact behaviour depends on the mapping used and is described in the OPC 10000-6.

securityPolicyUri

String

The URI for SecurityPolicyto use when securing messages sent over the SecureChannel.

The set of known URIs and the SecurityPolicies associated with them are defined in OPC 10000-7.

clientNonce

ByteString

A random number that shall not be used in any other request. A new clientNonceshall be generated for each time a SecureChannelis renewed.

This parameter shall have a length equal to the SecureChannelNonceLengthdefined for the SecurityPolicyin OPC 10000-7. The SecurityPolicyis identified by the securityPolicyUri.

requestedLifetime

Duration

The requested lifetime, in milliseconds, for the new SecurityToken. It specifies when the Clientexpects to renew the SecureChannelby calling the OpenSecureChannel Serviceagain. If a SecureChannelis not renewed, then all Messagessent using the current SecurityTokensshall be rejected by the receiver.

Several cryptanalytic attacks become easier as more material encrypted with a specific key is available. By limiting the amount of data processed using a particular key, those attacks are made more difficult. Therefore the volume of data exchanged between Clientand Servermust be limited by establishing a new SecurityTokenafter the lifetime.

The setting of the requested lifetime depends on the expected number of exchanged messages and their size in the lifetime. A higher volume of data requires shorter lifetime.

Response

responseHeader

ResponseHeader

Common response parameters (see 7.29for ResponseHeadertype definition).

securityToken

ChannelSecurityToken

Describes the new SecurityTokenissued by the Server. This structure is defined in-line with the following indented items.

channelId

BaseDataType

A unique identifier for the SecureChannel. This is the identifier that shall be supplied whenever the SecureChannelis renewed.

The concrete security protocol definition in OPC 10000-6chooses the concrete DataType.

tokenId

ByteString

A unique identifier for a single SecurityTokenwithin the channel. This is the identifier that shall be passed with each Messagesecured with the SecurityToken.

createdAt

UtcTime

The time when the SecurityTokenwas created.

revisedLifetime

Duration

The lifetime of the SecurityTokenin milliseconds. The UTC expiration time for the token may be calculated by adding the lifetime to the createdAttime.

serverNonce

ByteString

A random number that shall not be used in any other request. A new serverNonceshall be generated for each time a SecureChannelis renewed.

This parameter shall have a length equal to the SecureChannelNonceLengthdefined for the SecurityPolicyin OPC 10000-7. The SecurityPolicyis identified by the securityPolicyUri.

Table 12defines the Serviceresults specific to this Service. Common StatusCodesare defined in Table 177.

Table 12– OpenSecureChannel Service Result Codes

Symbolic Id

Description

Bad_SecurityChecksFailed

See Table 177for the description of this result code.

Bad_CertificateTimeInvalid

See Table 177for the description of this result code.

Bad_CertificateIssuerTimeInvalid

See Table 177for the description of this result code.

Bad_CertificateHostNameInvalid

See Table 177for the description of this result code.

Bad_CertificateUriInvalid

See Table 177for the description of this result code.

Bad_CertificateUseNotAllowed

See Table 177for the description of this result code.

Bad_CertificateIssuerUseNotAllowed

See Table 177for the description of this result code.

Bad_CertificateUntrusted

See Table 177for the description of this result code.

Bad_CertificateRevocationUnknown

See Table 177for the description of this result code.

Bad_CertificateIssuerRevocationUnknown

See Table 177for the description of this result code.

Bad_CertificateRevoked

See Table 177for the description of this result code.

Bad_CertificateIssuerRevoked

See Table 177for the description of this result code.

Bad_RequestTypeInvalid

The security token request type is not valid.

Bad_SecurityModeRejected

The security mode does not meet the requirements set by the Server.

Bad_SecurityPolicyRejected

The security policy does not meet the requirements set by the Server.

Bad_SecureChannelIdInvalid

See Table 177for the description of this result code.

Bad_NonceInvalid

See Table 177for the description of this result code.

A Servershall check the minimum length of the Clientnonce and return this status if the length is below 32 bytes. A check for duplicated nonce can only be done in OpenSecureChannelcalls with the request type RENEW_1.

This Serviceis used to terminate a SecureChannel.

The request Messagesshall be signed with the appropriate key associated with the current token for the SecureChannel.

Table 13defines the parameters for the Service.

Specific protocol mappings defined in OPC 10000-6may choose to omit the response.

Table 13– CloseSecureChannel Service Parameters

Name

Type

Description

Request

requestHeader

RequestHeader

Common request parameters. The authenticationTokenis always null.

The type RequestHeaderis defined in 7.28.

secureChannelId

BaseDataType

The identifier for the SecureChannelto close.

The concrete security protocol definition in OPC 10000-6chooses the concrete DataType.

Response

responseHeader

ResponseHeader

Common response parameters (see 7.29for ResponseHeaderdefinition).

Table 14defines the Serviceresults specific to this Service. Common StatusCodesare defined in Table 177.

Table 14– CloseSecureChannel Service Result Codes

Symbolic Id

Description

Bad_SecureChannelIdInvalid

See Table 177for the description of this result code.