Root Causes 13: PKI for IoT

Hosted by

Tim Callan

Chief Compliance Officer

Jason Soroko

Fellow

Original broadcast date

April 25, 2019

The proliferation of Internet of Things (IoT) devices in many cases has outpaced security for those devices, leaving enterprises, end users, and the general public exposed. Learn how identity is an essential part of protecting any service involving IoT devices and how PKI is positioned to provide that identity.

Podcast Transcript

Lightly edited for flow and brevity.

Tim CallanToday, we are talking about Internet of Things, PKI, identity, and such matters.

Jason SorokoIt’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 CallanOkay. 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 SorokoIdentity 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 CallanYeah, 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 SorokoAgreed. 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 CallanSo how is that done? How do we establish and verify identity for our IoT devices?

Jason SorokoTim, 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.”

Tim CallanRight.

Jason SorokoSo 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 CallanWhat’s a static credential?

Jason SorokoStatic 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 CallanSo for purposes of who knows the shared secret, whether it’s a password or a symmetric token, they’re both the same.

Jason SorokoThey’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 CallanSo 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 SorokoYou couldn't.

Tim CallanIt’s the same across them?

Jason SorokoWhat 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 CallanThen not only can you intrude on the network and take down one device, you in principal could crash out the whole thing.

Jason SorokoYeah. 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.

Tim CallanAh-ha.

Jason SorokoWhoever 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 CallanSo once again if that were stolen then all of the devices are compromised.

Jason SorokoCorrect. 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 CallanBecause they did have the same shared secret on all the devices?

Jason SorokoExactly.

Tim CallanAnd that was a token in that case?

Jason SorokoExactly right. It was able to figure out one and thereby was able to figure out perhaps millions in one shot.

Tim CallanSo 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 SorokoLet’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 CallanWhich is?

Jason SorokoIf 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 CallanThen that just leaves you right where you were.

Jason SorokoAbsolutely. 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 CallanIt’s encrypted.

Jason SorokoExactly.

Tim CallanWe all know what you’re describing, right? This is what public key infrastructure is all about. You’re talking about a PKI scheme.

Jason SorokoA 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 CallanPKI 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 SorokoWhen 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 CallanThey’re expecting it to be complex and difficult.

Jason SorokoComplex and difficult. Which if you’re an IoT device vendor it’s the last thing in the world you want.

Tim CallanAre those expectations justified or is it actually something that should be well within the reach of anybody who’s deploying an IoT network?

Jason SorokoIf 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 CallanPKI 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 SorokoObviously 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 CallanSo 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 SorokoFor 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 CallanAnd 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 SorokoYeah, 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 CallanOkay 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 SorokoPrecise 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.

Tim CallanSure.

Jason SorokoNow 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 CallanYou can’t revoke the airplane engine while it’s in the air.

Jason SorokoYeah. 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 CallanAnd 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 SorokoWhen 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 CallanTo 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 SorokoThere 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 CallanThere’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.

Stay informed with expert insights

Subscribe to Root Causes for engaging discussions on PKI, digital security, and best practices for protecting your organization's critical assets. Don’t miss an episode!