OPC UA was designed with security in mind. One of the key ways OPC UA protects the integrity and confidentially of messages is through message encryption and signing. Although this sounds fancy, the technologies OPC UA uses to achieve this have a direct impact on how end users interact with OPC UA products. This blog describes that technology, and details how to use it to make secure OPC UA connections.
OPC UA uses an IT technology called X509 certificates for message signing and encryption. Message signing means when your application receives a message, you can know exactly who sent it by checking the message signature. This protects against rogue entities sending your client or server bogus requests. Message encryption provides confidentiality by guaranteeing that only the receiver is able to read a message. So how do X509 certificates provide OPC UA applications with message signing and encryption?
Every OPC UA product, client, or server gets an X509 certificate called an application instance certificate. This certificate consists of three things: a public key that is known to the world, a private key that is only known to the application, and identity information that enable applications to know who owns the certificate.
Public and private keys are really large prime numbers that are hard to guess. If a chunk of data is run through an encryption algorithm using the public key, only the private key can decrypt the message. The same holds true if the data is encrypted using the private key—only the public key would be able to decrypt it.
Asymmetric Encryption Methods
Asymmetric encryption methods are used to connect an OPC UA client to an OPC UA server. First, the client and server both exchange their public keys. It’s up to the client application to ‘trust’ the server’s public key, and the server application to ‘trust’ the client’s public key. Every product does this a little differently, but for many the way to create this two-way trust is to first attempt a secure connection and fail. Once failed, the client and server applications will place each other’s certificates in an ‘untrusted’ directory, and the user must move them to the ‘trusted’ directory. Once the trust relationship is established, the client and server connect.
After connecting, the client and server create a secure channel to encrypt and sign messages. The client encrypts a message with the server’s public key, guaranteeing that only the server can decrypt it. The client will also sign the message with its private key, allowing the server to check the signature. The server does the same when it sends messages to the client.
In reality, asymmetric encryption is pretty slow. To get around this once an OPC UA client and server establish a secure channel, they exchange a symmetric key. The symmetric key is the same for both the client and the server, and they continue on encrypting messages with the symmetric keys because it’s faster. Because symmetric keys are little less secure than asymmetric keys, however, the client and server will renew the keys at an agreed upon rate (such as, once an hour).
And that’s it! Pretty cool, huh? Since, setting up trust relationships between every client and server can be a bit of a burden at times, using a Certificate Authority (CA) is a good solution—but that’s the topic of a future blog. Stay tuned!