4.2.3 GTA API and OPC UA object model mapping

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

image007.png

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.