Errata exists for this version of the document.
The algorithm and nonce length used of the UADP NetworkMessage security depend on the selected SecurityPolicy. They are defined by SymmetricPubSubEncryptionAlgorithm and SymmetricPubSubNonceLength.
The keys used to encrypt and sign messages are returned from the GetSecurityKeys method (see 8.4). This Method returns a sequence of random data with a length that depends on the SecurityPolicyUri, which is also returned by the Method. The layout of the random data is defined in Table 74.
Table 74 – Layout of the key data for UADP message security
|
Name |
Type |
Description |
|
SigningKey |
Byte [SymmetricSignatureAlgorithm Key Length] |
Signing key part of the key data returned from GetSecurityKeys. The SymmetricSignatureAlgorithm is defined in the SecurityPolicy. |
|
EncryptingKey |
Byte [SymmetricEncryptionAlgorithm KeyLength] |
Encryption key part of the key data returned from GetSecurityKeys. The SymmetricEncryptionAlgorithm is defined in the SecurityPolicy. |
|
KeyNonce |
Byte [SymmetricPubSubNonceLength] |
Nonce part of the key data returned from GetSecurityKeys. |
The layout of the MessageNonce for AES-CTR mode is defined in Table 75.
Table 75 – Layout of the MessageNonce for AES-CTR
|
Name |
Type |
Description |
|
Random |
Byte [4] |
The random part of the MessageNonce. This number does not need to be a cryptographically random number, it can be pseudo-random. |
|
SequenceNumber |
UInt32 |
A strictly monotonically increasing sequence number assigned by the publisher to each NetworkMessage sent for a SecurityTokenId and PublisherId combination. The sequence number is reset to 1 after the key and SecurityTokenId are updated in the Publisher. A receiver should ignore older NetworkMessages than the last sequence processed if it does not handle reordering of NetworkMessages. Receivers need to be aware of sequence numbers roll over (change from 4294967295 to 0). To determine whether a received NetworkMessages is newer than the last processed NetworkMessages the following formula shall be used: (4294967295 + received sequence number – last processed sequence number) modulo 4294967296. Results below 1073741824 indicate that the received NetworkMessages is newer than the last processed NetworkMessages and the received NetworkMessages is processed. Results above 3221225472 indicate that the received message is older (or same) than the last processed NetworkMessages and the received NetworkMessages should be ignored if reordering of NetworkMessages is not necessary. Other results are invalid and the NetworkMessages shall be ignored. The key lifetime should be selected in a way that a new key is used before a rollover for the SequenceNumber happens. Subscribers shall reset the records they keep for sequence numbers if they do not receive messages for two times the keep alive time to deal with Publishers that are out of service and were not able to continue from the last used SequenceNumber. |
The message encryption and decryption with AES-CTR mode uses a secret and a counter block. The secret is the EncryptingKey from the key data defined in Table 74. The layout and content of the counter block is defined in Table 76.
Table 76 – Layout of the counter block for UADP message security
|
Name |
Type |
Description |
|
KeyNonce |
Byte [4] |
The KeyNonce portion of the key data returned from GetSecurityKeys. |
|
MessageNonce |
Byte [8] |
The first 8 bytes of the Nonce in the SecurityHeader of the NetworkMessage. For AES-CTR mode the length of the SecurityHeader Nonce shall be 8 Bytes. |
|
BlockCounter |
Byte [4] |
The counter for each encrypted block of the NetworkMessage. The counter is a 32-bit big endian integer (the opposite of the normal encoding for UInt32 values in OPC UA. This convention comes from the AES-CTR RFC). The counter starts with 0 at the first block. The counter is incremented by 1 for each block. |
AES-CTR mode takes the counter block and encrypts it using the encrypting key. The encrypted key stream is then logically XORed with the data to encrypt or decrypt. The process is repeated for each block in the plain text. No padding is added to the end of the plain text. AES-CTR does not change the size of the plain text data and can be applied directly to a memory buffer containing the message.
The signature is calculated on the entire NetworkMessage including any encrypted data. The signature algorithm is specified by the SecurityPolicyUri in OPC 10000-7.
When a Subscriber receives a NetworkMessage, it shall verify the signature first. If verification fails, it drops the NetworkMessage.
Other SecurityPolicy may specify different key lengths or cryptography algorithms.