As the IIoT continues its widespread adoption, a lot of new IT technologies are quickly being adopted by the industrial automation and process control industries. More and more, industrial assets are becoming Internet enabled and being connected to other digital systems.

Monitoring OEE and KPIs in real time from a mobile device is no longer a pie-in-the-sky application. It’s happening right now, through the convergence of OT and IT.

One of the technologies that’s enabling the IIoT is secure digital communication. And to establish that secure communication, you need to have an authority you can trust that can validate the indentity of devices on a network and on the Internet. You have to trust that the encrypted connection you're using is actually connected to the device you want to talk to, and not to some rogue node trying to breach your network and steal your information.

That’s where Certificate Authorities come into play in the IIoT.

To understand what a certificate authority is, you first have to understand how a public key infrastructure (PKI) system works. PKI encryption is what allows nodes on a public network to privately communicate.

It should be noted that public key infrastructure (PKI) encryption is pretty much an Internet SOP or standard operating procedure. That is, it’s the same technology you use all across the Internet. 

Like when you do mobile banking at home or log onto pretty much any secure website, indicated by the https:// in your address bar. The s after http indicates that your web browser is connected to the web server over an encrypted connection. The current standard encryption for web communications is SSL/TLS.

But let’s get back to public key encryption and certificate authorities.

You might be familiar with traditional symmetric key encryption. This is encryption in, dare I say it, its least complicated form. Two nodes on the network, for example a programmable automation controller and an HMI software program, are configured with the same encryption key.

That way, when they communicate, they both use the same key to encrypt and decrypt data sent between them.

The problem with this type of encryption infrastructure is that it’s pretty difficult to scale up—especially when we’re talking about the billions of industrial assets we want to start connecting together to build the Industrial Internet of Things.

Imagine having to manually configure the thousands of devices at your plant or factory with the same encryption key. I’d hate to be the person with that job, stuck in a windowless room somewhere typing in the same encryption key, over and over, for days...even months. Not to mention the massive security vulnerability of all of your devices using the same encryption key.

That’s where a public key infrastructure, PKI, comes to the rescue.

Digital certificates, often referred to as X.509 certificates, are the foundation of a PKI encryption system.

Digital certificates perform essentially two functions in secure data communication:

• Identity Verification. The certificate contains the device's name, the name of the organization that controls the device, and digital signatures of organizations that vouch for the authenticity of the certificate, also known as certificate authorities.
• Data Encryption. Identity verification is done over an SSL/TLS encrypted connection from a client to a server. The client and server establish an SSL/TLS encrypted connection using a process called an SSL Handshake. The SSL Handshake is invisible to the user and happens instantaneously. During the handshake, the client requests identity verification from the server. The server responds with its digital certificate, which contains the server's public key. The client can then use the public key from the server to confirm with certificate authorities listed in the certificate that the server is indeed who it claims to be.

You can think of a device’s digital certificate as kind of like a virtual identification card. Certificates, or virtual ID cards, are issued to computers, mobile devices, pretty much anything connected to the network that you want to verify the identity of.

In a public key infrastructure system, each digital certificate contains a public key that binds the system’s identity to the certificate. When an encrypted connection is set up between two nodes, they both exchange their public keys to verify their identity and open an encrypted connection for data transmission.

But where do these certificates come from and how do we know they’re actually legit? 

In a PKI system there are self-signed and CA-signed certificates. Self-signed certificates are generated by the node that owns the certificate and are not signed by a certificate authority. That’s why when you browse some websites, you get a warning message about the site not being secure.

It’s not that the connection between your PC and the site isn’t encrypted. It’s that the site is likely using a self-signed certificate instead of a CA-signed certificate. 

Popular certificate authorities include Verisign (now owned by Symantec), GoDaddy, and Comodo. There are others out there, but those are the big three, so to speak. These folks handle verifying digital identities on the Internet. Certificate authorities digitally sign certificates, basically vouching for the certificate owner’s identity.

You don’t necessarily need to use a CA-signed certificate for all of your devices like HMIs and automation controllers, but it is a good idea to use encryption on your network with self-signed digital certificates for SSL/TLS communication.

Even though the certificate your device uses may not be signed by a certificate authority, implementing a PKI encryption system on your network still allows for encrypting data between devices on the network. It's just that the identity portion of a self-signed certificate has not been verified by a trusted certificate authority like Verisign.

With the RESTful API to SNAP PAC controllers from Opto 22, you can securely access control system data over an encrypted connection using either a self-signed or CA-signed digital certificate. You can learn about the security features automation devices need in this blog post. And you'll find more information on generating self-signed digital certificates for the SNAP PAC system on the Opto 22 developer site.

Industrial systems are increasingly the target of cyber attacks. For more, take a look at this series of blogs on security for industrial automation.