Figure 11shows the structure of a MessageChunkand how security is applied to the Message.


Figure 11– OPC UA Secure Conversation MessageChunk

Every MessageChunkhas a Messageheader with the fields defined in Table 41.

Table 41– OPC UA Secure ConversationMessage header


Data Type



Byte [3]

A three byte ASCII code that identifies the Messagetype.

The following values are defined at this time:

MSGA Messagesecured with the keys associated with a channel.

OPN OpenSecureChannel Message.

CLO CloseSecureChannel Message.



A one byte ASCII code that indicates whether the MessageChunkis the final chunk in a Message.

The following values are defined at this time:

C An intermediate chunk.

F The final chunk.

A The final chunk (used when an error occurred and the Messageis aborted).

This field is only meaningful for MessageType of ‘MSG’

This field is always ‘F’ for other MessageTypes.



The length of the MessageChunk, in bytes.

The length starts from the beginning of the MessageType field.



A unique identifier for the SecureChannelassigned by the Server.

If a Serverreceives a SecureChannelId which it does not recognize it shall return an appropriate transport layer error.

When a Serverstarts the first SecureChannelIdused should be a value that is likely to be unique after each restart. This ensures that a Serverrestart does not cause previously connected Clientsto accidently ‘reuse’ SecureChannelsthat did not belong to them.

The Messageheader is followed by a security header which specifies what cryptography operations have been applied to the Message. There are two versions of the security header which depend on the type of security applied to the Message. The security header used for asymmetric algorithms is defined in Table 42. Asymmetric algorithms are used to secure the OpenSecureChannel Messages. PKCS #1defines a set of asymmetric algorithms that may be used by UASC implementations. The AsymmetricKeyWrapAlgorithmelement of the SecurityPolicystructure defined in Table 35is not used by UASC implementations.

Table 42– Asymmetric algorithm Security header


Data Type




The length of the SecurityPolicyUriin bytes.

This value shall not exceed 255 bytes.

If a URI is not specified this value may be 0 or -1.

Other negative values are invalid.


Byte [*]

The URI of the Security Policyused to secure the Message.

This field is encoded as a UTF-8string without a null terminator.



The length of the SenderCertificatein bytes.

This value shall not exceed MaxSenderCertificateSizebytes.

If a certificate is not specified this value may be 0 or -1.

Other negative values are invalid.


Byte [*]

The X.509 v3 Certificateassigned to the sending applicationInstance.

This is a DER encoded blob.

The structure of an X.509 v3 Certificateis defined in X.509 v3.

The DER format for a Certificateis defined in X690

This indicates what Private Keywas used to sign the MessageChunk.

The Stackshall close the channel and report an error to the application if the SenderCertificateis too large for the buffer size supported by the transport layer.

This field shall be null if the Messageis not signed.

If the Certificateis signed by a CA, the DER encoded CA Certificatemay be appended after the Certificate in the byte array. If the CA Certificateis also signed by another CA this process is repeated until the entire Certificate chain is in the buffer or if MaxSenderCertificateSizelimit is reached (the process stops after the last whole Certificatethat can be added without exceeding the MaxSenderCertificateSizelimit).

Receivers can extract the Certificatesfrom the byte array by using the Certificatesize contained in DER header (see X.509 v3).

Receivers that do not handle Certificatechains shall ignore the extra bytes.



The length of the ReceiverCertificateThumbprintin bytes.

If encrypted the length of this field is 20 bytes.

If not encrypted the value may be 0 or -1.

Other negative values are invalid.


Byte [*]

The thumbprint of the X.509 v3 Certificateassigned to the receiving applicationInstance.

The thumbprint is the CertificateDigestof the DER encoded form of the Certificate.

This indicates what public key was used to encrypt the MessageChunk.

This field shall be null if the Messageis not encrypted.

The receiver shall close the communication channel if any of the fields in the security header have invalid lengths.

The SenderCertificate, includingany chains,shall be small enough to fit into a single MessageChunkand leave room for at least one byte of body information. The maximum size for the SenderCertificatecan be calculated with this formula:

MaxSenderCertificateSize =

MessageChunkSize –

12 - // Header size

4 - // SecurityPolicyUriLength

SecurityPolicyUri -// UTF-8 encoded string

4 - // SenderCertificateLength

4 - // ReceiverCertificateThumbprintLength

20 - // ReceiverCertificateThumbprint

8 - // SequenceHeader size

1 - // Minimum body size

1 - // PaddingSize if present

