The security algorithms used and the length of the KeyNonce for the UADP NetworkMessage depend on the selected SecurityPolicy. The algorithms are defined by SymmetricEncryptionAlgorithm and SymmetricSignatureAlgorithm in OPC 10000-7. The nonce length is part of the SymmetricEncryptionAlgorithm.
The keys used to encrypt and sign messages are extracted from the key data returned from the GetSecurityKeys method (see 8.3.2). This Method returns a sequence of key data with a length that depends on the SecurityPolicyUri, which is also returned by the Method. The layout of the key data is defined in Table 138.
Table 138 – 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 Key Length] |
Encryption key part of the key data returned from GetSecurityKeys. The SymmetricEncryptionAlgorithm is defined in the SecurityPolicy. |
|
KeyNonce |
Byte [SymmetricEncryption Nonce Length] |
Nonce part of the key data returned from GetSecurityKeys. |
The layout of the MessageNonce for AES-CTR mode is defined in Table 139.
Table 139 – 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 |
Sequence number for the MessageNonce as defined in 7.2.3. The sequence number is reset to 1 after the key and SecurityTokenId are updated in the Publisher. |
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 138. The layout and content of the counter block is defined in Table 140.
Table 140 – Layout of the counter block for UADP message security for AES-CTR
|
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 1 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 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 or a Publisher receives a NetworkMessage, it shall verify the signature before processing the payload. If verification fails, it drops the NetworkMessage.
Other SecurityPolicy may specify different key lengths or cryptography algorithms.