A CertificateGroup is a context that contains a TrustList and one or more CertificateTypes that can be assigned to an Application (See OPC 10000-12).

This ObjectType allows an Application which has multiple TrustLists and/or ApplicationInstance Certificates to express them in its AddressSpace.

Figure 1 depicts the OPC UA security object model.

Figure 1 – OPC UA Security Object Model

ISO/IEC TS 30168 provides an API that addresses the integration of TrustAnchor functionality into an industrial IoT application. Typical requirements are:

• Confidentiality and integrity protection of cryptographic credentials, e.g., private keys, pre-shared secret keys, passcodes
• Integrity protection of trusted information, e.g., certificates trusted in the process of certification path validation
• Protection of device configuration

A SecureElement is a component which is capable to securely store confidential or cryptographic data and host functionality to operate with that data. Thus, TrustAnchor capabilities can be realized using such a component. SecureElements are available with different characteristics and formfactors. Starting from software implementations bootstrapped from a single (hardware-) protected secret and offering some basic protection during execution (e.g., dedicated privilege level) to dedicated security micro controllers. Examples for trust anchor technologies are TCG DICE, TCG TPM, ISO 7816 series.

GTA API aims at providing a single generic abstraction allowing an application to access TrustAnchor functionality regardless of the technology used for the SecureElement.

Figure 2 gives an overview of the GTA API information model. The starting point for objects organized by the GTA API information model are identifiers (cf. ISO/IEC TS 30168 clause 5.5.3). An identifier is used to identify a device or application in a specific security context. For example, with OPC UA an ApplicationUri is a suitable identifier.

Figure 2 – GTA API personality object model

Personalities are means that allow to present the device or application identity associated to an identifier in the digital world. A personality comprises all security objects which are needed to act in a given security context. The different security objects are represented as attributes of the personality:

• Secret Attributes: These are objects which are typically used to proof the identity and authenticity of an entity or to access data which shall only be exposed to a designated entity. The SecureElement provides capabilities to protect the integrity, authenticity, and confidentiality of these objects. Examples are, private keys for asymmetric crypto, secret keys, and passcodes. In case of OPC UA this corresponds to an RSA or ECC private key (depending on the SecurityPolicy).
• Trusted Attributes: These are objects which are typically used to proof the identity and authenticity of another entity. The SecureElement provides capabilities to protect the integrity and authenticity of these objects. Examples are, trusted public keys, trusted certificates, passcode verifiers.
• Attributes: These are additional objects which can be managed by GTA API to provide a single point of information for objects belonging to the security context. These attributes can also be used to enable organization and discovery of personalities. However, these attributes do not depend on the security capabilities of the SecureElement. Examples are end entity and intermediate certificates, application specific information like labels or URIs.

Figure 3 shows how the OPC UA object model is mapped to the GTA API object model.

Each OPC UA Application is represented by a distinct Identifier in the GTA API object model. To express this relation the Identifier value is set to either the ProductInstanceUri or ApplicationUri (cf. 4.3.2.1).

The GTA API object model does not provide an equivalent for CertificateGroup. With GTA API a set of personalities are used to represent each CertificateGroup. The affiliation of these Personalities to a CertificateGroup is indicated by following respective naming conventions (cf. 4.3.2.2).

Figure 3 – GTA API and OPC UA object model mapping

Each Certificate Group consists of multiple Personalities:

• Personality Identity: This personality represents the Device or Application as identified by its Device Identity Certificate or Application Instance Certificate. The Personality encloses the private key used for crypto operations (gta_authenticate_data_detached(), gta_unseal_data()). The Device Identity Certificate or Application Instance Certificate may be stored as an attribute.One or more Identity Personalities can exist in parallel, e.g., for different cryptographic profiles.
• Personality TrustList: This Personality is used to protect the OPC UA TrustList objects. The actual objects are not stored by GTA API. Instead the TrustList personality makes use of the basic GTA API profile for local data protection ch.iec.30168.basic.local_data_integrity_only as defined in ISO/IEC TS 30168 Annex B.2. The management of the OPC UA TrustList objects (trustedCertificates, trustedCrls, issuerCertificates, issuerCrls) is left to the OPC UA application.

