6.7.2 MessageChunk structure
6.7.2.1 Overview
The structure of the MessageChunks exchanged after a SecureChannel is negotiated depends on whether the SecurityPolicy requires a symmetric encryption algorithm that combines encryption and authentication (e.g. AuthenticatedEncryption algorithms) used or if it requires separate symmetric algorithms for each operation.
Figure 11 shows the structure of a MessageChunk and how security is applied to the Message when not using AuthenticatedEncryption algorithms. For these SecurityPolicies any padding is appended to the message before appending the Signature. When using Sign mode, the Padding is not present.
Figure 12 shows the structure of a MessageChunk and how security is applied to the Message when using Authenticated Encryption algorithms. For these SecurityPolicies the Signature is calculated during encryption and appended after the encrypted data.
The OpenSecureChannel negotiations use asymmetric algorithms. The MessageChunk structure is shown in Figure 13. When using ECC or RSA-DH based algorithms there are additional steps described in 6.7.5.
6.7.2.2 Message Header
Every MessageChunk has a Message header with the fields defined in Table 57.
| Name | Data Type | Description |
|---|---|---|
| MessageType | Byte [3] | A three byte ASCII code that identifies the Message type. The following values are defined at this time: MSG A Message secured with the keys associated with a channel. OPN OpenSecureChannel Message. CLO CloseSecureChannel Message. |
| IsFinal | Byte | A one byte ASCII code that indicates whether the MessageChunk is 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 Message is aborted). This field is only meaningful for MessageType of ‘MSG’ This field is always ‘F’ for other MessageTypes. |
| MessageSize | UInt32 | The length of the MessageChunk, in bytes. The length starts from the beginning of the MessageType field. |
| SecureChannelId | UInt32 | A unique identifier for the SecureChannel assigned by the Server. If a Server receives a SecureChannelId which it does not recognize it shall return an appropriate transport layer error. When a Server starts the first SecureChannelId used should be a value that is likely to be unique after each restart. This ensures that a Server restart does not cause previously connected Clients to accidently ‘reuse’ SecureChannels that did not belong to them. |
6.7.2.3 Security Header
The Message header 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 58. Asymmetric algorithms are used to secure the OpenSecureChannel Messages. PKCS #1 defines a set of asymmetric algorithms that may be used by UASC implementations. The AsymmetricKeyWrapAlgorithm element of the SecurityPolicy structure defined in Table 49 is not used by UASC implementations.
| Name | Data Type | Description |
|---|---|---|
| SecurityPolicyUriLength | Int32 | The length of the SecurityPolicyUri in 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. |
| SecurityPolicyUri | Byte [] | The URI of the Security Policy used to secure the Message. This field is encoded as a UTF-8 string without a null terminator. |
| SenderCertificateLength | Int32 | The length of the SenderCertificate in bytes. This value shall not exceed MaxSenderCertificateSize bytes. If a certificate is not specified this value may be 0 or -1. Other negative values are invalid. |
| SenderCertificate | Byte [] | The X.509 v3 Certificate assigned to the sending application Instance. This is a DER encoded blob. The structure of an X.509 v3 Certificate is defined in X.509 v3. The DER format for a Certificate is defined in X.690 This indicates what Private Key was used to sign the MessageChunk. The Stack shall close the channel and report an error to the application if the SenderCertificate is too large for the buffer size supported by the transport layer. This field shall be null if the Message is not signed. If the Certificate is signed by a CA, the DER encoded CA Certificate may be appended after the Certificate in the byte array. If the CA Certificate is also signed by another CA this process is repeated until the entire Certificate chain is in the buffer or if MaxSenderCertificateSize limit is reached (the process stops after the last whole Certificate that can be added without exceeding the MaxSenderCertificateSize limit). Receivers can extract the Certificates from the byte array by using the Certificate size contained in DER header (see X.509 v3). Receivers that do not handle Certificate chains shall ignore the extra bytes. |
| ReceiverCertificateThumbprintLength | Int32 | The length of the ReceiverCertificateThumbprint in bytes. When using RSA Public Keys: If encrypted, the value of this field is 20 bytes. If not encrypted the value may be 0 or -1. When using ECC or RSA-DH Public Keys: The value of this field is 20 bytes. Other negative values are invalid. |
| ReceiverCertificateThumbprint | Byte [] | The thumbprint of the X.509 v3 Certificate assigned to the receiving application Instance. The thumbprint is the SHA1 hash of the DER encoded form of the Certificate. When using RSA PublicKeys, it indicates which Public Key was used to encrypt the MessageChunk. When using ECC or RSA-DH Public Keys it indicates the intended recipient of the MessageChunk. The receiver shall reject the MessageChunk if the Certificate identified does not match the Certificate it is using for the SecureChannel. |
The receiver shall close the communication channel if any of the fields in the security header have invalid lengths.
The SenderCertificate, including any chains, shall be small enough to fit into a single MessageChunk and leave room for at least one byte of body information. The maximum size for the SenderCertificate can 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 presentThe MessageChunkSize depends on the transport protocol but shall be at least 8192 bytes. The AsymmetricSignatureSize depends on the number of bits in the public key for the SenderCertificate. The Int32FieldLength is the length of an encoded Int32 value and it is always 4 bytes.
| Name | Data Type | Description |
|---|---|---|
| TokenId | UInt32 | A unique identifier for the SecureChannel SecurityToken used to secure the Message. This identifier is returned by the Server in an OpenSecureChannel response Message. If a Server receives a TokenId which it does not recognize it shall return an appropriate transport layer error. |
6.7.2.4 Sequence Header
The security header is always followed by the sequence header which is defined in Table 60. The sequence header ensures that the first encrypted block of every Message sent over a channel will start with different data.
| Name | Data Type | Description |
|---|---|---|
| SequenceNumber | UInt32 | A monotonically increasing sequence number assigned by the sender to each MessageChunk sent over the SecureChannel. |
| RequestId | UInt32 | An identifier assigned by the Client to OPC UA request Message. All MessageChunks for the request and the associated response use the same identifier. |
A SequenceNumber shall not be reused for any TokenId. The SecurityToken lifetime shall be short enough to ensure that this never happens; however, if it does the receiver shall treat it as a transport error and force a reconnect. The SequenceNumber does not reset when a new TokenId is issued and it shall be incremented by exactly one for each MessageChunk sent.
SecurityPolicies with LegacySequenceNumbers set to TRUE, the SequenceNumber shall monotonically increase for all Messages and shall not wrap around until it is greater than 4 294 966 271 (UInt32.MaxValue – 1024). The first number after the wrap around shall be less than 1024.
SecurityPolicies with LegacySequenceNumbers set to FALSE, the SequenceNumber shall start at 0 and monotonically increase for all Messages and shall not wrap around until it is equal to 4 294 967 295 (UInt32.MaxValue). The first number after the wrap around shall be 0.
Some applications will find it takes time to validate the OpenSecureChannel Requests and Responses used to renew a TokenId. In these situations, the receiver may assume the SequenceNumber is correct which allows it to process subsequent messages secured with the existing TokenId before the OpenSecureChannel Message is validated. When processing of the OpenSecureChannel Message completes, the receiver checks the SequenceNumber and closes the SecureChannel if it is incorrect.
The sequence header is followed by the Message body which is encoded with the OPC UA Binary encoding as described in 5.2.9. The body may be split across multiple MessageChunks.
6.7.2.5 Message Footer
6.7.2.5.1 Encryption other than Authenticated Symmetric Encryption (AEAD)
When using encryption with algorithms other than AEAD, each MessageChunk has a footer with the fields defined in Table 61.
The formula to calculate the amount of padding depends on the amount of data that is being 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 – MessageHeaderSize - SecurityHeaderSize – SignatureSize - 1)/CipherTextBlockSize) – SequenceHeaderSize;The MessageHeaderSize is 12 bytes and the SecurityHeader size depends on whether symmetric or asymmetric cryptography is used. The SequenceHeaderSize is always 8 bytes.
During encryption, a block with a size equal to PlainTextBlockSize is 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 Message can fit into a single chunk if BytesToWrite is less than or equal to the MaxBodySize. In this case the PaddingSize is calculated with this formula:
PaddingSize = PlainTextBlockSize –
((BytesToWrite + SignatureSize + 1) % PlainTextBlockSize);If the BytesToWrite is greater than MaxBodySize the sender shall write MaxBodySize bytes with a PaddingSize of 0. The remaining BytesToWrite – MaxBodySize bytes shall be sent in subsequent MessageChunks.
6.7.2.5.2 Authenticated Encryption Algorithms (AEAD)
When not using encryption or when using AEAD algorithms, each MessageChunk has a footer with the fields defined in Table 62.