General information: https://en.wikipedia.org/wiki/X.509 Security Considerations ----------------------- The certificate management system of the GDS handles cryptographic keys and needs to be protected from malicious actors. - The machine the GDS runs on should ideally be used for no other purpose. At least disable all services that are unneeded or known to be security problems. - User logins at this machine should be restricted to administrators. - The GDS itself provides a user login system to restrict access to the configuration. - Physical security and/or hard disk encryption should be considered, as an attacker who can physically access the hard disk is able to extract cryptographic keys. Certificate validity times and updates -------------------------------------- Application certificates usually have a short validity time (in most cases 1 year or less). Updates are easy, just generate a new certificate and change it. The GDS Push functionality can automate this. Intermediate CA certificates usually have validity times of several years. Updates are easy as well, because each application should have a list of intermediate certificates that lead to a well-known root certificate. Root CA certificates have considerably longer validity times, since the update is more complicated. Often they are valid for 20 to 30 years. Updates can be accomplished as follows: - Generate a new CA certificate. Regenerate all application certificates. Exchange them all at the same time. This is only possible during a maintenance period, because all systems in the UA network must be updated at the same time. - Generate a new CA (with new certificate). Push the new root CA certificate to all stations. Regenerate and push application certificates. Finally delete the old root CA. This can be done while the UA network is running, but needs to touch each system twice. - Use intermediate CAs and cross certificates. Generate new root and intermediate CAs (with new certificates). Cross-sign each intermediate CA from the other root CA. Regenerate and push application certificates. Finally delete the old root CA. This needs preparation on the GDS (= the intermediate CAs must be present), but allows to update while the UA network is running and needs to touch each system only once. General information about certificates ------------------------------------ Please read details in https://en.wikipedia.org/wiki/X.509. The currently used certificates are officially called X509 certificates. Many file formats of certificates are existing, but always the content is the same. In origin X509 is the complete specification for public key certificates. The main reason for certificates is the identification from the communication partner before all encryption. A certificate has an issuer, a unique key generated with long prime number multiplication So the gereration is simply and mostly fast, the decoding need to be impossibly. All certificates having n issuer date and an expiration date. A certificate can be revoked. Mostly this is necessary if anyone did copy the private key needed for the encryption of data. Therefor revocation lists do exist. Often certificates are kingdoms because of its key usage. Web servers only accepting web server certificats. OPC UA only accepting OPC UA certificates. Multiple key usages can be given but many software will not accept them. Additionally some companies or countries only accepting certificares with an specific issuer. And China do not accept US certificates and the US no from China. Because of the lifetime and the growing necessary encryption certificates and the handling software need to be actualized. In general one computer should have one own certificate forits identification. But because of explanations above often many certificatse existing. There is no standard of storing a certificate. Because of this an automatically certificate management is needed. Certificate and OPC UA GDS -------------------------- The OPC Foundation did specify in the GDS parts of the OPC UA specitications functionality for the management of certificates used by OPC UA. This is needing a full fledged OPC UA connection with valid and trusted certificates. Certificate dispatch push and pull ---------------------------------- Certificates can be dispatched with push. Then the certificate authority (CA) software needs accessing the systems which needing a certificate. The CA needs a list of known endpoints. Because the OPC UA server client architecture all endpoints using push need an OPC UA server. The certificate also can be requested from endpoints via Pull from the CA. If the endpoint is a OPC UA client as a SCADA software it may not contain an OPC UA server. In both cases the CA is needing all certificates for all endpoints. Certificate push is easier because the central CA or the sub CA in the gateways can dispatch the certificates. The timeout for certificate validaties is easier in a central or CA or in a sub CA. Overview are simply because all data are available. Encryption and security ----------------------- All encryption sheme is a compromise between computation time and the size of certificates. So around two years new encryption standards are coming. This will need actualized encryption software. And it needs stronger encryptions with newer math. Older encryption standards may be deprecated. Removing them may harm older systems, but preserving them may be a security hole. Real plant networks ------------------- Industry standard plant networks are not connected to the internet. Mostly this is because of security reasons. And plant networks running under real time conditions. Also a plant need running without access to external systems. Mostly in bigger plants parts of the production networks are separated completely. No routing will work. Gateways with two network adapters and without routing between the adapters is common. Dispatching certificates over such separate networks need a gateway with two separately working OPC UA conenctions. Both will need its own certificates. This also circumvents trusting issues if one station cannot accept certificates from others because of political reasons or vendor lockin issues. This GdScout can handle properly. GdScout structure ----------------- The central station is containing the certificate authority (CA). It creates and holds the certificates for all connected endpoints and all connected sub CA. Sum CA will allow gateways with separated networks. And if organizes the certificate dispatch to the unterlaying network if the master CA is not available always. This isolates the networks. Each sub CA acts as the CA for connected endpoints and deeper sub CA again. The CA checks for the lifetime of the certificates. Before it end actualized certificates are pushed. Each CA manages the certificate revocation list and dispatches this to all underlaying stations. Because revocation lists can grow if the lifetime of certificates is longer a good solution is holding this below one year. Current OPC UA specifications will limit the lifetime of a certificate to six month. GdScout advantages ------------------ The OPC UA GDS spectifcation only is defined for OPC UA. Other systems also need certificates, an example is the Siemens S7 1500 for the PLC internal protocol. More examples are MQTT SSL certificates, web servers, web sockets and other. All those certificates can be handled. More and more OPC UA requires separately certificates for each connection. This works also.