Log In
Home
10/04/2022
Offline
Hello,
We’re looking into the OPC UA 10000-21 part for device onboarding and are discussing how to understand some of the writings on the usage of DeviceIdentity certificates (IDevID or LDevID).
It seems quite clear that the expectation is that the DeviceIdentity certificate will be used as an application instance certificate for the DCA during the initial provisioning phase, i.e., before the registrar push new site-specific app.instance certificates to the DCA and the applications it can configure. From 7.3 Push Management:
“Each of the DeviceIdentity Certificates is returned in EndpointDescriptions returned by GetEndpoints.” .. “If the Registrar finds an EndpointDescription that matches a valid Ticket it will create a new SecureChannel using that EndpointDescription.”
It is also quite clear that the DeviceIdentity cert shall be hardware protected, e.g., using a TPM to store the private key of the DeviceIdentity certificate. From 5.1 Device Identity:
“… Devices should provide a SecureElement storage (for an example, see ISO/IEC 11889) to ensure the associated Private Keys cannot be copied off the Device.”
All fine and dandy, but:
- This will put some specific requirements on the clients expectations on the certificate on first use, as the DeviceIdentity cert will not be an app.instance certificate, e.g., no DNSname or IPAddress to validate. No big issue maybe – the Registrar is a specific application which could be coded to handle this.
- It will require the DCA to be able to create secure channels using a certificate w. private key stored in TPM (or similar secure element storage). This is a bigger issue, as we have so far not found any of the available stacks supporting app.instance certificates w. key stored in secure storage.
Are we understanding the specification right?
Anyone knows of support for part 21 in upcoming stack releases?
Best,
Björn
05/30/2017
Offline
1) The IDevID should be used for bootstrapping only. For operation devices need to issued certificates for the system by the GDS/CertificateManager.
2) Few stacks support this secure element capability at this time but some do allow users to replace the certificate operations with their own code that could use a TPM.
3) There is a JWG which is focused on defining a standard API to secure elements that can be used by OPC UA applications:https://opcfoundation.org/abou…..ps/view/80
03/28/2022
Offline
Hi,
I have a follow-up question as we are looking into the same thing currently in our product. We have been looking into GDS support and proper onboarding of devices and ran into the following issue:
We want to avoid using self-signed certificates and load a CA signed IDevId certificate in production to our devices, so that our customers can authenticate the devices to be genuine.
I am not aware of many GDS implementations, so far we have been only using UaGDS for testing (that was also used in interoperability workshop so is that the “Industry standard”?). However as pointed out earlier, this would require that the IDevId must be accepted by GDS, but as of now UaGDS will not allow a connection using a certificate without dNSname or IPaddress, which cannot be present in an IDevId at production time.
I contacted Unified Automation about this and this possibility will maybe be added at some point in future (so user can choose to ignore these missing SAN fields). Using self-signed certificates we can get the GDS to work with our device (with the missing fields).
Now we are in a pickle here as if we don’t use self-signed certificates, our device can’t be used by anyone using UaGDS (or any GDS?). So this is not really something that we can release.
The only way we could think a solution that works now (and in future) is to additionally load a CA certificate in our device during production and then use that to sign a new temporary certificate used by DCA with the missing fields. Then we can get a certificate that satisfies all the requirements for Application Instance Certificates defined in 10000-6 (and should work with all GDS implementations, no matter if they support Part21 or not).
Are there any other ideas on how this could be done, does this make any sense or have we misunderstood something?
Best regards,
Miikka
05/30/2017
Offline
A GDS should accept any Certificate which it has been told to Trust.
i.e. you should be able to install the issuer for your IDevIDs as a trusted CA using a GDS specific configuration interface.
If UnifiedAutomation GDS does not allow this they have a missing feature.
You can also generate a “default” hostname and set that as the dnsName for the IDevID.
The GDS has no way to know if the the dnSName is valid and any valid hostname works.
IEC 61406-2 recommends an algorithm for generating a default hostname:
An IL string can be used also to derive a unique default hostname.
he default hostname is created by:
1) Calculate the SHA256 hash of the IL string in hexadecimal
2) Truncate the hexadecimal string after a length of 29 characters
3) Prepend the prefix ‘IL-‘
Result is a 32 characters string as default hostname.
You can replace IL-String with “ProductInstanceUri”.
03/28/2022
Offline
Thanks for quick reply, we will try the default host name approach, but I got a bit confused about this:
“A GDS should accept any Certificate which it has been told to Trust.”
The CA certificate is added to the trust list of UaGDS, but it fails when validating the IDevId certificate. Isn’t this mandatory? In 10000-4 Table 106 – Certificate validation steps:
First the certificate structure and chain are validated (which should pass with the CA added to trust list), then:
| Host Name | Bad_CertificateHostNameInvalid AuditCertificateDataMismatchEventType | The HostName in the URL used to connect to the Server shall be the same as one of the HostNames specified in the Certificate.This check is skipped for CA Certificates.This check is skipped for Server side validation. This error may be suppressed. |
Doesn’t “may be suppressed” mean that it is up to the GDS implementor (if they don’t support Part 21) to choose if they allow ignoring issues with host name or not?
I can’t find anywhere in Part 12 that GDS should not follow these rules when connecting to the device.
Then in 10000-6 Appendix E.6 there are some certificate validation options, that allow for example to ignore mismatches between host name / ApplicationUri, but there are no options to suppress issues with hostname.
There is no issue if Part 21 is supported as that states in in 6.4:
The process of verifying a Certificate is described completely in OPC 10000-4, however, checks that are specific to Application Instance Certificates do not apply (e.g. the HostName and ApplicationUri checks).
If not already somewhere (and I can’t find it), would it make sense to explictly mention in Part 12 (or Part 4) how GDSs should validate IDevId certificates even if Part 21 is not supported?
05/30/2017
Offline
There is a disconnect in the spec between Part 4 and Part 21.
This needs to be resolved.
Part 21 makes it clear that an IDevID is allowed to create sessions.
But a commercial GDS is designed to conform to Part 4 could create issues.
We need to update compliance tests to make sure the Part 21 requirements are supported.
In the meantime, I recommend using the default hostname in the IDevID.
The algorithm I suggested should ensure uniqueness no matter where a device is installed.
1 Guest(s)
Usage Policy