Generic Trust Anchor (GTA) API Profile

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:

Transition from a DeviceIdentity personality to DCA personality (5.2)
Provisioning of ApplicationInstance personality
Use of ApplicationInstance personality for application authentication (5.5)
Management of ApplicationInstance Certificates and TrustLists
Factory reset / decommissioning

The analysis for the provisioning of personalities is based on the scenarios described in OPC 10000-21 The processes described in OPC 10000-21 provide the most comprehensive coverage of SecureElement usage. Scenarios for using SecureElements in combination with e.g., , can be easily derived from the information given in this document.

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:

At least one DeviceIdentity Personality (4.3.3) is present and managed by GTA API that can be used for the onboarding process (5.2.2).
This is the initial enrolment for the DCA, i.e., the DCA client does not yet have a TrustList
The registrar has access to a Ticket that identifies the device (https://reference.opcfoundation.org/Onboarding/v105/docs/3.1.19)
Key generation takes place on device, i.e. the private key is not provided by the Registrar.

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; https://reference.opcfoundation.org/Core/Part6/v105/docs/6.2). 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).

Establish OPC UA Secure Channel DCA – Registrar/GDS. Details on how to establish a secure channel using an existing personality are described in 5.5.
Create personality for Application Instance
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

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.

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.

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.

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)

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

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

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

5.6 CreateSession and ActivateSession

CreateSession and ActivateSession are used to establish Sessions based on the UserIdentity.

CreateSession and ActivateSession 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. CreateSession and ActivateSession use these keys to authenticate the identity of the client resp. server identity.
Protecting the UserIdentityToken (RSA only)

Note that authentication of the actual user using X.509 credentials is not in scope of this document. X.509 user credentials are supposed to be user specific and will typically not be persisted on the device.

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.