The OPC UA Secure Conversation (UASC) mechanism described 6.7is designed for use with asymmetric cryptography algorithms, such as RSA, that allow Public Keysto 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.5without making the keys available to eavesdroppers. This negotiation uses a Diffie Hellman algorithm defined in RFC 8422and is shown in Figure 13.

image016.png

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 SecureChannelthe Clientgenerates a new key pair (JC, KC) and passes the Public Key(JC) in the request. After verifying the signature on the request, the Servergenerates a new key pair (JS, KS) and returns the Public Key(JS) in the response. The new key pairs are used each time a SecureChannelis 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 SecurityPolicydefined in OPC 10000-7specifies exactly one named curve which is used for the EphemeralKeys.

Each ECC ApplicationInstance Certificateis also based on a named curve. Each SecurityPolicyspecifies 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 Keysand digital signatures are the output of an ECC operation. The encoding of these outputs depends on the ECC curve and are described by the SecurityPolicyin OPC 10000-7.

Clause 6.7.4 specifies the contents of the OpenSecureChannelrequest and response messages. When using an ECC SecurityPolicythe ClientNonceis the Public Keyfor the Client’s EphemeralKeyencoded using the Public Key encoding for the curve. Similarly, the ServerNonceis the Public Keyfor the Server’s EphemeralKey.

The EphemeralKeysare used to calculate a shared secret by using the Private Keyof an EphemeralKeyand the Public Keyof 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

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.

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=ClientSaltand Info=ClientSaltas shown in Table 60.

Table 60– Deriving Client Keys from Keying Material

Name

Offset

Length

ClientSigningKey

0

DerivedSignatureKeyLength

ClientEncryptingKey

DerivedSignatureKeyLength

EncryptionKeyLength

ClientInitializationVector

DerivedSignatureKeyLength + EncryptionKeyLength

C – CounterLength

The server keys are extracted from the keying material created with IKM=shared secret, Salt= ServerSaltand Info=ServerSaltas shown in Table 61.

Table 61– Deriving Server Keys from Keying Material

Name

Offset

Length

ServerSigningKey

0

DerivedSignatureKeyLength

ServerEncryptingKey

DerivedSignatureKeyLength

EncryptionKeyLength

ServerInitializationVector

DerivedSignatureKeyLength + EncryptionKeyLength

InitializationVectorLength – CounterLength

The SymmetricEncryptionAlgorithm for the SecurityPolicysetsthe EncryptionKeyLengthand EncryptionBlockSize.

When using Authenticated Encryption, the SigningKeyand EncryptingKeyare always calculated, however, only one will be used. If the mode is SignAndEncryptthen the EncryptingKey is used. If the mode is Signthen the SigningKeyis used.

In addition, a unique InitializationVectoris needed for each Message. This value contructed from the ClientInitializationVectoror ServerInitializationVectorwhere the first 8 bytes are replaced by the values in Table 62encoded as described in 5.2.2.2.

Table 62– Creating a Mask for the Initialization Vector

Name

Bytes

Length

TokenId

4

The TokenIdspecified in the SecurityHeaderof MessageChunkbeing processed.

It is encoded as a UInt32as described in 5.2.2.2.

LastSequenceNumber

4

The SequenceNumberspecified in the SequenceHeaderof last MessageChunk sent in the same direction on the SecureChannel.

This number is 0 for the first message.

It is encoded as a UInt32as described in 5.2.2.2.

The ClientInitializationVectoris used when the Clientencrypts or signs and the ServerInitializationVector is used when the Serverencrypts or signs.

The LastSequenceNumberis the SequenceNumberfrom the previously sent Messagewhich normally requires the previous Messageto be decrypted. If the receiver processes incoming Messagesin parallel it can calculate the expected SequenceNumberbased on the order in which the encrypted Messagesare received.

When using Signmode it is necessary to have a SigningKeythat is unique and unpredictable for each message. The transformation defined for the InitializationVectoris applied to the ClientSigningKey(when the Clientsigns) or the ServerSigningKey(when the Serversigns). After applying the transformation, a hash is computed using the Hash function specified by the KeyDerivationAlgorithm. If the hash length is greater than or equal to the SigningKey length then the first SigningKeylength bytes from the hash are used. If the hash length is less than the SigningKeylength then the first hash length bytes of the SigningKeyare replaced with the hash.

