SecureElementsare a hardware-based storage for cryptographic secrets that protect them against authorized access and disclosure. The mechanisms defined for Deviceauthentication depend on PrivateKeysthat are stored in SecureElements. PrivateKeysstored on Deviceswithout SecureElementscan be stolen and reused on counterfeit Devices.

OwnerOperatorsmay provision Deviceswithout SecureElementsif they have other ways to ensure their authenticity.

Every Devicehas multiple layers of hardware and software that are installed and managed at different stages in the lifecycle by different actors. The layers are shown in Figure 2.

image005.gif

Figure 2– Device Hardware and Software Layers

A Devicehas firmware that is generally not changed during normal operation. Firmware updates may be provided by the Manufacturerto correct software bugs or patch security flaws. A Deviceshould have a mechanism to ensure the integrity of the system, including the firmware, during the boot process. A Deviceshould have a way to update firmware after onboarding in the OwnerOperator’ssystem.

A Deviceshould have SecureElementstorage used for security sensitive elements such as Private Keys. This storage cannot be backed up nor is it affect by a firmware update. The Private Keyof DeviceIdentity Certificates(IDevID and LDevID) shall be placed in this storage.

A Deviceshall have a Device Configuration Application(DCA) which is used for Deviceauthentication and setup of other Applicationson the Device.

A Devicemay have storage used for Applicationsand their configuration. A Deviceshould have a mechanism to back up and restore configurations. A Devicemay support multiple Applicationswhich have their own configuration and security configuration.

A Devicehas storage for the Applicationsecurity configuration that does not need to be in the protected storage. This storage is separate from the storage for Applicationsand configurations. Certificates, Trust Lists, administrator credentials are examples of information that is part of the security configuration. The Deviceshall have mechanisms to ensure that only authorized actors are able to alter the security configuration or access sensitive data such as the PrivateKeys. If a Devicesupports multiple Applications,the set of authorized actors may be different for each Application.

Implicit in the Devicelifecycle is the notion that Devicesand Compositeswill be physically delivered to different actors. The transfers of physical control that may occur are shown in Figure 3.

image006.gif

Figure 3– Possible Transfers of Physical Control

In many cases, the Distributorbelongs to the same organization as the Manufactureror CompositeBuilder. Similarly, the Integratorand the OwnerOperatormay be the same organization.

When a transfer of physical control occurs, the supplier ships the equipment (a Deviceor Composite) and an electronic Ticket(see 6) that describes the equipment. The receiver may use the Ticketto authenticate the origin of the equipment using the mechanisms defined in this standard or save it so it can be provided when the equipment is transferred to another actor.

While an actor has physical control, the actor may Install, Provision, Configureor Operate(see Table 2) the equipment. For example, if an actor (e.g., a CompositeBuilder) makes changes to a Deviceand then transfers this Deviceto another actor (e.g., an OwnerOperator) then those changes may restrict what the new owner is able to do, i.e., CompositeBuildermay install an Applicationused for maintenance that the OwnerOperatorcannot access.

The workflows (see 4.3) describe this process in more detail.

The onboarding process defined in this document describes how an OwnerOperatorcan authenticate Devicesadded to the network. This document does not define any mechanisms to allow Devicesto authenticate the network it is connected to. This implies that a Deviceconnected to a network will allow itself to be configured via any network that it is connected to. This behaviour is called “Trust on First Use” or TOFU.

When first connected to a network the DCAwill be in an initial state where it will either attempt to discover a network service that it can get its configuration (PullManagement, see 7.2) or wait for another application to provide its configuration (PushManagement, see 7.3).

Once the onboarding process completes the DCAis supplied with credentials that authorize Applicationsthat are allowed to make changes to its security configuration. Devicesshould have a mechanism to return the DCAto an initial state which discards all configuration, including all credentials and TrustListsthat were assigned in a previous onboarding process.

The new state allows the TOFU onboarding process to start again. Note the initial state is not the same as a factory reset which typically deletes all software installed on the Device. The reset mechanism should require proof of physical possession of the Deviceto ensure it cannot be exploited remotely.

The TOFU model exposes the Deviceto malicious actors that are running on the network. This means the network used for configuration has to be protected to make it harder for a malicious actor to gain access to the network. OwnerOperatorsshould also have network services designed to detect and eliminate malicious applications that attempt to interfere with the onboarding process.

Devicesmay have other ways to assign the credentials provided by the onboarding process in order to avoid the risks associated with TOFU.

The SoftwareUpdateManageris a system component that provides updates to firmware or software running on a Device. The SoftwareUpdateManagermay implement the standard model defined in OPC 10000-100, however, it often will be specific to the Manufacturer. This document defines APIs that allow any SoftwareUpdateManager to coordinate with the components defined in this document.

The SoftwareUpdateManager is an important part of the onboarding process because it is necessary to ensure that Deviceswith out-of-date firmware are not allowed on the network. The interactions between the SoftwareUpdateManager and the other components are described in clause7. The SoftwareUpdateManager may not be present in systems where the OwnerOperatorhas other mechanisms in place to ensure the Deviceshave up to date firmware.

Registrarsand DCA Serversneed to restrict access to many of the features they provide. These restrictions are described either by referring to well-known Roleswhich a Sessionmust have access to or by referring to named Privilegeswhich are assigned to Sessionsusing mechanisms other than the well-known Roles. Privilegesare needed because not all restrictions can be expressed simply by granting Rolepermissions on Nodes. For example, authenticated Devicesare granted the ability to update only their own information which means the decision on granting access can depend on the values of the arguments passed to a Methodcall rather than the permissions on the Method Node. The well-known Rolesused in this document are listed in Table 3.

Table 3– Well-known Roles for Onboarding

Name

Description

RegistrarAdmin

The Role grants rights to manage the Ticketsknown the Registrarand approve Deviceswhen automatic authentication was not possible.

SoftwareUpdateAdmin

The Role grants rights to set the software status for a Device.

SecurityAdmin

The Role grants the right to changes the security configuration of a Registraror a DCA Server. For the DCA Serverthis includes the right to set the location of the Registraror to force the Serverto restart the authentication process.

The Privileges used in this document are listed in Table 4.

Table 4– Privileges for Onboarding

Name

Description

DeviceSelfAdmin

The Devicehas rights to modify its own registration.

DCA

The Clientis a DCA that has rights to request Certificatesand TrustListsfor Applicationsthat it has been granted rights to.

For a detailed description of Roles,see OPC 10000-3.