Registrars shall not accept Devices they do not trust. The steps to determine trust are:
- Read all DeviceIdentity Certificates from the Device;
- Locate a Ticket that has a ProductInstanceUri that matches one or more DeviceIdentity Certificates;
- Validate the Ticket if it has not already been validated (see 6.4);
- Select and Validate DeviceIdentity Certificate that matches the Ticket;
- Establish a secure connection to the Device using the selected DeviceIdentity Certificate.
- Issue a DCA Application Instance Certificate to the Device that indicates that it has been authenticated.
The initial communication between the Registrar and the Device is secured with a DeviceIdentity Certificate. When using PushManagement (7.3), the Registrar is a Client that calls GetEndpoints via connection without security on the Device Configuration Application (DCA). The DCA shall provide at least one EndpointDescription for each DeviceIdentity Certificate. The Registrar chooses a DeviceIdentity Certificate, establishes a secure connection using an EndpointDescription that uses that Certificate. This provides proof that the Device possesses the PrivateKey associated with the Certificate. The Registrar uses the SecureChannel to provide an Application Instance Certificate to the DCA which will allow the DCA to be used to provision the other Applications running on the Device. This Certificate is called the DCA Certificate.
When using PullManagement (7.2) the DCA connects to the Registrar without security and calls the ProvideIdentities Method. The Registrar chooses a valid DeviceIdentity Certificate and returns it in the response along with a ApplicationId which is used to request new Certificates. The DCA reconnects using a new SecureChannel with the selected Certificate which provides proof that the Device possesses the PrivateKey associated with the Certificate. The DCA uses the SecureChannel to request a new Application Instance Certificate which will allow the DCA to provision the other Applications running on the Device. The DCA Application Instance Certificate cannot be used for any action other than configuring the DCA or other Applications managed by that DCA (for example, the host name/IP address of the Application being configured has the same host name/IP addresses assigned to the Device where the DCA is running).
Registrar first looks for a Certificate that has a ProductInstanceUri as a value in the subjectAltName of the Certificate. The Registrar first searches the set of pre-validated Tickets that were provided out-of-band for a match. If that fails it either calls the RequestTickets Method on the DCA (see PushManagement in 7.3), or returns a code from ProvideIdentities Method that tells the DCA to call the ProvideTickets Method (see pull management in 7.2).
If the matching DeviceIdentityTicket is referenced by a Composite Ticket (see CompositeIdentityTicketType in 8.2.4) then the Registrar looks for a Certificate that has both the CompositeInstanceUri and the ProductInstanceUri as values in the subjectAltName.
A Device that is part of a Composite should provide the Composite Tickets in the RequestTickets or ProvideTickets Method.
Partial matches to DeviceIdentityTickets in CompositeIdentityTickets are rejected (i.e. Certificates with the ProductInstanceUri but no CompositeInstanceUri).
If more than one Certificate had a matching Ticket the Registrar may choose any one of them. The one selected is logged.
If the matching Ticket came from the Device, the Registrar validates the Ticket (see 6.4).
Once the Registrar has found a valid Ticket that matches a DeviceIdentity Certificate, it can use the CertificateAuthority in the Ticket to validate the selected Certificate using the process described in OPC 10000-4 for Application Instance Certificates. The revocation status check may be online if the Manufacturer or CompositeBuilder adds the cRLDistributionPoints or authorityInfoAccess extensions (see RFC 5280) to the DeviceIdentity Certificates. If those extensions do not exist then the revocation check may be skipped. Skipped revocation checks shall be logged. If the Ticket is signed by a trusted Ticket signing authority and the timestamp is valid then expired CA Certificates may be ignored since the lifetime of a Device is usually longer than the lifetime of a CA Certificate.
The Registrar, and the storage it needs, is a critical part of the authentication process and needs to be protected from access by malicious actors.
Clients may use pull management which is illustrated in Figure 4.
Figure 4 – Device Authentication using Pull Management
See 7 for a complete description of the Device authentication process.
The sequence begins when the Device discovers the location of the Registrar via mDNS (see OPC 10000-12), the SetRegistrarEndpoints Method is called (Servers only) or the Endpoints are provided via a Device specific mechanism. The sequence automatically repeats until the Device receives its DCA Certificate and no software update is required. Any errors occur the sequence restarts from the beginning. Note that step requires that the DCA trust any Registrar it finds since it does not have a valid TrustList (see 4.2.4).
If multiple Registrars are on the network, the DCA shall attempt to connect to each one until it finds one that accepts it and allows it to request a DCA Certificate and a TrustList. Once configured, the DCA shall not attempt to connect to Registrars that are not in the TrustList. Devices that support pull management shall have a way for a person with physical access to the Device to reset the DCA TrustList and restart the Device authentication process.
The OwnerOperator should have a strategy to detect and remove rogue Registrars since the DCA always trusts the first Registrar that provides an Application Instance Certificate.
Once connected to a Registrar the Device provides all of its DeviceIdentity Certificates to the Registrar which then attempts to locate a valid Ticket that matches one of the Certificates. If a Composite Ticket that matches the Device ProductInstanceUri exists then only DeviceIdentity Certificates with the CompositeInstanceUri are considered by the Registrar.
If no Ticket is found the Registrar asks the Device to provide any Tickets that it has by returning a Bad_TicketRequired error.
If a valid Ticket is found the Registrar returns a DeviceIdentity Certificate and ApplicationId which the Device is expected to used to request the DCA Certificate and the DCA TrustList.
The Registrar also uses the Ticket to determine if a software update is required before it provides a Certificate to a Device. If one is required it returns a Endpoint to the SoftwareUpdateManager that the Device is expected to use.
When the Device connects to SoftwareUpdateManager it provides the current version number of the software that is installed. If it is the required version, the SoftwareUpdateManager calls the UpdateSoftwareStatus Method. Otherwise, the Device downloads the update, applies it and then connects to SoftwareUpdateManager again and provides the new version number. The process repeats until the required software version is installed.
The complete process for requesting a Certificate and a TrustList are described in OPC 10000-12. Note that the DCA does not call RegisterApplication on the CertificateManager since the Registrar does that on behalf of the DCA when it finds a valid Ticket for the Device. Note that the Methods exposed by the Registrar rather than the CertificateManager. The expectation is the Registrar and the CertificateManager share a common backend so Certificates and Applications created via the Registrar will be known to the CertificateManager. In some cases, the Registrar and the CertificateManager will be the same Server.
The GetManagers call returns the Endpoints for the CertificateManager which the DCA is expected to use.
The DCA shall not connect to an untrusted Registrar once it has a TrustList.
The process for requesting Application Instance Certificates is shown in Figure 5.
Figure 5 – Requesting Certificates using Pull Management
The DCA registers all Applications it intends to manage with the Registrar which verifies that the DCA is authorized to manage the Applications and provides ApplicationIds needed to request Certificates from the CertificateManager. This authorization process is specific to the Registrar implementation and can include communication with an external authorization service or manual approval by a RegistrarAdmin.
Servers may use PushManagement which is illustrated in Figure 6.
Figure 6 – Device Authentication using Push Management
See 7 for a complete description of the authentication process.
Each of the DeviceIdentity Certificates is returned in EndpointDescriptions returned by GetEndpoints. The Registrar looks for a pre-validated Ticket that matches the Certificate in one of the Endpoints. If none found it chooses any one and establishes a SecureChannel and calls RequestTickets. The Registrar needs to validate the Tickets returned by the Device which requires access to the Certificate that created one of the Signatures and the ability to check its revocation status.
If the Registrar finds an EndpointDescription that matches a valid Ticket it will create a new SecureChannel using that EndpointDescription. It provides the DCA Certificate and TrustList to the Device. Once a Device has a DCA TrustList and all software updates have been applied, it will not accept connections from untrusted Registrars. In this state, the DCA shall only return EndpointDescriptions that use the DCA Certificate when GetEndpoints is called.
The Registrar may then pass control to the SoftwareUpdateManager which is responsible for checking if the Device software is up to date and uploading a new image if required. Once complete the SoftwareUpdateManager or an agent acting on its behalf calls UpdateSoftwareStatus Method on the Registrar.
Once the Device has updated software the CertificateManager will be able to push Application Instance Certificates and TrustLists for all Applications exposed via an ApplicationConfiguration Object (see 9.3.6) in the DCA AddressSpace. This process is shown in Figure 7.
Figure 7 – Updating Certificates using Push Management
If multiple Registrars are on the network, the DCA shall accept the first one to provide an Application Instance Certificate and a TrustList. Once configured, the DCA shall reject connections from Registrars that are not in the TrustList. The OwnerOperator should have a strategy to detect and remove rogue Registrars since the DCA always trusts the first Registrar that provides a Certificate.
Some Devices with limited resources may only support a single Server which acts as both the DCA and the operational Application. DCAs report this requirement to the Registrar by setting the IsSingleton Property to TRUE on the ProvisionableDevice Object (see 9.3.2). Registrar that shall provide a normal Application Instance Certificate to the DCA that cannot be used to configure other Applications.
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.
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.