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.
Figure 19 – Security transformations for OpenSecureChannel Request and Response for Aes256-Sha256-RsaPss
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.
Figure 20 – Establish Secure Channel (RSA, Client View)
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 – Establish Secure Channel (RSA, Server View)
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.