All SecurityProtocolsshall implement the OpenSecureChanneland CloseSecureChannelservices defined in OPC 10000-4. These Servicesspecify how to establish a SecureChanneland how to apply security to Messagesexchanged over that SecureChannel. The Messagesexchanged and the security algorithms applied to them are shown in Figure 10.

SecurityProtocolsshall support three SecurityModes: None, Signand SignAndEncrypt. If the SecurityModeis Nonethen no security is used and the security handshake shown in Figure 10is not required. However, a SecurityProtocolimplementation shall still maintain a logical channel and provide a unique identifier for the SecureChannel. The handshake shown also applies when using Session-lessServiceinvocations, however the CreateSessionsteps are omitted.


Figure 10– Security handshake when Creating a Session

Each SecurityProtocolmapping specifies exactly how to apply the security algorithms to the Message. A set of security algorithms that shall be used together during a security handshake is called a SecurityPolicy. OPC 10000-7defines standard SecurityPoliciesas parts of the standard Profileswhich OPC UA applications are expected to support. OPC 10000-7also defines a URI for each standard SecurityPolicy. The latest versions of all SecurityPoliciesare available in the online Profileswebsite. OPC 10000-7defines the link to this website.

A Stackis expected to have built in knowledge of the SecurityPoliciesthat it supports. Applications specify theSecurityPolicy they wish to use by passing the URI to theStack.

Table 42defines the contents of a SecurityPolicy. EachSecurityProtocolmapping specifies how to use each of the parameters in the SecurityPolicy. A SecurityProtocol mappingmay not make use of all of the parameters.

Table 42– SecurityPolicy




The URI assigned to the SecurityPolicy.


The symmetric signature algorithm to use.


The symmetric encryption algorithm to use.


The asymmetric signature algorithm to use.


The asymmetric encryption algorithm to use.


The minimum length, in bits, for an asymmetric key.


The maximum length, in bits, for an asymmetric key.


The key derivation algorithm to use.


The length in bits of the derived key used for Messageauthentication.


The asymmetric signature algorithm used to sign certificates.


The algorithm used to create asymmetric key pairs used with Certificates.


The algorithm used to create asymmetric key pairs used for EphemeralKeys.


The length, in bytes, of the Noncesused when opening a SecureChannel.


The length, in bits, of the data used to initialize the symmetric algorithm.


The length, in bits, of the symmetric signature.


If TRUE, the 1 024 based SequenceNumber rules apply to the SecurityPolicy;

IfFALSE, the 0 based SequenceNumber rules apply. See

The KeyDerivationAlgorithmis used to create the keys used to secure Messagessent over the SecureChannel. The length of the keys used for encryption is implied by the SymmetricEncryptionAlgorithm. The length of the keys used for creating Signaturesis specified by the DerivedSignatureKeyLength.

The MinAsymmetricKeyLengthand MaxAsymmetricKeyLengthare constraints that apply to all Certificates(including Issuersin the chain). In addition, the key length of issued Certificatesshall be less than or equal to the key length of the issuer Certificate. See 6.2.6for information on Certificatechains.

The CertificateKeyAlgorithmand EphemeralKeyAlgorithmare used to generate new asymmetric key pairs used with Certificatesand during the SecureChannelhandshake. OPC 10000-7specifies the algorithms that need to be supported for each SecurityPolicy.

The CertificateSignatureAlgorithm applies the Certificateand all Issuer Certificates. If a CertificateSignatureAlgorithm allows for more than one algorithm then the algorithms are listed in order of increasing priority. Each Issuerin a chain shall have an algorithm that is the same or higher priority than any Certificateit issues.

The SecureChannelNonceLengthspecifies the length of the Noncesexchanged when establishing a SecureChannel(see 6.7.4).