Exploring OPC UA - Symmetric vs Asymmetric Encryption

In the first post of our ongoing Exploring OPC UA blog series, we covered the three functions that OPC UA Certificates (also known as Application Certificates) serve in the context of OPC UA security.

In this second post, we'll take a look at what happens to messages after you have trusted the application 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) encryption works – because, at the end of the day, they are not so different from one another.  At a very basic level (which will be all we have time for in a blog like this), symmetric and asymmetric encryption are not that complicated, so let’s take a look at how they do what they do.

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).

An Example of How Symmetric Encryption Works:

1. 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.
2. Server A uses the previously exchanged symmetric key to encrypt the message.
3. The encrypted message – safe from prying eyes – is now sent to the OPC UA Server running on Server B.
4. On Server B, the same key that was used to encrypt the message is now used to decrypt it.
5. The original unencrypted message is then delivered to the OPC UA Server.
6. Any unapproved parties who do not have the key would end up with an encrypted message they can do nothing with.

If the OPC UA Server running on Server B wanted to send an encrypted response it would simply need to use the same – previously exchanged – key to encrypt the message, and the process would repeat in reverse.

Because the same key is used for encryption and decryption, symmetric encryption is fast – and therein lies its primary benefit over asymmetric encryption; speed. But that speed comes at a price, and that price is security.

The example only briefly touched on arguably the most critical step of symmetric encryption, and that is the key exchange. How do you securely perform an exchange thats protect the key in a way where malicious parties cannot get access to it, and where the key can be easily exchanged with a new one if the old one were ever to be compromised?

Because the same key is used both for encryption and decryption, IF a malicious party were to ever gain access to the key they would be able to not only decrypt messages from both sides, but would be able to generate their own messages that could now potentially be treated as valid.

Another less than ideal aspect of symmetric encryption is that the number of certificates can also be prohibitive when dealing with more than just two machines. With a single client/server pair, there is only one key needed, but with 100 servers/clients – where each machine might want to talk to each of the other machines in the system – the number of needed certificates grows exponentially. Asymmetric encryption addresses many of these concerns…

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?

I wish I had time here to cover that concept in deeper detail but, for now, we will need to settle for the short version (since the long version involves a ton of math). With asymmetric encryption, each application will have two certificates that are mathematically linked (more on what this means in a second):

1. A private certificate that is used for decryption and message signing
2. 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 perform 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.

An Example of How Asymmetric Encryption Works:

1. 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.
2. The UA client will use the public key that was received from the OPC UA server to encrypt the messages.
3. The encrypted message is then sent off (where it is accessed by a malicious third party as it is in transit to Server B).
4. The OPC UA server on Server B uses its private key to decrypt the encoded message.
5. The original message is then processed normally.
6. The bad actor that intercepted the message as well as Server B’s public key is still unable to decrypt the captured message because they don't have the corresponding private key.

There is another cool feature that the aforementioned mathematical link between the private and public key brings us; not only can the public key be used to encrypt traffic that only the corresponding private key can decrypt. The server can also use the private key to sign a message and generate a message hash that – when compared against the public key – guarantees the message was not altered, and that the message originated from the machine we think it did.

Now earlier I said that the public and private keys are mathematically linked so I want to revisit that concept. What that means is that one key (or a part of one) was generated using the other key in some way, or that both keys were generated from the same large, random, prime number.

How that generation is accomplished depends on the algorithm used (RSA, Elliptic Curve, etc.) but the important piece is that there is a mathematical relationship between the two because of that operation. It is nearly impossible to derive the public key by just knowing the private key, and nearly impossible to derive the private key just knowing the public key. (Given enough time, and enough computing power, and enough mathematical brain power, nothing is unbreakable therefore “nearly impossible” applies.)

While significantly more secure than symmetric encryption, asymmetric encryption has one major drawback and that is speed. While these ‘mathematically linked’ keys are fantastic, having to do that math on every message can add a ton of computational overhead. And that brings us to our comparison - which one is better?

Comparing Symmetric and Asymmetric Encryption

Ultimately, to answer that question, you will need to consider the objectives for your particular project.  If the highest level of security is of the utmost importance regardless of any other factors, asymmetric encryption is obviously the right option.  If your project can accept a slightly less secure level of encryption in exchange for significantly faster performance and less overhead, symmetric encryption is likely the right option.

How Does Symmetric and Asymmetric Encryption Apply to OPC UA?

When you exchange the application/OPC UA certificates for your client and server you are exchanging the public key as part of those certificates. This means that when you are choosing to encrypt your OPC UA connection, OPC UA uses asymmetric encryption to secure the initial connection but, in order to work around the slower communication performance with asymmetric encryption, once the channel is secure a symmetric encryption key is exchanged for communications.

This voids the two primary concerns with both encryption standards:

1. Since communications are performed using symmetric encryption, we gain the speed benefit offered there.
2. Since the connection is heavily encrypted when the symmetric key is exchanged, there is no chance of the key being intercepted and used to break communications.

To keep the connection secure for the long term, the "SecureChannel" (more on this in the third part of this blog series) is regularly renewed so the same symmetric key is not used long term.  So when an OPC UA Endpoint references the terminology Sign versus Sign&Encrypt, it is quite literally referring to how the public and private keys will be used (i.e. should messages be signed using the private key and/or should messages be encrypted using the public key).

Not so confusing any longer, right? Subscribe to our blog to stay tuned for the third post of this blog series that will take a look at the OPC UA communication stack and what security features we gain at each layer.