The use of certificates in cryptographic applications and online communication protocols is nothing new and can practically be traced all the way back to the 1970's when the "framework" for public key encryption (more on this in a future blog) came into being. With the (now-not-so-recent) Industry 4.0 movement coming out of Europe, and the design and operation changes brought about by the IIoT phenomenon, we are seeing more and more systems – that have traditionally been air-gapped and kept offline – being brought online to take advantage of the digital revolution in which we find ourselves.
Despite how you feel about this (r)evolution there are several exciting changes that are being brought about, including the one I want to discuss is the increased adoption of OPC Unified Architecture (OPC UA) in automation systems.
In this first post in our ongoing Exploring OPC UA blog series, we will look at what OPC UA Certificates are and what they provide and subsequent posts will further explore how they are used in OPC UA, how they fit into the security ‘stack’ of OPC UA and will then look at how OPC UA Certificates are utilized and managed in several Software Toolbox applications. First thing’s first however; what are OPC UA Certificates and what are they used for?
If you have ever configured an OPC UA Connection between an OPC UA Client and OPC UA Server – you are probably familiar with OPC UA Certificates. OPC UA makes use of the X.509 certificate standard, which defines a standard public key format (for more information on Public/Private Keys and how they are used check out part 2 of this blog series) and is used in OPC UA for three primary functions:
-
OPC UA Message Signing Validates Communications Integrity
The application uses its private key to generate a message signature/hash, which can then be validated by using the corresponding public key certificate. If the private key signature checks out the message is guaranteed to come from the corresponding application. Modifying the message in transit (as might be the case in a man-in-the-middle-attack) would result in the message signature/hash no longer being correct – showing that the message was modified in-flight. -
OPC UA Message Encryption Keeps Communications Safe From Prying Eyes
In the same way that an application’s private key can be uses to sign a message to guarantee it was generated by the approved application, the public key can be used to encrypt messages. Once a public key is used to encrypt a message only the application with the corresponding private key can decrypt it (the really cool part is that an attacker could even have a copy of the public key and they would not be able to decrypt the message that was just encrypted; a public key is used for encryption only – it cannot be used to decrypt its own messages) -
OPC UA Application Identification Provides Measure of Trustworthiness
Naturally being able to sign messages and encrypt/decrypt them would not be much good to us if there was no way to determine whose certificate we were working with. Each OPC UA certificate therefore also provides identifying information on what application generated the certificate, when it was generated, by who it was generated, what the certificate can be used for, how long the certificate should be valid for, where it was generated, and many other things.
Central to those three functions comes the concept of trust. When two OPC UA-capable applications first connect, they exchange their Public Keys (these are included as part of the application/OPC UA certificates), while keeping their corresponding Private Key…well…private.
It is now up to the user to go into each application – the client and server – and trust the other side’s public certificate (if you are reading this and saying “well wait a minute what about systems that use Local Discovery Servers (LDS) and Global Discovery Servers (GDS)” you are – of course – correct, but that is a topic for another time). But be careful – trusting a certificate in your application may seem like a trivial step, but you are telling your application that the other application is trustworthy and allowed to connect/communicate. Make sure to validate that the certificate you are trusting has been vetted – after all, a locked door is no good when you give the bad guy the key.
Understanding what OPC UA Certificates are used for is one thing but understanding how they are used is a whole different topic. Subscribe to our blog to stay tuned for part two of this blog series that will look a little closer at the certificate exchange mechanism and how those certificates are used to keep your data secure.