Once the keys are derived ECC SecureChannelsbehave the same as RSA SecureChannels.

ActivateSessionallows a Clientto provide an encrypted UserIdentityTokenusing a SecurityPolicyspecified by a UserTokenPolicysupported by the current Endpoint. With ECC, encryption requires that the Clientand Serverexchange EphemeralKeysand there is no mechanism in the current CreateSession/ActivateSessionhandshake to do this. For that reason, EphemeralKeysare returned in the AdditionalHeaderfield of the ResponseHeaderof the CreateSessionand ActivateSessionresponses. An overview of the handshake is shown in Figure 14.

image017.png

Figure 14– ECC CreateSession/ActivateSession Handshake

The UserTokenPoliciesare returned in the GetEndpointsresponse. A UserTokenPolicymay specify a SecurityPolicyUrithat is different than the SecureChannel, however, all UserTokenPoliciesin an EndpointDescriptionshall specify a SecurityPolicyUrithat is valid for all Certificatesthat are valid for SecurityPolicyUrispecified in the EndpointDescription.For example, an EndpointDescriptionproviding an ECC SecurityPolicyUrishall not specify RSA SecurityPolicyUrisin the UserTokenPolicies.

When a Clientcalls CreateSessionvia a SecureChannelbased on an ECC SecurityPolicy the Clientspecifies the SecurityPolicyUriit plans to use for the UserIdentityTokenin the RequestHeader. Serverreturns an EphemeralKeyin the ResponseHeaderthat can be used for the SecurityPolicyUri specified by theClient. If the SecurityPolicyUri is not valid theServerreturns a StatusCodein the ResponseHeaderinstead of an EphemeralKey.

When theClient callsActivateSession it creates an EccEncryptedSecret(see OPC 10000-4) using the EphemeralKeyprovided in CreateSessionresponse. The Serveralways returns a new EphemeralKeyin the ResponseHeaderwhich the Clientsaves for when it calls ActivateSessionagain. The SecurityPolicyUri passed in CreateSessionis used to determine what type of EphemeralKeyto return.

The EphemeralKeys may be used for exactly one key negotiation. After that they are discarded. Each time ActivateSessionis called the UserIdentityToken is encrypted using the last EphemeralKeyreturned by the Server. The EphemeralKeyis changed even if the Clientdid not provide an encrypted UserIdentityToken.

If the Clientdoes not provide SecurityPolicyUri in the call to CreateSessionit will not be able to use any UserIdentityTokens that require encryption with ECC SecurityProfiles.

OPC 10000-4defines AdditionalParametersTypewhich is a list of name-value pairs. An instance of this type is passed in the AdditionalHeaderfield. Instances of the EphemeralKeyTypedefined in OPC 10000-4are passed as values in the name-value pair list in the response messages. The names used for the parameters defined for the CreateSession/ActivateSessionexchange are defined in Table 63.

Table 63– Additional Header Key Names

Name

DataType

Description

ECDHPolicyUri

String

Specifies the SecurityPolicyUriused for the EphemeralKeys.

ECDHKey

EphemeralKeyType

Specifies an EphemeralKey.

If the EphemeralKeycould not be created a StatusCodeindicating the reason for the error is used instead of an instance of EphemeralKeyType.

OPC 10000-4defines the layout of EccEncryptedSecretstructure which is used to protect secrets with ECC SecurityPolicies. Applying security with ECC requires two EphemeralKeysgenerated by the sender and the receiver which are used create the symmetric keys need for encryption.

6.8.2defines a mechanism to allows the sender to acquire the receiver EphemeralKeywhen 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.2. 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 ReceiverPublicKeyare 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 64.

Table 64– Deriving Keys from Keying Material

Name

Offset

Length

EncryptingKey

0

EncryptionKeyLength

InitializationVector

EncryptionKeyLength

InitializationVectorLength

The EncryptionKeyLengthand EncryptionBlockSizeare specified by the Symmetric Encryption Algorithmfor the SecurityPolicy. The Signatureis created with the SigningCertificateand is calculated after encryption. Receivers shall validate the SigningCertificate and signature before decrypting the Secret.