3 Terms, abbreviated terms and conventions3.1 OverviewIt is assumed that basic concepts of OPC UA security and ISO/IEC TS 30168 are understood in this document. For the purposes of this document, the terms and definitions given in OPC 10000-1 , OPC 10000-2 , OPC 10000-4 , OPC 10000-6 , OPC 10000-12 and OPC 10000-21 as well as the following apply.
Note that OPC UA terms and terms defined in this document are italicized in the document.
3.2 SecureElements for OPC UA based on ISO/IEC TS 30168 terms3.2.1 generic trust anchor application programming interface (GTA API)
set of well-defined methods, functions, routines, or commands for application software to facilitate the programming languages use of cryptographic or protected resources from an SE that is used as trust anchor
3.2.2 Personality
set of trusted information and cryptographic key material that is used by an application in a specific security context
Note 1 Note 1 to entry: A personality typically includes the device's own cryptographic material like private keys, secret keys, own public key certificates. A personality can also include information required to establish trust towards partners.
Note 2 to entry: A personality is used within the scope of a specific application. A device can use different personalities in different application contexts.
Note 3 to entry: A personality may make use of secret storage (confidentiality and integrity protected), trusted storage (integrity protected), and general storage (unprotected).
[SOURCE: ISO/IEC TS 30168 ]
3.2.3 Certificate
digitally signed data structure that contains a public key and the identity of a Client or Server . [SOURCE: OPC 10000-1 ]
3.2.4 SecureElement (SE)
component capable of securely hosting functionalities, or confidential and cryptographic data, or both in accordance with well-defined rules and security requirements
Note 1 Note 1 to entry: A typical solution for a SecureElement is a one chip microcontroller.
Note 2 to entry: Cryptographic keys are an example of confidential and cryptographic data.
Note 3 to entry: A SecureElement can be realized as pure software component to support future migration to a hardware SecureElement .
Note 4 to entry: A SecureElement can provide special physical protection features such as tamper protection.
3.2.5 TrustAnchor
NOTE An essential security capability that, by definition, must be trusted
Note 1 to entry: A TrustAnchor can provide provisions to protect the integrity and confidentiality of functions and related information that are required by an application.
Note 2 to entry: The security capability to achieve protection can be provided with an SecureElement. The SecureElement can provide functionality for, for example, secure generation and use of cryptographic key material, and tamper-protected storage of public key certificates.
Note 3 to entry: Data sets, for example, certificates starting a certification path, require additional protection against manipulation to be considered as trust anchor. This additional protection can be achieved by, for example, storage in a shielded location.
Note 4 to entry: A certificate protected against unauthorized tampering and which is accepted as termination of a certification path is an example for a TrustAnchor.
3.3 Abbreviated termsGTA API Generic Trust Anchor Application Programming Interface SAN Subject Alternative Name (X.509) SE Secure Element URI Uniform Resource Identifier