In this episode, we discuss what certificates are, how they work, and what you need to understand about certificates for building automation.
Click here to download or listen to this episode now.
Resources mentioned in this episode
Training Video
Transcript
Phil Zito 0:00
This is the smart buildings Academy podcast with Phil Zito episode 331. So folks, in this episode, we're going to be kind of rerecording our certificates and certificate authorities for Bas, podcast and live stream episode, I didn't like how the previous one turned out, I felt it could be more concise and more clear. So we're going to be going through it again. Alright, so what is happening here in building automation world is this thing 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 certificate ng requirements. And 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 certificates and certificate authorities. So certificate thing, at the end of the day, right 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. So 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 like 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 kind of that checkbox or the rather, the lock box next to the domain name, okay, you'll see 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 a information, little circle with an eye in the middle of saying not secure, or maybe a triangle with an exclamation point, a red triangle saying not secure. And the funny thing is that a lot of folks don't realize this is kind of a brief segue is that you can implement what's called a self signed certificate. And we'll talk more about that a little bit later. And that self signed certificate, that would flag a site as not secure potentially, even though things are encrypted. And that simply has to do with 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, because at an end of at the end of the day, certificates not only validate who you are, and who's connecting. So they will go and meet one of the OSI secure security layers.
Phil Zito 3:40
Basically, their security services, they'll meet one of those, and they will prove that that one of those services which is non repudiation, which is you know, proving that the people are who they say they are, and that they actually sent the messages that is done through one of the ways it's done through is certificate NG. But at the end of the day, we have this thing called a certificate. And I'm going to talk about certificate ng for encryption. I'm going to talk about certificate ng 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 have 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, right? So everything that is transferred between our web browser and the BAS device is going to be clear text, and then there's ace TTP s which is hyper transport or Hypertext Transfer Protocol Secure Your or with a secure socket layer depending on how you define that acronym. And that essentially means that the data that is being sent from your web browser to the bes device and vice versa, is encrypted. What is 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 as much of a deal 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, who their temperature set points, their pressure set points, etc, especially in the FDA, or in the midis medicinal fields where they're developing medicine like pharmaceuticals, they do care about those values being leaked, and they want them confidential. Because then their competitors can know, okay, they're using this temperature in manufacture 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. And 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? While I'm going to tell you it's through this thing called Public Key Infrastructure, or PKI. So you've probably heard, maybe you've heard of the term public key and private key, okay, so 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, right, 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 goes and 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 certificate in comes in, is that 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 MD five or think RSA, if I remember correctly. RSA is what is it, 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
Phil Zito 8:34
a data hash to basically create ones and zeros. And then that hash is signed using a key which then goes and makes the data encrypted, that signature is combined, right with a certificate. And that then goes and 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 right. And 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. And this is why we have certificate ng authority authorities. So a certificate ng authority, right is going to sign the certificate with a private key, guaranteeing that that certificate 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 like 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 certificate NG. At the end of the day, these certificates as I mentioned, they validate who is who. And so when we go into our Bas, and we want to go and 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 go and use a certificate now we can do this thing called self signing, self signing is where we generate our own private key. And like if you wanted to do this, right now, you could go into IIS on Windows, and you could go to this certificate section. And you could self sign a certificate and 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 know, you are who you are, no one's verified that and you sign your certificate and you create your self signed certificate. That's what a self signed certificate is. 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. And you can go and 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 like you are who you say you are, because anyone could have had that key and self signed a certificate. And, you know, then pretended to be someone else. Now, why does that matter? Because if someone understands these keys, right, that they have access to these keys, they can decrypt information decrypting bas information is not necessarily the most dangerous thing in the world, I thought 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 decryption, like you are self signed certificates, you would not know that this device is legitimate, potentially. Whereas if you distribute a
Phil Zito 13:02
authorized and approved and validated certificate, you can go and have a greater I'm hesitating to say something is 100%. But you can have greater belief that whoever it is connecting is actually who they say they are. Okay, so you've got certificate Ng, you've got encryption. And the two are not necessarily the same certificate ng is a way of validating connections are secure, validating that who it is, who they are, is who they say they are is who they are, oh my gosh. And 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 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 building automation or 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 go and use a certifying authority, and a registering authority. So RAS registering authority ca certifying authority, where I would go and utilize these would be if I had a public facing building automation device, I definitely would want to use a actual validated certificate to ensure that whoever was connecting to my device is legitimate.
Phil Zito 16:12
There's other technologies you can use as well, like, oh, auth, and LDAP, that are on the authentication side of things. Maybe we'll do an episode on authentication if y'all are interested. But as far as certificate and 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 we're going to have to determine what form of certificate does it implement, what key size does it support. And how do we go and issue a certificate, oftentimes, we will issue a certificate, and then we will go or we'll we'll create a certificate, we will then and there will be an optional, say like create a certificate for SCA or Certificate Request is typically what it's called. So we'll create that Certificate Request. And then we will take that file, and we will send it to the registering authority. And 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. And 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 it'll 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, we will go and distribute the certificate to them. And then that certificate will be used right for authentication, who seeing who we are, as well as encryption. That being said, as I mentioned, we can self sign and we can implement HTTPS TLS. Just doing it that way. 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 certificate authorities give 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 set a podcast on Oh auth. And on LDAP. Definitely let me know we can definitely do an O auth and an LDAP. So LDAP is Lightweight Directory Access Protocol, if I remember correctly. LDAP There we go. It is light. Yeah, Lightweight Directory Access Protocol. So LDAP is something that's used by Microsoft and a couple other folks to basically connect to Active Directory and validate. And then Oh auth is another one. If you've ever like connected to Google, through Facebook, or you signed up to something and it's like, do you want to use your Google or Facebook account to sign up for this app? And you're like, Yeah, I do. That's Oh auth that work? So oh auth allows you to use like a Google or a Facebook who can be considered validators of your identity to then register for something. I haven't run into any building automation systems that use O dot o off but I have seen them use LDAP if any of you have run into building automation system using O auth. I'd be very interested because I'd like to explore that. I've used that in programs I've written in the past. But definitely LDAP is something I see supported. I do want to reiterate that if you are using TLS that you are you Using the latest version of TLS, okay, right now it is TLS 1.3 In most building automation systems, or 1.2. But if you're using earlier than that, you there is a large potential for compromise. And if using SSL that is compromised SSL is now considered a compromised technology set. So definitely be aware of that. Thank you so much for listening. All of our podcast resources will be available at podcast at Smart builders academy.com Ford slash 331. Once again, that is podcasts at smart buildings academy.com four slash 331. And we will go through and answer any questions you have in the comments. Wherever you're watching or listening to this, definitely go and post those comments. If you do me a favor once again, like I ask
Phil Zito 20:58
if you can like and subscribe and click on the notification bell so you are notified of our new videos. If you're listening to this. Definitely please go. And if you're listening to this on iTunes, leave us a five star review. If you feel that we've earned it, it helps other people find this content. Thanks so much for being here. And upcoming on Friday. We are going to be talking about some sales strategies. For those of you who want to bring a little bit more business in your doors. We're going to be going through that. Alright, thanks so much. love having you all here and look forward to talking to you all on Friday. Take care
