Chat With Us
We are here for you!
Talk to a fellow human.
The Root Causes podcast explores the important issues behind today’s world of PKI, identity, and digital certificates. Podcast hosts Jason Soroko (CTO of IoT, Sectigo) and Tim Callan (Senior Fellow, Sectigo) recently sat down to discuss the issues and requirements surrounding public key infrastructure for Internet of Things (IoT).
The Root Causes podcast explores the important issues behind today’s world of PKI, identity, and digital certificates. Podcast hosts Jason Soroko (CTO of IoT, Sectigo) and Tim Callan (Senior Fellow, Sectigo) recently sat down to discuss the issues and requirements surrounding public key infrastructure for Internet of Things (IoT). Here is what transpired.
(Lightly edited for flow and brevity, this episode of the Root Causes PKI and security podcast originally appeared April 25, 2019.)
Tim: Today, we are talking about Internet of Things, PKI, identity, and such matters.
Jason: It’ll probably be the first podcast of hopefully several about the topic. Today we’re going to dig into the current problem and shine a bright light on what might be the solution.
Tim: Okay. So I’ve got an IoT network. That means there are devices that are out there in the field. They’re beyond my firewall. They’re out in the DMZ. They’re doing things. They’re giving me information or taking commands or taking action or feeding data back or somehow connecting to business-critical processes and systems. Where does identity fit into this?
Jason: Identity fits in to it because typically a device could be talking to another device or to an enterprise resource such as an ERP, or it could be talking to the equivalent in the Cloud. And typically, if it’s emitting something, if it’s like a telemetry type of sensor you might want to really know that that device is the device that should be emitting this information.
Or, what’s a more common use case, is where a controller type of device is actually receiving commands from another device and you really, really want each system to be able to mutually authenticate each other. You really want to know the true origin that the command was emitted from and is being received by.
Tim: Yeah, I think of IoT devices falling into two main camps, which are sensors and actors. And a device can be both. Sensors are finding things; they’re reporting them, and they’re sending them back. Like a meter. Then there are actors that actually take commands from other sources and change based on those, and basically for the security and proper functioning of our systems, both sensors and actors need to be reliable. That we’re getting real information, or the information that’s being provided to the device is genuine. Do you agree?
Jason: Agreed. Because we are talking about connected devices, as you said at the top of the show, and connected devices have a vulnerability that in traditional security terms we might call a Man in the Middle attack. There are many ways to get into the middle of that communication depending on the scenario. If it’s connected. And so for commands that are going across the wire, you really want to protect those commands and you want to protect the identity of the origin and destination of those commands.
Tim: So how is that done? How do we establish and verify identity for our IoT devices?
Jason: Tim, if you and I were going to go do business together right now, we might agree on, “Hey if you come to my door in thirty minutes and you knock three times and I’ll know it’s you.” And that’ll be our shared secret. One, two, three. That’s a real old fashion way of doing things and it kind of worked. The problem is if anybody heard us having that discussion they might go, “Oh I know what to do. I'm just going to knock three times, and Tim will think it’s me.”
Jason: So you might be dealing with somebody you think is me but in fact is someone else. Believe it or not that’s exactly the problem we see with something that we call in the business static credentials.
Tim: What’s a static credential?
Jason: Static credentials can take several forms. They’re typically some sort of alphanumeric representation that’s pre-stored on the devices from the factory and that could be something that a lot of people are used to such as a username and password. If a device needs to log in to an ERP system or a Cloud system it might be pre-programmed with a username and password. If the device itself needs to be authenticated to, if it sees that username and password being used, it might give you root access to the device itself.
So that is a form of static credential. We also see another form of static credential being used. Again, in the business we call it a symmetric token. The word symmetric simply means that the same secret is known to both the device itself (the secret was given to the device at the point at which it was created) as well as some other system. It might be the Cloud system that that device connects to or it might be another device. The same secret is shared on both sides. Therefore, the secret is essentially symmetric.
Tim: So for purposes of who knows the shared secret, whether it’s a password or a symmetric token, they’re both the same.
Jason: They’re used, I don’t want to say interchangeably; people typically will choose one or the other. But I find it interesting that when symmetric tokens are used a lot of times people are thinking that they’re being very clever that they’re not using username and password, but they don’t realize that there’s not a lot of extra security. It’s simply a static credential.
Tim: So I have a large number of devices out in the field. I have tens of thousands of devices, and I'm using a static credential. Presumably, I'm not generating a unique username and password for each of these devices, right?
Jason: You couldn’t.
Tim: It’s the same across them?
Jason: What we’re finding in the real world that a lot of devices are still being created with a default username and password that is the same for just about every device, which is probably your worst-case scenario.
Tim: Then not only can you intrude on the network and take down one device, you in principal could crash out the whole thing.
Jason: Yeah. Believe it or not, Tim, we’ve also seen symmetric tokens like, for example, key fobs. You might have 10,000 key fobs or more that all have the same alphanumeric code.
Jason: Whoever architected this thought, “Oh well nobody’s ever going to guess this code. It’s twenty-three letters and numbers long.” Nobody will ever guess it, but they didn’t make it different per device.
Tim: So once again if that were stolen then all of the devices are compromised.
Jason: Correct. Hence, things like the Mirai Botnet and why it was able to compromise tens of thousands if not millions of devices sometimes in one go.
Tim: Because they did have the same shared secret on all the devices?
Tim: And that was a token in that case?
Jason: Exactly right. It was able to figure out one and thereby was able to figure out perhaps millions in one shot.
Tim: So to some degree even one device compromised might be all you need to work your evil, but surely if you have access to all of them or nearly all of them the potential only goes up.
Jason: Let’s talk about California state law. California has an actual law at the moment on this topic. One of the things that it specifies is if you want to sell a device into the state of California it needs to be able to have a capacity to change that static username and password at some point during its lifecycle. That’s the essential idea. And that’s great, except there’s one more problem.
Tim: Which is?
Jason: If I'm able to listen in on the network and let’s say that network happens to be the public internet. If those username and passwords or symmetric tokens are sent in the clear as part of their authentication cycle, they’re not much of a secret, are they?
Tim: Then that just leaves you right where you were.
Jason: Absolutely. So for IoT what would be better? What you need is a non-symmetric or asymmetric type of secret and the ability for that secret to be changed through time throughout the device’s lifecycle. You also need to be able to protect communication from device to device or device to the Cloud. In other words, setting up a TLS session.
Tim: It’s encrypted.
Tim: We all know what you’re describing, right? This is what public key infrastructure is all about. You’re talking about a PKI scheme.
Jason: A lot of people who might be listening to this podcast think about IoT security. The right way to do it for device identity is to use a PKI infrastructure.
Tim: PKI isn’t new. Why is it then that in these examples we talked about before with the static credentials, why wasn’t PKI being employed then?
Jason: When I’ve spoken to a lot of people who have looked at PKI and said, “Well I'm not going to go that way. I'm just going to go with a cheap and cheerful solution and cross my fingers for security.” One of the reasons is they fear PKI. They fully know it would be the right way to do it, but they remember back to an earlier life they may have had where they were a manager of a PKI for a passport system or a financial system or of some other form of a badge-in system. There’s so many hundreds of dozens of PKI systems that have been built over the past several decades that have had fairly lengthy deployment lifecycles and were fairly expensive as well.
Tim: They’re expecting it to be complex and difficult.
Jason: Complex and difficult. Which if you’re an IoT device vendor it’s the last thing in the world you want.
Tim: Are those expectations justified or is it actually something that should be well within the reach of anybody who’s deploying an IoT network?
Jason: If you see the advertisements or a salesperson coming up to you from one of the traditional PKI companies, I think you have every right to be skeptical because those are the companies that made a lot of money from professional services and this complexity. But I think what’s changing, is the idea of purpose-built PKI for IoT. In other words, PKI that is very, very sensitive to the needs of an IoT device vendor.
Tim: PKI is a basic toolkit. It’s a building block. But you could imagine a PKI solution that is designed around the specific needs of an IoT vendor. So what are those things?
Jason: Obviously scalability. We’re talking about millions and millions of devices. Even the largest passport systems in the world might’ve used only, you know X million. You might be doing that number of million per week as an IoT device vendor. So obviously scalability is number one. Reliability. This thing just cannot go down, and therefore we’re seeing a lot of people with interest in IoT issuance coming from the Cloud. It used to be that nobody ever got fired for being paranoid with their PKI.
Therefore, on-premise was a great thing, but now people are realizing, “Boy, the scalability and the ease of hosting that PKI in the Cloud is great.” We talked about complexity earlier. If you look at the sheer complexity of all the knobs and buttons and settings and configurations that were necessary to get a PKI working just right for a passport system or for a financial system, you can strip away a massive amount of complexity and make it purpose-built and simple for IoT device vendors.
Tim: So I'm an IoT manager, there’s a lot of PKI questions I don’t really need to ask because we understand the use case and it can be given to me in a way where I'm channeled down the correct decisions?
Jason: For a lot of device vendors you might want to just keep it as simple as “I want to define what my certificate profile is.” Or if I have several profiles, just define what they are and I might also want to have one piece of complexity, which is I'm running my devices within a hierarchy. A trust model that has a hierarchy. Therefore I have a highest level trust, which happens to be the trusted third-party CA perhaps, and then I have an ecosystem of vendors that I'm interoperating with and I want to be able to define who those are. So I do have some complexity, but my complexity is very finite and defined. Can you please give me that PKI and I’ll buy it?
Tim: And it’s laid out for me so that I don’t have to be a PKI expert. I don’t have to have a PhD in PKI to know how to do this. I can just be a sensible person who understands what my devices are and what my needs are and I can be guided to make the right decisions.
Jason: Yeah, the person at the factory who might be doing a manual issuance, for example, might be wearing a hardhat. They might not be a 25-year PKI veteran, which is rare to start with. Can I have a PKI that’s simple enough for a person who is more operationally trained then hardcore PKI trained to be able to do this? And the answer now thankfully is yes.
Tim: Okay Jason, so we talked about some of the aspects of the PKI system for IoT. It’s scalability, reliability, and simplicity of use. What about precise control?
Jason: Precise control actually could probably mean a few things. One of them could be being able to very precisely control the number of devices that are coming off of your assembly line. It’s the question of genuineness. The ability to hand over not just the device that has a serial number, but a device that actually can electronically identify itself to a network on its initial startup. That’s very important within a supply chain. So that’s one form of precision in the earlier part of a lifecycle.
During the operational part of a lifecycle, you know what’s interesting about the difference between operational IoT devices versus say human PKI that we’ve been talking about earlier in the podcast, typically where people come and go from a system? They can get hired or leave a job. They can also be citizens of a country or perhaps pass away.
Jason: Now within an operational aspect, people typically think about PKI and that power to be able to revoke a device that perhaps might be misbehaving. But I know my friends in the medical industry or in the automotive industry or even in critical infrastructure, the concept of revocation can be an important one but when a device is actually operating that could be a really scary topic.
Tim: You can’t revoke the airplane engine while it’s in the air.
Jason: Yeah. In other words, rather than relying on revocation as a tool, one of the tools that we can use in terms of precision as you say, precision of identity within a lifecycle is that ability to actually have a lot more renewal cycles. To shorten the renewal cycle. Instead of the airplane having an identity certificate that lasts the entire lifespan of the airplane, perhaps that airplane gets a new certificate renewed every time it takes off and lands.
Tim: And then you don’t have that concern of destroying something when it needs to function or lives are at stake or are otherwise very high, At the same time you can have a high degree of reliability that everything that is operating in the system should be.
Jason: When you consider human PKI versus IoT-based PKI, what really needs to happen in terms of that question of precision, when we’re talking to people in terms of operational use cases and very critical operational use cases, is you can use that precision of being able to define PKI to be able to handle your use case correctly. From the trust model being able to do very, very secure but also open trust for inter-operability all the way to what’s the correct certificate profile to be used for you and what’s that certificate lifecycle like?
What we used to do for human PKI, which might’ve been fairly monotonous. In other words, we used to do the same thing for just about everyone because human beings have a certain lifecycle. Devices can have very, very different lifecycles and that’s the precision of PKI that can be replicated neither by static credentials nor perhaps old non-purpose-built PKIs, that were quite complex for other purposes.
Tim: To bring it back home: With the proliferation of devices, the mission critical nature of what they’re doing – whether it’s a car driving down the street or a nuclear power plant or these really critical systems – it may be that once upon a time we weren’t so worried about being able to get this level of granularity out of our PKI systems, but now we have to. It’s a different time.
Jason: There might be specific controllers or actuators, you called them actors, which is maybe a perfect generic term for them. Those actuators or actors exist in cars, critical infrastructure plants, medical devices, and smart cities.
It’s kind of funny, you and I didn’t really go into specific verticals but these concepts exist within each of those verticals. And you know that might be an entire podcast by itself is to talk about some of the differences in the way you’d setup a PKI for each of those verticals. That might be an interesting podcast but for now it suffices to say that PKI can handle it.
Tim: There’s a lot more detail behind this. We’ll want to get into this, and we touched on several launching points today that will be their own podcasts to come including that last one about vertical applications. This was a good overview of the topic and, Jason, I appreciate it very much.