In this post, we’re going to be talking about what is happening here in building automation world called certificates. Now you're seeing this at the server and supervisory layers. So, you're seeing supervisory devices and field controllers requiring certificates. You're seeing things like BACnet Secure Connect coming out with certificating requirements. If you've logged into almost any building automation system that's been released over the past year, you've probably seen an option for secure connections, usually something to the form of HTTPS with TLS 1.2 or 1.3.
Now, what does all this mean and what do you, as a building automation professional, need to know about certificating and certificating authorities? So, certificating, at the end of the day, is typically known as a secure socket layer certificate, although we are using the TLS protocol, which is the transport layer security protocol, and that is due to SSL, secure socket layer, being compromised. So, SSL is compromised and we're actually using TLS.
Now, if you've ever gone to a website, you've seen the little lock box next to the URL of the website. So, if you go to your building automation web link, via a web browser, and it is indeed encrypted via SSL certificate, then you will see the lock box next to the domain name. Typically, a lockbox, it'll either be green or it'll just be gray, it just depends on how the site's implementing it. It'll have like information, a little circle with an “I” in the middle of it saying not secure, or maybe a triangle with an exclamation point; a red triangle saying not secure.
The funny thing that a lot of folks don't realize is that you can implement what's called a self-signed certificate, and that self-signed certificate, that would flag a site as not secure potentially, even though things are encrypted. That simply has to do with the fact that the self-signed certificate cannot be authenticated as a legitimate certificate, thus, the “domain powers that be” have no way of really validating that that encrypted connection is actually secure and that you are who you say you are. At the end of the day, certificates validate who you are and who's connecting, to meet one of their OSI security layers. They will prove that one of those services, which is nonrepudiation, or proving that the people are who they say they are and that they actually sent the messages, is done through certificating.
At the end of the day, we have this thing called a certificate, and I'm going to talk about certificating for encryption, certificating for digital signing and validation, and then we're going to talk about employing certificates actually on our building automation systems.
Okay, so first off, as I mentioned, when we connect to the building automation domain, which is the domain address of the controller, or of the supervisory device that we're connecting to via our web browser, we have two options:
- We can connect HTTP, Hypertext Transport Protocol, which is clear text. So, everything that is transferred between our web browser and the BAS device is going to be clear text.
- We can connect HTTPs, Hypertext Transfer Protocol Secure, or with a secure socket layer, depending on how you define that acronym. That essentially means that the data that is being sent from your web browser to the BAS device, and vice versa, is encrypted.
What does this encryption do? Well, it gives us confidentiality, which to be quite honest, besides for your username and password and stuff like that, confidentiality is not that big of a deal in the building automation world. At the end of the day, if someone knows your temperature setpoint, it's not the end of the world.
I have worked for customers, whose temperature set points, their pressure set points, etc, especially in the FDA or in the medicinal/pharmaceutical fields, they do care about those values being leaked, and they want them confidential because then their competitors can know they're using this temperature in manufacturing of this product. So, there are times when confidentiality matters.
Most of the time, though, confidentiality is simply to protect your username and password. Basically, what happens is, you initiate a connection between your web browser and the BAS device and that initiates most of the time as an HTTP connection, unless you're directly going straight to Port 443, which is the default HTTPS port. So, like if you've seen Port 80, that's HTTP, clear text. If you see 443, though, these are logical ports, that's HTTPS. So, you're connecting to HTTPS, and everything, by default is encrypted.
Now, you may be wondering, how does everything get encrypted? Well, it's through this thing called Public Key Infrastructure, or PKI. So, you've probably heard of the term public key and private key. Public key is going to be like someone's public key. So, for example, your computer's public key, and you're going to sign data, and then that data is going to get signed, and your private key is going to be used to decrypt the data by the BAS device.
Now, there is some sharing of public and private keys, we're not going to get too deep into that here, but just realize that the whole purpose here is to give you the ability to encrypt data and then decrypt data. The public key encrypts, the private key decrypts.
Not only can you do that, but you can also sign and verify data. So, you can have what is called digitally signed data and this is where certificating comes in. You have data, it's hashed, and then it's signed by a private key. So, the hash data, there's a hashing algorithm, like MD5 or RSA. I can't remember the algorithm off top my head, but the algorithm hashes, which means it converts the data, and then it hashes it against a data hash to basically create ones and zeros. Then that hash is signed using a key which then makes the data encrypted. That signature is combined with a certificate, and that then gets attached to the data, that is digitally signed data, and you receive the digitally signed data, and you use the signature against it. Basically, you use the public key of the signer, and that's going to get a hash. Then the data itself is hashed as well, and if the hashes are equal, then the signature is valid, so you can ensure that the data is actually coming from the right person.
This is why we have certificating authorities. So, a certificating authority is going to sign the certificate with a private key, guaranteeing that that certificating and registering authority actually did verify that that person is who they say they are. This becomes important when you are trying to connect to a domain and you want to validate that a domain is who it says it is, you want to validate a remote computer, you want to validate software coming from one. If you've ever gone into Niagara and you've done a driver, you've seen signed drivers versus unsigned drivers. So, there's all sorts of uses for certificating.
At the end of the day, these certificates as I mentioned, they validate who is who. When we go into our BAS, and we want to validate that either a remote user is who they say they are, or a remote device is who they say they are, or vice versa, we will use a certificate.
Now we can do this thing called self-signing. Self-signing is where we generate our own private key. If you wanted to do this right now, you could go into IIS on Windows, go to the certificate section, and you could self-sign a certificate. In some BAS, as you can self-sign your certificate as well. While the self-signing just means that you take your private key, which hasn't been validated, no one's ensured that you are who you are, no one's verified that, and you sign your certificate, and you create your self-signed certificate.
There's no validation that whoever signed it actually is who they say they are, but it is self-signed, and it enables you to encrypt. So, if all you want to do is encrypt data, you can create a self-signed certificate, you can implement HTTPS, TLS, and that will encrypt your data with your self-signed certificate. There's no validation of whoever being whom they say they are. So, if you're using your BAS software to connect to the device, the device has no way of proving that you are who you say you are, because anyone could have had that key and self-signed a certificate, and then pretended to be someone else.
Now, why does that matter? If someone understands these keys, that they have access to these keys, they can decrypt information. Even though decrypting BAS information is not necessarily the most dangerous thing in the world, they could get your username and password and that would not be good, but where it really becomes a problem is if you're doing a lot of IOT stuff, or edge stuff, and you have IP enabled controls, and you want to basically authenticate them, you could have an issue with the authentication, because of self-signed certificates. You would not know that this device is legitimate, potentially. Whereas if you distribute an authorized, and approved, and validated certificate, you can have a greater belief that whoever it is connecting is actually who they say they are.
Okay, so you have certificating, you have encryption, and the two are not necessarily the same. Certificating is a way of validating connections are secure, validating that who they say they are, is who they are. That becomes important because it defends against a potential man-in-the-middle attack where people could potentially impersonate a computer, or something like that.
Additionally, it makes sure that you're connecting to legitimate sites, not so much of a big deal with BAS. There's not a lot of illegitimate BAS sites floating around that you may accidentally connect to and enter your password data. But for example, one of the reasons you want to know a domain is legitimate is because if you connect to that domain, like you connect to Google.com, and you think you're connecting to Google.com, but it's an illegitimate site, it's a hijacked domain, you could enter your username and password and now people have stolen your credentials.
Well, it's kind of the same with BAS. That being said, while that is definitely a risk with domains sitting out on the IT world, building automation, there's not like a ton of devices sitting out there trying to impersonate building automation devices, stealing usernames and passwords. It's for most people, not that big of a deal. The nice thing about encryption, though, is like I said, it protects data.
Now I'm going to say something that's a little controversial to some, but it is that on most internal networks, you don't necessarily need to be encrypted. I will tell you though, that encryption is pretty low on the overhead side of things. It used to be a big deal, because we had slow networks, and things were slow, and computers were slow, and controllers were slow. That's not so much of a big deal anymore. We don't really have slow computers. Some of our field controllers are faster than our servers were a couple years back. So, we just we have the computing capacity to manage these algorithms.
So, it's not a whole lot of trouble to self-sign a certificate and implement HTTPS, TLS on your building automation system on an internal network. Where I would actually use a certifying authority and a registering authority, so RA is registering authority and CA is certifying authority. Where I would utilize these would be if I had a public facing building automation device. I definitely would want to use an actual validated certificate to ensure that whoever was connecting to my device is legitimate.There are other technologies you can use as well, like OAuth and LDAP, that are on the authentication side of things, but as far as certificating goes, at the end of the day, it's pretty simple.
So, let's talk through how we implement that on a building automation system. First thing we're going to have to do is we're going to have to go to that building automation system and determine what form of certificating it implements, and what key size it supports, and how we will issue a certificate. Oftentimes, we will create a certificate request, we will take that file and we will send it to the registering authority, we will enter a bunch of data and pay a fee, and they will process that data, validate who we are, and they will send us a signed certificate. Then we import that signed certificate into our building automation system, but we also have to have that signed certificate on any system that we're going to be utilizing.
Now there are certain building automation systems that if you put the certificate on the server, it will then send the certificate over to the browser and stuff like that, but most of the time, we will have the certificate on the server, on the supervisory device, on any devices that are connecting, and we will distribute the certificate to them. Then that certificate will be used for authentication, seeing who we are, as well as encryption. That being said, as I mentioned, we can self-sign and we can implement HTTPS, TLS as well.
Alright, so if you have any questions on this, I definitely encourage you to reach out to us. I hope this kind of crash course on certificates and certificating authorities gave you a better understanding at a high level of these. If you'd like me to go deeper into these technologies, or if you'd like me to do a post on OAuth and LDAP, definitely let me know. I'd be very interested because I'd like to explore that. I've used that in programs I've written in the past.
One last thing I do want to reiterate, if you are using TLS that you are you using the latest version of TLS. Right now, it is TLS 1.3 in most building automation systems, or 1.2. If you're using earlier than that, there is a large potential for compromise. If you’re using SSL, that is compromised. SSL is now considered a compromised technology set. So, definitely be aware of that.
Thanks a ton and take care.