The integrity protection for the TrustList object using the profile ch.iec.30168.basic.local_data_integrity_only can be done in two ways:

• Using gta_authenticate_data_detached(), gta_verify_data_detached(): gta_authenticate_data_detached() produces a seal on the object to be protected. The seal is then stored along-side the original object. The seal can be verified using gta_verify_data_detached() to proof that the object has not been tampered with.
• Using gta_seal_data (), gta_unseal_data: gta_seal_data() creates an envelope containing the object to be protected. The object can be retrieved from the envelop using gta_unseal_data(). The envelope ensures that the contained object has not been tampered with.

Whether the first or second approach is more suitable depends on whether it is preferred to have an additional tag/seal for protection that needs to be handled by the application while the original object stays untouched, or to replace the original object with the protected object.

Each OPC UA application on a device corresponds to a GTA API identifier and at least one personality set. An OPC UA application may use multiple identity personalities corresponding to multiple SecurityPolicies.

Subsection 4.3.2 introduces conventions to be used for GTA API identifiers and personality names being used by OPC UA applications.

The personality’s application property and personality attributes can be used to provide additional distinguishing features depending on the actual personality type. Subsections 4.3.3, 4.3.4, and 4.3.5 provide an in-depth description for three types of personality sets which are commonly used in OPC UA:

• DeviceIdentity Personality set: The personalities representing the DeviceIdentity and corresponding to DeviceIdentity certificates available for the onboarding process. DeviceIdentity Personalities are provided by the device vendor and can be used by OPC UA but are not managed by OPC UA.
• DCA Personality set: The personalities representing the DCA and corresponding to the DCA certificate(s) and the corresponding Trust List.
• Application Instance Personality set(s): Any other personality representing an OPC UA Application Instance corresponding to an Application Instance certificate(s) and the corresponding Trust List.

As described in 4.2.2 the main organization criteria for objects used with GTA API are identifiers and personality names. To allow easy retrieval of the required personality by an OPC UA application the following naming conventions shall be observed.

GTA API identifiers created for exclusive use by OPC UA shall be of type org.opcfoundation.product_instance_uri or org.opcfoundation.application_instance_uri and their respective value shall be set to the ProductInstanceUri or ApplicationUri respectively.

Adhering to this convention allows convenient enumeration of all personalities belonging to a specific ProductInstanceUri or ApplicationUri using gta_personality_enumerate() or direct selection of a personality using its personality name.

GTA API personality names shall be set to an URI query string<InstanceUri>?cg=<CertificateGroup>[&ct=<CertificateType>&ix=<GenerationIndex>]

where

• <InstanceUri > is either the ProductInstanceUri or the ApplicationUri
• <CertificateGroup> is the Name portion of the BrowseName for the OPC UA CertificateGroup (e.g., “DefaultApplicationGroup”), and
• <CertificateType> is the Name portion of the BrowseName for the OPC UA CertificateType (See OPC 10000-12) where any trailing “ApplicationCertificateType” is removed, “EccNistP256ApplicationCertificateType” “EccNistP256”
• <GenerationIndex> is a monotonically increasing number that can be used to distinguish between different versions of the personality. Multiple versions can exist during an update process which takes time to complete.

CertificateType and GenerationIndex are not present for the personality representing the TrustList for the CertificateGroup.

DeviceIdentity personalities are established by the device vendor, device integrator, or device distributor. Depending on the underlying device life-cycle and trust model, a DeviceIdentity may be represented by either an IDevID or LDevID. Especially IDevIDs are not intended for exclusive use by OPC UA. Figure 4 shows the object model for a DeviceIdentity Personality.

