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.