5 Use cases

5.1 General

This subclause describes the use cases of interest when using a secure element to protect the security objects used by OPC UA. The following scenarios are considered:

5.2 Device onboarding

Transition from a DeviceIdentity personality to DCA personality.

5.2.1 Preconditions

The device onboarding scenarios described in 5.2 makes the following assumptions:

For illustration the figures and explanations in sections 5.2.3.1 and 5.2.3.2 assume that the profile used for the DCA Personality is org.opcfoundation.ECC-nistp521 and substitutes examples values where values are to be supplied by the DCA:

urn:manufacturer.com:2024-10:myproduct:SN51235 for the ProductInstanceUri

urn:manufacturer.com:2024-10:myproduct:SN51235?cg=DefaultApplicationGroup&ct=EccNistP256 for the base personality name of the DCA Identity Personality

urn:manufacturer.com:2024-10:myproduct:SN51235?cg=DefaultApplicationGroup for the personality name of the DCA Trustlist Personality

For simplification all personalities are assumed to be created with initial access for access control (cf. ISO/IEC TS 30168 ED 1, 5.6.5.1). Refer to 7.1 for further information on access control.

5.2.2 Selection of DeviceIdentity for onboarding

The first step in the onboarding process is the selection of identities that the DCA offers to the Registrar.

There are different options available to enable the DCA to discover the available GTA API DeviceIdentity personalities (4.3.3).

Start from a well-known vendor defined personality name. This is the most straight forward approach. Figure 7 illustrates the interaction of DCA with GTA API. A vendor may also provide a list of personality names that can be provided to the Registrar.

Start from a well-known vendor defined identifier. Multiple DeviceIdentity personalities can be associated with the same identifier, e.g., to support different profiles. Figure 8 illustrates the interaction of DCA with GTA API. It is possible that multiple personalities are eligible for onboarding and are offered to the Registrar.

Start from a well-known vendor defined application name. Multiple personalities can be assigned the same application name. Figure 9 illustrates the interaction of DCA with GTA API. It is possible that multiple personalities are eligible for onboarding and are offered to the registrar.

Search for a personality flagged with the dedicated attribute type org.opcfoundation.product_instance_uri. Figure 10 illustrates the interaction of DCA with GTA API. It is possible that multiple personalities are eligible for onboarding and are offered to the Registrar.

The device vendor should advise the implementor of the DCA which options apply for a specific device.

Figure 7 – Discover DeviceIdentity personality using personality name
Figure 8 – Discover DeviceIdentity personality using identifier value
Figure 9 – Discover DeviceIdentity personality using application name

Annex A.1.1 provides a code example for the search and discovery of personalities by the application name.

Figure 10 – Discover DeviceIdentity personality using attribute type org.opcfoundation.product_instance_uri
Annex A.1.2 provides a code example for the search and discovery of personalities using attribute type org.opcfoundation.product_instance_uri.
The call to gta_context_open() at the end of each sequence is representative for any further operations the DCA intends to do with the selected personality, e.g., retrieval of the Device Identity Certificate that may be stored as part of the DeviceIdentity personality as shown in Figure 11.
Figure 11 – Get DeviceIdentity Certificate

Annex A.2 gives an example for the retrieval of personality attributes.

5.2.3 Provisioning of DCA’s Application Instance (Certificate)

This section shows how interaction with GTA API on the local endpoint maps into the overall onboarding process. During the course of the onboarding process a new personality for the DCA is created. The following operations are of interest with respect to the trust anchor:

Generate a new public/private key pair

Sign the proof-of-possession

Optional: Store end-entity certificate chain as part of the personality

Store the list of trusted certificates belonging to the DCA personality

The examples in this section use the ECC profile org.opcfoundation.ECC-nistP256 (6.1). They can be easily adapted to RSA by simply exchanging the profile name.
5.2.3.1 Pull Management

Figure 12 illustrates the use of TrustAnchor capabilities integrated in the Pull Management process (See OPC 10000-21).

Figure 12 – Onboarding of Device Configuration Application (Pull Management)

The process starts from selecting a DeviceIdentity(s) that are eligible for onboarding (see 5.2.2). The DCA client needs to maintain a mapping between DeviceIdentity certificates and the corresponding Device Identity personality.

The DCA client proposes all available DeviceIdentity to the Registrar which replies with the selected DeviceIdentity certificate.