Figure 4 – DeviceIdentity Personality

The decision on the GTA API identifier type and value is left to the device vendor.

The personality name and application are also selected by the vendor.

To support the decision on whether a specific personality is eligible for OPC UA device onboarding, DeviceIdentity personalities should have an attribute of type org.opcfoundation.product_instance_uri. If present, the value of that attribute shall be set to the ProductInstanceUri.

EXAMPLE

"urn:some-company.com:2025-01:model-xyz:snr-16273849"

If this attribute is not present, the personality to be used as DeviceIdentity needs to be communicated to the DCA by other means (out-of-band).

The DeviceIdentity Certificate itself can be made available using a personality attribute of type ch.iec.30168.trustlist.certificate.self.x509. As the security of the DeviceIdentity Certificate does not depend on additional protection offered by a secure element it may also be stored elsewhere.

DCA related Personalities are the first GTA API objects created for OPC UA. There would be one DCA TrustList Personality and one or more DCA Identity Personalities (corresponding to one or more DCA certificates). Figure 5 shows the object model for a DCA Personality Set.

Figure 5 – DCA Personality Set

By convention the identifier used to create DCA related Personalities shall be of type org.opcfoundation.application_instance_uri. The ProductInstanceUri is a natural choice for the identifier value used for the DCA Personality set. However, selection of the identifier value is left to the operator.

The application of a DCA Identity Personality shall be set to “DCA Identity” and the application of a DCA TrustList Personality shall be set to “DCA TrustList”. This allows easy selection of the DCA related Personalities using gta_personality_enumerate_application() (cf. ISO/IEC TS 30168, clause 6.6.10.4.12) during later use.

The name of the DCA Identity Personality is set according to the description in 4.3.2.2.

EXAMPLE

urn:manufacturer.com:2024-10:myproduct:SN51235?cg=DefaultApplicationGroup&ct=Rsa2048&ix=1

urn:manufacturer.com:2024-10:myproduct:SN51235?cg=DefaultApplicationGroup&ct=EccNistP256&ix=10

The DCA Certificate itself can be made available using a personality attribute of type ch.iec.30168.trustlist.certificate.self.x509. As the security of the DCA Certificate does not depend on additional protection offered by a secure element it may also be stored elsewhere.

The name of the TrustList personality is set according to the description in 4.3.2.2.

EXAMPLE

urn:manufacturer.com:2024-10:myproduct:SN51235?cg=DefaultApplicationGroup

Figure 6 shows the object model for an Application Instance Personality Set.

Figure 6 – Application Instance Personality set

GTA API identifiers used as a base to create personalities representing Application Instance Certificates for OPC UA applications should be of type org.opcfoundation.application_instance_uri and the value should be set to the ApplicationUri.

EXAMPLE

urn:manufacturer.com:2024-10:myproduct:myappid?cg=DefaultApplicationGroup

The name of an Application Instance Identity personality is set according to the description in 4.3.2.2. The names used for GTA API personalities representing Application Instance Certificates should be a qualified name with the namespace URI equal to the ApplicationUri. The qualified name used for the personality name can contain additional information to distinguish between multiple personalities sharing a single identifier.

EXAMPLE

urn:manufacturer.com:2024-10:myproduct:myappid?cg=DefaultApplicationGroup&ct=Rsa2048&ix=12

urn:manufacturer.com:2024-10:myproduct:myappid?cg=DefaultApplicationGroup&ct=EccNistP256&ix=14

The ApplicationInstance Certificate itself can be made available using a personality attribute of type ch.iec.30168.trustlist.certificate.self.x509. As the security of the Application Identity Certificate does not depend on additional protection offered by a secure element it may also be stored elsewhere.

The name of the TrustList personality is set according to the description in 4.3.2.2.

EXAMPLE

urn:manufacturer.com:2024-10:myproduct:myappid?cg=DefaultApplicationGroup