5.5 Use of Application Instance personality to establish a secure channel
An overview of the sequence to establish a secure channel is given in OPC 10000-6.
Establishing a secure channel can be supported by the following TrustAnchor capabilities:
Computation of asymmetric cryptographic operations using private keys. Long-term private keys, i.e., private keys corresponding to an application certificate, can effectively be protected by TrustAnchor capabilities. OPC UA Secure Conversation uses these keys for authentication (ECC and RSA) and key transport (RSA only).
Protecting the trusted certificates used to verify the remote party.
5.5.1 Elliptic Curve Profiles
OPC 10000-6 describes the secure channel handshake and key negotiation for ECC.
Figure 16 – shows the security transformation required on OpenSecureChannel Request and OpenSecureChannel Response involving ECC operations with the persistent EC private key. The basic cryptographic operation used is the computation of an EC signature.
Annex B.1 shows an example for an OpenSecureChannel Request using ECC-nistP256 for further reference.
For ECC profiles the key agreement of the symmetric key to be used to protect the secure channel completely relies on ephemeral keys. These ephemeral keys need to be authenticated by a digital signature produced by the respective identity personalities. The signature generation process is sensitive and should rely on functions of the TrustAnchor. However, any computations relying on the ephemeral keys is expected to be done in software and does not rely on functionality offered by the TrustAnchor.
Figure 17 illustrates how the related TrustAnchor functions fit into the process to establish a secure channel based on an ECC SecurityPolicy at the client side.
The personality to be used for establishing the secure channel is determined from the exchange of GetEndpoints Request/Response. The example assumes that the client’s identity personality is named urn:manufacturer.com:2024-10:myproduct:myclient_appid?cg=DefaultApplicationGroup&ct=EccNistP256&ix=1.
As a first step the client must verify the identity of the server claimed by means of the server certificate send within GetEndpoints Response. This requires certificate path validation against the configured TrustList. The integrity of the TrustList information is protected and shall be verified before relying on it. Integrity verification is done using the respective TrustList personality urn:manufacturer.com:2024-10:myproduct:myclient_appid?cg=DefaultApplicationGroup and profile ch.iec.30168.basic.local_data_integrity_only. The client calls gta_verify_data_detached() to check the correctness of the integrity protection seal stored alongside the TrustList. Whether verification of the TrustList is performed once every time a new secure channel is established, at regular intervals, or only once per device power-cycle depends on the desired security level and is left to the application.If the identity of the server is found to be valid the client starts to build the OpenSecureChannel Request.
Optionally, the client certificate can be retrieved from the identity personality using gta_personality_get_attribute().
Construction of the OpenSecureChannel Request involves the computation of a digital signature using the identity personality representing the client. The client calls gta_authenticate_data_detached() to calculate the required signature transformation ◯Figure 16 S as shown in Figure 16.
Figure 18 illustrates how the related TrustAnchor functions fit into the process to establish a secure channel based on an ECC SecurityPolicy at the server side.
The server selects the personality to be used for establishing the secure channel. The example assumes that the server’s identity personality is named urn:manufacturer.com:2024-10:myproduct:myserver_appid?cg=DefaultApplicationGroup&ct=EccNistP256&ix=1. Optionally, the server certificate can be retrieved from the identity personality using gta_personality_get_attribute().
After receiving the OpenSecureChannel Request the server must verify the identity of the client claimed by means of the client certificate provided by the OpenSecureChannel Request. This requires certificate path validation against the configured TrustList. The integrity of the TrustList information is protected and shall be verified before relying on it. Integrity verification is done using the respective TrustList personality urn:manufacturer.com:2024-10:myproduct:myserver_appid?cg=DefaultApplicationGroup and profile ch.iec.30168.basic.local_data_integrity_only. The server calls gta_verify_data_detached() to check the correctness of the integrity protection seal stored alongside the TrustList. Whether verification of the TrustList is performed once every time a new secure channel is established, at regular intervals, or only once per device power-cycle depends on the desired security level and is left to the application.If the identity of the client is found to be valid the client starts to build the OpenSecureChannel Response.
Construction of the OpenSecureChannel Response involves the computation of a digital signature using the identity personality representing the server. The server calls gta_authenticate_data_detached() to calculate the required signature transformation ◯Figure 16 S as shown in Figure 16.5.5.2 RSA Profiles
OPC 10000-6 6.7 (https://reference.opcfoundation.org/Core/Part6/v105/docs/6.7) describes the secure channel handshake and key negotiation used with RSA.
Figure 19 shows the security transformation required on OpenSecureChannel Request and OpenSecureChannel Response involving RSA operations with the persistent RSA private key. The basic cryptographic operations used are the computation of an RSA signature and the decryption of an RSA ciphertext used to exchange a secret between OPC client and OPC server.
Annex B.2 shows an example for an OpenSecureChannel Request using Aes256-Sha256-RsaPss for further reference.
Figure 20 illustrates how the related TrustAnchor functions fit into the process to establish a secure channel based on an RSA SecurityPolicy at the client side.
The personality to be used for establishing the secure channel is determined from the exchange of GetEndpoints Request/Response. The example assumes that the client’s identity personality is named urn:manufacturer.com:2024-10:myproduct:myclient_appid?cg=DefaultApplicationGroup&ct=Rsa2048&ix=1.
As a first step the client must verify the identity of the server claimed by means of the server certificate send within GetEndpoints Response. This requires certificate path validation against the configured TrustList. The integrity of the TrustList information is protected and shall be verified before relying on it. Integrity verification is done using the respective TrustList personality urn:manufacturer.com:2024-10:myproduct:myclient_appid?cg=DefaultApplicationGroup and profile ch.iec.30168.basic.local_data_integrity_only. The client calls gta_verify_data_detached() to check the correctness of the integrity protection seal stored alongside the TrustList. Whether verification of the TrustList is performed once every time a new secure channel is established, at regular intervals, or only once per device power-cycle depends on the desired security level and is left to the application.If the identity of the server is found to be valid the client starts to build the OpenSecureChannel Request.
Optionally, the client certificate can be retrieved from the identity personality using gta_personality_get_attribute().
Construction of the OpenSecureChannel Request involves the computation of a digital signature using the identity personality representing the client. The client calls gta_authenticate_data_detached() to calculate the required signature transformation ◯Figure 16 S as shown in Figure 19. Note that the required encryption operation uses the server’s public key and does not involve TrustAnchor functionality.
After sending the OpenSecureChannel Request the client receives the OpenSecureChannel response from the server. The client needs to extract the serverNonce from the encrypted part of the OpenSecureChannel Response. The client uses gta_unseal_data() to compute the decryption operation involving the client’s identity personality (Figure 19, ◯Figure 16 X).
Figure 21 illustrates how the related TrustAnchor functions fit into the process to establish a secure channel based on an RSA SecurityPolicy at the server side.
The server selects the personality to be used for establishing the secure channel. The example assumes that the server’s identity personality is named urn:manufacturer.com:2024-10:myproduct:myserver_appid?cg=DefaultApplicationGroup&ct=Rsa2048&ix=1. Optionally, the server certificate can be retrieved from the identity personality using gta_personality_get_attribute().
After receiving the OpenSecureChannel Request the server must verify the identity of the client claimed by means of the client certificate provided by the OpenSecureChannel Request. This requires certificate path validation against the configured TrustList. The integrity of the TrustList information is protected and shall be verified before relying on it. Integrity verification is done using the respective TrustList personality urn:manufacturer.com:2024-10:myproduct:myserver_appid?cg=DefaultApplicationGroup and profile ch.iec.30168.basic.local_data_integrity_only. The server calls gta_verify_data_detached() to check the correctness of the integrity protection seal stored alongside the TrustList. Whether verification of the TrustList is performed once every time a new secure channel is established, at regular intervals, or only once per device power-cycle depends on the desired security level and is left to the application.
If the identity of the server is found to be valid the server needs to extract the clientNonce from the encrypted part of the OpenSecureChannel Request. The server uses gta_unseal_data() to compute the decryption operation involving the server’s identity personality (Figure 19, ◯Figure 16 X).
Construction of the OpenSecureChannel Response involves the computation of a digital signature using the identity personality representing the server. The server calls gta_authenticate_data_detached() to calculate the required signature transformation ◯Figure 16 S as shown in Figure 19.