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.

Figure 16 – Security transformation for OpenSecureChannel Request and Response for ECC-nistP256

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.

Figure 17 – Establish Secure Channel (ECC, 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=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 – Establish Secure Channel (ECC, Server View)

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.