The DCA client uses the selected DeviceIdentity to create a secure channel to the Registrar. Create SecureChannel involves the computation of a digital signature (gta_authenticate_data_detached()). Further details for establishing a secure channel are explained in 5.5. Since the DCA client did not yet store any trusted certificates there is no authentication of the Registrar.
The DCA client creates a new identifier for the DCA and creates a new DCA Identity Personality for that identifier (gta_identifier_assign(), gta_personality_create()). The identifier value and personality name are set according to 4.3.2.1 and 4.3.4.
After creation of the DCA Identity personality the DCA prepares to file a certificate signing request (CSR) for its own DCA Certificate (cf. OPC 10000-6 6.2, Table 45; ). Upfront the device specific information that should be included in the CSR is setup (gta_context_set_attribute()). Finally the proof-of-possession is computed and the completed CSR is returned to the DCA client (gta_pesonality_enroll()) and forwarded to the Registrar.

After the Registrar has processed the certificate signing request it provides the DCA Certificate and the DCA TrustList, i.e., the list of certificates that the DCA shall regard as trustworthy for future communications with OPC UA infrastructure services (e.g., Registrar., Certificate Manager)

Storage of the DCA Certificate within the trust anchor is optional as the certificate is protected by the issuer’s signature. 

The integrity of the DCA TrustList shall be protected by the TrustAnchor. The DCA creates a dedicated DCA TrustList personality using the local data protection profile ch.iec.30168.basic.local_data_integrity_only. Storage of the TrustList objects is left to the application. The integrity of the TrustList objects is protected using a seal computed with gta_authenticate_data_detached(). The returned integrity protection seal is to be stored along-side the respective TrustList object by the application.
5.2.3.2 Push Management

Figure 13 illustrates the use of TrustAnchor capabilities integrated in the Push Management process (See OPC 10000-21).

Figure 13 – Onboarding of Device Configuration Application (Push Management)

In response to a GetEndpoints request received from the registrar the DCA server compiles a list of DeviceIdentity(s) that are eligible for onboarding (see 5.2.2). The DCA server needs to maintain a mapping between DeviceIdentity certificates and the corresponding DeviceIdentity personality. The list of EndpointDescriptions created from the available DeviceIdentity certificates is returned to the Registar.

The Registrar selects one DeviceIdentity and starts a create SecureChannel Request. Details for establishing a SecureChannel are explained in 5.5. The DeviceIdentity selected by the Registrar is indicated by the ReceiverCertificateThumbprint contained in the security header (See OPC 10000-6).

The subsequent actions of the DCA server towards the GTA API correspond to Pull Management.

The sequence following on CreateSigningRequest (Push) corresponds to the sequence used to prepare StartSigningRequest (Pull).

The sequence following on UpdateCertificate (Push) corresponds to the sequence following the response to StartSigningRequest (Pull)

The sequence following on UpdateTrustList (Push) corresponds to the sequence following the response to GetTrustList (Pull)

5.3 Update of DCA’s Application Instance (Certificate)

Figure 14 illustrates the update of the DCA Personality Set using PullManagement. The DCA Personality Set is assumed to be the result of the process described in 5.2.3.1.

As long as GTA API does not offer a functionality for in-place update of an existing personality (for example, &ix=1) the update process needs to create a new personality (for example, &ix=2) and removes the outdated personality (&ix=1) once the process has completed successfully.

Figure 14 – Update of Device Configuration Application (Pull Management)

As a precondition for all subsequent information exchanges between the DCA Client and the Certificate Manager, the DCA Client creates a secure channel to the Registrar using the existing DCA Identity Personality (4.3.4) named urn:manufacturer.com:2024-10:myproduct:SN51235?cg=DefaultApplicationGroup&ct=EccNistP256&ix=1. Details on how to establish a secure channel using an existing personality are described in 5.5.

As the existing personality (&ix=1) is required until the update finishes successfully the DCA application creates a new personality named urn:manufacturer.com:2024-10:myproduct:SN51235?cg=DefaultApplicationGroup&ct=EccNistP256&ix=2 to accept the updated security objects. After receiving the new DCA Certificate, the old DCA Identity Personality is removed (gta_personality_remove()).
As in the initial onboarding process gta_personality_authenticate_data_detached() is used to compute integrity protection seals for the updated TrustList Objects.

Update of the DCA Identity Personality and TrustList can be performed in independent processes.

