Sponsored by: Software Toolbox
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 when the ‘framework’ for public key encryption came into being. With the relatively 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, specifically the increased adoption of OPC Unified Architecture (OPC UA) in automation systems. This paper explores what OPC UA Certificates are and what they provide, how they are used in OPC UA, and how they fit into the security ‘stack’ of OPC UA. Additionally, it examines OPC UA encryption methodology and the key concepts of a layered security model.
Primary Functions of OPC UA Certificates
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 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 certificate 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 (also known as their application certificates or just 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. 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 the next step.
Types of OPC UA Encryption
Now that we’ve had a look at the functions OPC UA Certificates serve in the context of OPC UA security, we need to consider what happens to messages after you have trusted the OPC UA certificates and have enabled security on the OPC UA endpoint. Specifically, what does Sign&Encrypt mean on an endpoint and how can we be sure that the data is truly secure.
To really understand how OPC UA Security between two applications works we need to know a little about how symmetric and asymmetric (or public key) encryptions work – because at the end of the day they are not so different from one another.
How Does Symmetric Encryption Work?
Symmetric encryption is so named (quite aptly) because the same key is used to both encrypt and decrypt the encoded message, not unlike a physical lock where the same key is used to lock and unlock the lock. This symmetry is great because it is a very fast way to encrypt/decrypt information because the same key is used for both, and because it is reasonably secure (although not as secure as its asymmetric brother).
- Server A (the OPC UA Client in this case) has an unencrypted message that it wants to send to the OPC UA Server on Server B.
- Server A uses the previously exchanged symmetric key to encrypt the message
- The encrypted message – safe from prying eyes – is now sent to the OPC UA Server running on Server B.
- Where the same key that was used to encrypt the message is now used to decrypt it
- And the original message is then delivered to the OPC UA Server
- Any unapproved parties who do not have the key would end up with an encrypted message they can do nothing with
How Does Asymmetric Encryption Work?
Asymmetric encryption – or public key encryption – (also quite aptly named) is considered asymmetric because the same key is no longer used for encryption and decryption. How is that possible you ask? How can one key be used to encrypt data, and another key be used to decrypt it?
Basically, with asymmetric encryption, each application will have two certificates that are mathematically linked (more on what this means in a second):
- A private certificate that is used for decryption and message signing
- A public certificate that is used for encryption
These keys are mathematically linked meaning that a message that is encrypted with a public key can ONLY be decrypted with the corresponding private key.
The first step with any connection that will use asymmetric encryption is that the public keys are exchanged.
Because an encrypted message can only be decrypted using the corresponding private key, applications can be very liberal in who they give their public keys to since anyone that intercepts an encrypted message cannot decrypt the message (even if they have a copy of the public key used to do the encryption). This also means an application only needs a single public key that can be used by many applications – solving the certificate count issue we see when using symmetric encryption.
- The OPC UA Client running on Server A starts with an unencrypted message that will be sent to the OPC UA Server running on Server B. The public keys have already been exchanged.
- The UA Client will use the public key that was received from the OPC UA Server to encrypt the messages and…
- The encrypted message is sent off (where it is intercepted by a malicious third party)
- The OPC UA Server on Server B uses its private key to decrypt the encoded message…
- Which is then processed.
- The bad actor that intercepted message as well as Server B’s public key is still unable to decrypt the captured message.
Read the full White Paper