Padding - // Padding if present

ExtraPadding - // ExtraPadding if present

AsymmetricSignatureSize// If present

The MessageChunkSizedepends on the transport protocol but shall be at least 8 192 bytes. The AsymmetricSignatureSizedepends on the number of bits in the public key for the SenderCertificate. The Int32FieldLengthis the length of an encoded Int32 value and it is always 4 bytes.

The security header used for symmetric algorithms defined in Table 43. Symmetric algorithms are used to secure all Messagesother than the OpenSecureChannel Messages. FIPS 197define symmetric encryption algorithms that UASC implementations may use. FIPS 180-2and HMACdefine some symmetric signature algorithms.

Table 43– Symmetric algorithm Security header


Data Type




A unique identifier for the SecureChannel SecurityTokenused to secure the Message.

This identifier is returned by the Serverin an OpenSecureChannelresponse Message. If a Serverreceives a TokenId which it does not recognize it shall return an appropriate transport layer error.

The security header is always followed by the sequence header which is defined in Table 44. The sequence header ensures that the first encrypted block of every Messagesent over a channel will start with different data.

Table 44– Sequence header


Data Type




A monotonically increasing sequence number assigned by the sender to each MessageChunksent over the SecureChannel.



An identifier assigned by the Clientto OPC UA request Message. All MessageChunksfor the request and the associated response use the same identifier.

ASequenceNumber may not be reused for any TokenId. The SecurityTokenlifetime should be short enough to ensure that this never happens; however, if it does the receiver should treat it as a transport error and force a reconnect.

The SequenceNumbershall also monotonically increase for all Messagesand shall not wrap around until it is greater than 4 294 966 271 (UInt32.MaxValue – 1 024). The first number after the wrap around shall be less than 1 024. Note that this requirement means that a SequenceNumberdoes not reset when a new TokenIdis issued. The SequenceNumbershall be incremented by exactly one for each MessageChunksent unless the communication channel was interrupted and re-established. Gaps are permitted between the SequenceNumberfor the last MessageChunkreceived before the interruption and the SequenceNumberfor first MessageChunkreceived after communication was re-established. Note that the first MessageChunkafter a network interruption is always an OpenSecureChannelrequest or response. If gaps occur in any other case the receiver shall close the SecureChannel.

The sequence header is followed by the Messagebody which is encoded with the OPC UA Binary encoding as described in 5.2.9. The body may be split across multiple MessageChunks.

Each MessageChunkalso has a footer with the fields defined in Table 45.

Table 45– OPC UA Secure ConversationMessage footer


Data Type




The number of padding bytes (not including the byte for the PaddingSize).


Byte [*]

Padding added to the end of the Messageto ensure length of the data to encrypt is an integer multiple of the encryption block size.

The value of each byte of the padding is equal to PaddingSize.



The most significant byte of a two-byte integer used to specify the padding size when the key used to encrypt the message chunk is larger than 2 048 bits. This field is omitted if the key length is less than or equal to 2 048 bits.


Byte [*]

The signature for the MessageChunk.

The signature includes the all headers, all Messagedata, the PaddingSize and the Padding.

The formula to calculate the amount of padding depends on the amount of data that needs to be sent (called BytesToWrite). The sender shall first calculate the maximum amount of space available in the MessageChunk(called MaxBodySize) using the following formula:

MaxBodySize = PlainTextBlockSize * Floor ((MessageChunkSize –

HeaderSize - 1)/CipherTextBlockSize) –

SequenceHeaderSize – SignatureSize;

The HeaderSizeincludes the MessageHeaderand the SecurityHeader. The SequenceHeaderSizeis always 8 bytes.

During encryption a block with a size equal to PlainTextBlockSizeis processed to produce a block with size equal to CipherTextBlockSize. These values depend on the encryption algorithm and may be the same.

The OPC UA Messagecan fit into a single chunk if BytesToWriteis less than or equal to the MaxBodySize. In this case the PaddingSizeis calculated with this formula:

PaddingSize = PlainTextBlockSize –

((BytesToWrite + SignatureSize + 1) % PlainTextBlockSize);

If the BytesToWriteis greater than MaxBodySizethe sender shall write MaxBodySizebytes with a PaddingSize of 0. The remaining BytesToWriteMaxBodySizebytes shall be sent in subsequent MessageChunks.

The PaddingSizeand Paddingfields are not present if the MessageChunkis not encrypted.

The Signature field is not present if the MessageChunk is not signed.