Update of the DCA Personality Set using Push Management works accordingly. The interactions between DCA application and GTA API are not affected by using either Push or Pull Management.

5.4 Provisioning of Application Instance

Figure 15 illustrates the use of TrustAnchor capabilities integrated in the Pull Management process for provisioning of Application Instance (cf. OPC 10000-21 7.2, Figure 5; https://reference.opcfoundation.org/Onboarding/v105/docs/7.2).

	Generate private key (gta_personality_create())
	Sign proof-of-possession on CSR (gta_personality_enroll())
	Write end-entity certificate (gta_personality_add_attribute())
	Protect TrustList for Application PKI domain (gta_authenticate_data_detached())
Figure 15 – Provisioning of Application Instance (Pull Management)

Provisioning of an Application Instance using Push Management works accordingly. The interactions between DCA application and GTA API are not affected by using either Push or Pull Management.

5.5 Use of Application Instance personality to establish a secure channel

Establishing a secure channel can be supported by the following TrustAnchor capabilities:

5.5.1 Elliptic Curve Profiles

Annex B.1 shows an example for an OpenSecureChannel Request using ECC-nistP256 for further reference.

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)
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

Annex B.2 shows an example for an OpenSecureChannel Request using Aes256-Sha256-RsaPss for further reference.

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)
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.

5.6 CreateSession and ActivateSession

CreateSession and ActivateSession can be supported by the following TrustAnchor capabilities:

5.6.1 Elliptic Curve Profiles

The interactions between Client and GTA API in the sequence shown in Figure 22 for CreateSession and ActivateSession are similar to the process to establish a secure channel shown in Figure 17. The two trust anchor functions used are gta_verify_data_detached() to validate the integrity seal on the TrustList and gta_authenticate_data_detached() to compute the authentication proof of the client.
Figure 22 – CreateSession, ActivateSession (ECC, Client View)
Likewise, the interactions between Server and GTA API in the sequence shown in Figure 23 for CreateSession and ActivateSession are similar to the process to establish a secure channel shown in Figure 18. The two trust anchor functions used are gta_verify_data_detached() to validate the integrity seal on the TrustList and gta_authenticate_data_detached() to compute the authentication proof of the server.
Figure 23 – CreateSession, ActivateSession (ECC, Server View)

Note that for ECC SecurityPolicies the protection of the UserIdentityToken is achieved using symmetric encryption with keys derived from the ECCDH handshake. Thus, the protection of the UserIdentityToken is done in software and does not require functionality provided by the trust anchor.

5.6.2 RSA Profiles

The interactions between Client and GTA API in the sequence shown in Figure 24 for CreateSession and ActivateSession are similar to the process to establish a SecureChannel shown in Figure 20. The two trust anchor functions used are gta_verify_data_detached() to validate the integrity seal on the TrustList and gta_authenticate_data_detached() to compute the authentication proof of the client.
Figure 24 – CreateSession, ActivateSession (RSA, Client View)
Likewise, the interactions between Server and GTA API in the sequence shown in Figure 25 for CreateSession and ActivateSession are similar to the process to establish a secure channel shown in Figure 21. The three trust anchor functions used are gta_verify_data_detached() to validate the integrity seal on the TrustList, gta_authenticate_data_detached() to compute the authentication proof of the server, and (conditionally) gta_unseal_data() to decrypt the UserIdentityToken provided by the Client. The protection of the UserIdentityToken only applies for UserNameIdentityToken and IssuedIdentityToken.

In contrary to the ECC SecurityPolicy described in 5.6.1, with RSA SecurityPolicies, the client used the servers public RSA key to encrypt the UserIdentityToken. Therefore, the server needs to use its private key to decrypt the UserIdentityToken. The private key is protected by the trust anchor.

Figure 25 – CreateSession, ActivateSession (RSA, Server View)

5.7 Rollback of device to “pre-onboarding” state

GTA API offers functionality to restore the state of a device TrustAnchor to a previous state. This can be useful to reset a device trust anchor to the device state as shipped by the manufacturer or to any subsequent restore point created before putting additional personalities on the device’s trust anchor. Potential applications in the context of OPC UA are either to reset the device trust anchor to the state before onboarding or to the state directly after onboarding the DCA Application Instance.

The mechanism to use device states are described in ISO/IEC TS 30168. The respective functions are gta_devicestate_transition() to create a restore point and gta_devicestate_recede() to return to a previous restore point.