There are different standards for Device Authentication which do not meet the complete set of requirements described in this specification. However, an OwnerOperator may have reasons to use one of these other mechanisms (i.e. they have the infrastructure and wish to reuse it).

In some cases, the OwnerOperator have a complete solution that manages the entire life cycle of the Certificates installed on the Device. In these cases, the onboarding mechanisms described in this specification are not used and it is responsibility of the alternate mechanism to issue and renew Application Instance Certificates to all Applications running on the Device and to maintain their Trust Lists.

In other cases, the alternate mechanism will only authenticate the Device and install a single Certificate. In these cases, the mechanism described in this specification takes over and manages the life cycle of Application Instance Certificates and the Trust Lists. This pull management version of this case is illustrated in Figure 8.

image011.gif

Figure 8 – Alternate Authentication Models with Pull Management

In this case, it is responsibility of the Authentication Service to verify the authenticity of the Device and supply a Certificate to the DCA that is trusted by the Registrar, SoftwareUpdateManager and CertificateManager. This Certificate shall also contain a ProductInstanceUri (see 5.2) which uniquely identifies the Device.

If a software update check is required the DCA needs the Endpoint for the SoftwareUpdateManager. If the Authentication Service cannot supply this Endpoint, the DCA can get it from the Registrar which may be discovered with mDNS and then calling the GetManagers Method. Once any software update is completed, the DCA calls RegisterManagedApplications on the Registrar to get permission to request Certificates and TrustLists on behalf of those Applications.

The location of the CertificateManager is returned by the GetManagers Method. The DCA can use the mechanisms defined in OPC 10000-12 to request the Certificates and TrustLists for all of the Applications which it is authorized to manage.

The Authentication Service may also provide a DCA Certificate to a Server which would then annouce its presence via mDNS. The Registrar would then follow the process described in 7.3 to discover the Applications managed by the DCA and providing their Certificates and TrustLists.

FIDO Device Onboard (FDO) is an onboarding protocol from the FIDO Alliance, an open industry association. The current version is FDO 1.1. FDO can be used as an alternate authentication model, as described in 7.4.1.

When a FDO Device is connected to a network it searches for one of the preconfigured DNS addresses for a FDO Rendezvous Server (TO1 in the FDO specification). When it finds one, it asks for the FDO Owner that has a digital document, called the FDO Ownership Voucher, that allows the onboarding process to start. The FDO Owner registers with a FDO Rendezvous Server when it recieves the FDO Ownership Voucher via mechanisms independent from the delivery of the FDO Device (TO0 in the FDO specification).

The FDO Device then creates a connection to the FDO Owner (TO2 in the FDO specification). The FDO Device identifies itself to the FDO Owner and creates a Signature with a PrivateKey preinstalled on the FDO Device. Then the FDO Owner verifies the Signature and determines if the FDO Device can be trusted by checking a TrustList provided to the FDO Owner. The FDO Owner presents the FDO Ownership Voucher for FDO Device with a Signature created by the FDO Owner. The FDO then allows communication to continue if it is able to verify the FDO Ownership Voucher.

The FDO Ownership Voucher is a digital document distributed by the manufacturer and is delivered via a mechanism independent from FDO as the FDO Device moves through the supply chain. The FDO Ownership Voucher has multiple Signatures provided by each intermediary in the supply chain. However, the FDO Device only knows the first PublicKey in the chain but this is sufficient to allow the FDO Device to verify the entire chain when it receives it from the FDO Owner.

Once FDO authentication is complete, the FDO Device creates an encrypted tunnel that is used to complete the onboarding process. The information exchanged during this stage can be application specific. FDO ServiceInfo Modules (FSIMs) are subprotocols that defined the messages exchanged during the onboarding process. The FSIMs to use are negotiated once the encrypted tunnel has been established.

Figure 9 illustrates the handoff from the FDO protocol to the mechanisms defined in this document.

image012.gif

Figure 9 – Device Authentication with the FDO Protocol

Specifically, the FDO Owner supplies the FDO device with a Certificate that can be used to create a SecureChannel with the Registrar. The Registrar is preconfigured with the CA Certificate used by the FDO Owner to issue the Certificates to authenticated FDO Devices. The FDO Owner uses a FSIM (fdo.csr) that creates a new LDevID that can be installed on the FDO Device as part of the onboarding process described in 7.4.2.1. This LDevID shall contain the information specified in Clause 5. The rest of onboarding process is the same as when the OPC UA device authentication mechanisms are used.

A FDO Device that supports integration with OPC UA shall have an OPC UA Client that can communicate with the Registrar. The OPC UA Client (a.k.a., a DCA using Pull Management as described in 7.2) may be installed by the Manufacturer or could be installed by the FDO Owner as part of the FDO onboarding process.