The OPC UA Secure Conversation (UASC) mechanism described 6.7 is designed for use with asymmetric cryptography algorithms, such as RSA, that allow Public Keys to be used for encryption and for digital signatures. ECC is an asymmetric cryptography algorithm that only supports digital signatures. To accommodate algorithms like ECC, the UASC handshake needs to be modified to allow negotiation of inputs used for key derivation in 6.7.5 without making the keys available to eavesdroppers. This negotiation uses a Diffie Hellman algorithm defined in RFC 8422 and is shown in Figure 13.
Figure 13 – ECC Key Negotiation
ApplicationInstance Certificates for ECC have a public-private key pair that are used to create and verify a digital signature. To negotiate the keys needed for the SecureChannel the Client generates a new key pair (JC, KC) and passes the Public Key (JC) in the request. After verifying the signature on the request, the Server generates a new key pair (JS, KS) and returns the Public Key (JS) in the response. The new key pairs are used each time a SecureChannel is negotiated and they are called EphemeralKeys.
ECC public-private key pairs are always based on a specific elliptic curve function which is used for the ECC calculations. Many curves exist, however, ECC cryptography libraries support a finite set of “named curves” to allow for better interoperability. Each OPC UA SecurityPolicy defined in OPC 10000-7 specifies exactly one named curve which is used for the EphemeralKeys.
Each ECC ApplicationInstance Certificate is also based on a named curve. Each SecurityPolicy specifies a list of named curves which are permitted for use in the ApplicationInstance Certificate. This list always includes the named curved used for the EphemeralKey, however, it may allow other named curves. OPC UA applications that support ECC SecurityPolicies will need to support multiple ApplicationInstance Certificates.
ECC Public Keys and digital signatures are the output of an ECC operation. The encoding of these outputs depends on the ECC curve and are described by the SecurityPolicy in OPC 10000-7.
Clause 6.7.4 specifies the contents of the OpenSecureChannel request and response messages. When using an ECC SecurityPolicy the ClientNonce is the Public Key for the Client’s EphemeralKey encoded using the Public Key encoding for the curve. Similarly, the ServerNonce is the Public Key for the Server’s EphemeralKey.
The encoding of the EphemeralKeys depends on the ECC curve used. For NIST and Brainpool curves the EphemeralKey is the x and y coordinate encoded as zero padded big-endian OctetString. For Edwards curves the EphemeralKey format is defined by RFC 7748.
The EphemeralKeys are used to calculate a shared secret by using the Private Key of an EphemeralKey and the Public Key of the peer’s EphemeralKey. The exact algorithm to calculate the shared secret depends on the ECC curve and is defined by the SecurityPolicy. This shared secret is then used to derive key data using the following algorithm from RFC 5869. Note that the algorithm is repeated here for clarity, however, the RFC is the normative source.
Step 1: Calculate Salts
ServerSalt = L | UTF8(opcua-server) | ServerNonce | ClientNonce
ClientSalt = L | UTF8(opcua-client) | ClientNonce | ServerNonce
Where
- L is the length of derived key material needed encoded as a 16-bit little endian integer;
- UTF8(label) is the UTF8 encoding of the string literal ‘label’;
- ServerNonce is the Server EphemeralKey from the OpenSecureChannel response;
- ClientNonce is the Client EphemeralKey from the OpenSecureChannel request;
- | concatenates sequences of bytes;
- Salt is a sequence of bytes.
Step 2: Extract
PRK = HMAC-Hash(Salt, IKM)
Where
- HMAC uses a Hash function specified by the KeyDerivationAlgorithm;
- IKM is the x-coordinate of the shared secret;
- Salt is calculated in Step 1;
- PRK is a pseudorandom output with length equal to the Hash size.
The encoding of the x-coordinate depends on the ECC curve used. For NIST and Brainpool curves the x-coordinate is encoded as a zero padded big-endian OctetString. For Edwards curves the coordinate format is defined by RFC 7748.
Step 3: Expand
N = ceil(L/HashLen)
T = T(1) | T(2) | T(3) | ... | T(N)
OKM = first L octets of T
where:
T(0) = empty string (zero length)
T(1) = HMAC-Hash(PRK, T(0) | Info | 0x01)
T(2) = HMAC-Hash(PRK, T(1) | Info | 0x02)
T(3) = HMAC-Hash(PRK, T(2) | Info | 0x03)
...
Where
- HMAC uses a Hash function specified by the KeyDerivationAlgorithm;
- PRK is the output from Step 1;
- Info is a sequence of bytes;
- L is the length of keying material needed;
- 0x01 is the number 1 encoded as a byte.
- OKM is the output with length equal to L bytes.
The client keys are extracted from the keying material created with IKM=shared secret, Salt=ClientSalt and Info=ClientSalt as shown in Table 63.
Table 63 – Deriving Client Keys from Keying Material
|
Name |
Offset |
Length |
|
ClientSigningKey |
0 |
DerivedSignatureKeyLength |
|
ClientEncryptingKey |
DerivedSignatureKeyLength |
EncryptionKeyLength |
|
ClientInitializationVector |
DerivedSignatureKeyLength + EncryptionKeyLength |
InitializationVectorLength |
The server keys are extracted from the keying material created with IKM=shared secret, Salt= ServerSalt and Info=ServerSalt as shown in Table 64.
Table 64 – Deriving Server Keys from Keying Material
|
Name |
Offset |
Length |
|
ServerSigningKey |
0 |
DerivedSignatureKeyLength |
|
ServerEncryptingKey |
DerivedSignatureKeyLength |
EncryptionKeyLength |
|
ServerInitializationVector |
DerivedSignatureKeyLength + EncryptionKeyLength |
InitializationVectorLength |
The SymmetricEncryptionAlgorithm for the SecurityPolicy sets the EncryptionKeyLength and EncryptionBlockSize.
When using AuthenticatedEncryption, the SigningKey, EncryptingKey and InitializationVector are always calculated, however, only the EncryptingKey and InitializationVector are used. The only difference between Sign and SignAndEncrypt is the length of encrypted data which is zero when Sign is used. The process of signing and encrypting data with AuthenticatedEncryption is illustrated in Figure 14.
Figure 14 – Signing and Encryption with Authenticated Encryption
When using UnauthenticatedEncryption with Sign only the SigningKey needs to be computed, however, the length of the derived key material used to calculate the Salt shall be the same as the length of the derived key material used with SignAndEncrypt. The encryption algorithm is not used and the padding is zero length when using Sign mode. The process of signing and encrypting data with UnauthenticatedEncryption is illustrated in Figure 15.
Figure 15 – Signing and Encryption with Unauthenticated Encryption
In addition, a unique InitializationVector is needed for each Message. This value constructed from the ClientInitializationVector or ServerInitializationVector where the first 8 bytes are XORed with the values in Table 65 encoded as described in 5.2.2.2.
Table 65 – Creating a Mask for the Initialization Vector
|
Name |
Bytes |
Length |
|
TokenId |
4 |
The TokenId specified in the SecurityHeader of MessageChunk being processed. It is encoded as a UInt32 as described in 5.2.2.2. |
|
LastSequenceNumber |
4 |
The SequenceNumber specified in the SequenceHeader of last MessageChunk sent in the same direction on the SecureChannel. The value is 0 to indicate there is no LastSequenceNumber for the first MessageChunk which is always the OpenSecureChannel Message. It is encoded as a UInt32 as described in 5.2.2.2. |
The ClientInitializationVector is used when the Client encrypts the MessageChunk and the ServerInitializationVector is used when the Server encrypts the MessageChunk.
The LastSequenceNumber is the SequenceNumber from the previously sent Message which normally requires the previous Message to be decrypted. If the receiver processes incoming Messages in parallel it can calculate the expected SequenceNumber based on the order in which the encrypted Messages are received.
Once the keys are derived ECC SecureChannels behave the same as RSA SecureChannels.
ActivateSession allows a Client to provide an encrypted UserIdentityToken using a SecurityPolicy specified by a UserTokenPolicy supported by the current Endpoint. With ECC, encryption requires that the Client and Server exchange EphemeralKeys and there is no mechanism in the current CreateSession/ActivateSession handshake to do this. For that reason, EphemeralKeys are returned in the AdditionalHeader field of the ResponseHeader of the CreateSession and ActivateSession responses. An overview of the handshake is shown in Figure 16.
Figure 16 – ECC CreateSession/ActivateSession Handshake
The UserTokenPolicies are returned in the GetEndpoints response. A UserTokenPolicy may specify a SecurityPolicyUri that is different than the SecureChannel, however, all UserTokenPolicies in an EndpointDescription shall specify a SecurityPolicyUri that is valid for all Certificates that are valid for SecurityPolicyUri specified in the EndpointDescription. For example, an EndpointDescription providing an ECC SecurityPolicyUri shall not specify RSA SecurityPolicyUris in the UserTokenPolicies.
When a Client calls CreateSession via a SecureChannel based on an ECC SecurityPolicy the Client specifies the SecurityPolicyUri it plans to use for the UserIdentityToken in the RequestHeader. Server returns an EphemeralKey in the ResponseHeader that can be used for the SecurityPolicyUri specified by the Client. If the SecurityPolicyUri is not valid the Server returns a StatusCode in the ResponseHeader instead of an EphemeralKey.
When the Client calls ActivateSession it creates an EccEncryptedSecret (see OPC 10000-4) using the EphemeralKey provided in CreateSession response. The Server always returns a new EphemeralKey in the ResponseHeader which the Client saves for when it calls ActivateSession again. The SecurityPolicyUri passed in CreateSession is used to determine what type of EphemeralKey to return.
The EphemeralKeys may be used for exactly one key negotiation. After that they are discarded. Each time ActivateSession is called the UserIdentityToken is encrypted using the last EphemeralKey returned by the Server. The EphemeralKey is changed even if the Client did not provide an encrypted UserIdentityToken.
If the Client does not provide SecurityPolicyUri in the call to CreateSession it will not be able to use any UserIdentityTokens that require encryption with ECC SecurityProfiles.
OPC 10000-4 defines AdditionalParametersType which is a list of name-value pairs. An instance of this type is passed in the AdditionalHeader field. Instances of the EphemeralKeyType defined in OPC 10000-4 are passed as values in the name-value pair list in the response messages. The names used for the parameters defined for the CreateSession/ActivateSession exchange are defined in Table 66.
Table 66 – Additional Header Key Names
|
Name |
DataType |
Description |
|
ECDHPolicyUri |
String |
Specifies the SecurityPolicyUri used for the EphemeralKeys. |
|
ECDHKey |
EphemeralKeyType |
Specifies an EphemeralKey. If the EphemeralKey could not be created a StatusCode indicating the reason for the error is used instead of an instance of EphemeralKeyType. |
OPC 10000-4 defines the layout of EccEncryptedSecret structure which is used to protect secrets with ECC SecurityPolicies. Applying security with ECC requires two EphemeralKeys generated by the sender and the receiver which are used create the symmetric keys need for encryption.
6.8.1 defines a mechanism to allows the sender to acquire the receiver EphemeralKey when using a Session. Using the EccEncryptedSecret in other contexts requires a different mechanism.
Once the sender has the receiver EphemeralKey, it creates its own EphemeralKey. The ECC curve and key length for the EphemeralKeys are specified by the SecurityPolicyUri.
The encryption uses the symmetric encryption algorithm specified by the SecurityPolicyUri. The encrypting key and initialization vector are generated by using the EphemeralKeys to create the shared secret and then derive keys using the algorithm defined in 6.8.1. Step 1 is slightly different and defined as follows:
Step 1: Calculate Salt
SecretSalt = L | UTF8(opcua-secret) | SenderPublicKey | ReceiverPublicKey
Where:
- L is the length of derived key material needed encoded as a 16-bit little endian integer;
- UTF8(opcua-secret) is the UTF8 encoding of the string literal ‘opcua-secret’;
- SenderPublicKey and ReceiverPublicKey are from the PolicyHeader;
- | concatenates sequences of bytes;
Salt is a sequence of bytes.
The encryption keys are extracted from the keying material created with IKM=shared secret, Salt=SecretSalt and Info=SecretSalt as shown in Table 67.
Table 67 – Deriving Keys from Keying Material
|
Name |
Offset |
Length |
|
EncryptingKey |
0 |
EncryptionKeyLength |
|
InitializationVector |
EncryptionKeyLength |
InitializationVectorLength |
The EncryptionKeyLength and EncryptionBlockSize are specified by the Symmetric Encryption Algorithm for the SecurityPolicy. The Signature is created with the SigningCertificate and is calculated after encryption. Receivers shall validate the SigningCertificate and signature before decrypting the Secret.