SMART CITIES

Louis Parks: We need to be thinking about: we can keep a building safe today, and certainly for the next five, six, eight years, but how do we keep it safe for the long term? And that’s where you will need to turn to quantum-resistant methods.

Kenton Williston: That was Louis Parks, the Chairman, CEO, and co-founder of Veridify. And I’m Kenton Williston, the Editor-in-Chief of insight.tech.

Every episode on the IoT Chat, I talk to industry experts about the technology and business trends that matter for developers, system integrators, and end users.

Today I’m talking to Louis about the security challenges for smart buildings and industrial automation, and some cool new ways you can lock down your assets—including the quantum-resistant cryptography Louis just mentioned.

Louis, welcome to the show. Can you tell me a little bit about yourself and what Veridify does?

Louis Parks: Sure. Good to be here. Veridify is focused on security for very, very low-resource devices, and really has been since its inception. And what I mean by that, since security’s a very big landscape, we’re focused on identification and authentication—which, not always working—but we take it for granted when we do our banking and do things on large, powerful platforms like PCs or smartphones. But when you have very, very low-resource processors—perhaps in an embedded device or in the Internet of Things—authenticating them and knowing they’re your device can be difficult. So we develop methods for doing that type of authentication identification.

I have three partners who are mathematician-cryptographers and specialists in the area, who helped develop these very efficient protocols. And I’m a co-founder of the company, who helps in figuring out how we take these things to market and turn them into the products that we market today.

Kenton Williston: So, this is a really interesting topic and a timely topic, I think, because the just general security landscape has been—it’s an ever-shifting landscape, to be sure. But I think last year, with the pandemic and people moving to remote work, there’s been just a real, I think, significant shift broadly on the sort of threats people are encountering. So I’m wondering, when it comes to the areas you specifically are looking at—things like industrial IoT and building automation and control systems—how you see the landscape shifting in those specific areas.

Louis Parks: Sure. Well, so first of all, the change in how we work has really brought attention to the whole idea of security. Privacy, of course, is something that comes out of that. But the idea now that—whether it’s your video call on whatever platform you’re using, the ordering, banking, what have you—suddenly we’re all aware that it’s a very digital world, from retail to socialization. So that’s a heightened awareness that we’re operating against.

What we see now, and what has continued as a level of sophistication—because as we’ve tried to connect more things together to make it efficient, so we could work remote, work from home, make the supply chain more efficient, whatever—has given a broader horizon for the hackers and attackers out there to infiltrate and/or go after things. Our focus, again, is on the small devices that run these things.

Specifically, we’ve been very busy the last year in the area of building security. That’s not getting into a building or the cameras on a building, but rather the fact that for years, and even more than decades, buildings have relied on processors to manage the heating system, the HVAC systems—more recently, the lighting systems and the elevators. So even before the term “smart building” came into vogue, buildings relied on processors.

And in fact, unfortunately, as those have been now connected to the IoT, it’s given another access route for an attacker to get to the IT systems in the buildings, and places where valuable data may be. So, really, as we’ve gotten so much more connected and better at operating digitally, so have the attackers.

Kenton Williston: Yeah, absolutely. And, like I said, this is not exactly at an all-new trend—it’s something that’s been happening. This example’s getting pretty dated by now, but people have been talking about, like the Stuxnet attack as an example of how the security landscape is not just about the servers, but it’s about all the equipment that’s out there.

I think it’s fair to say there’s a broad sense that, hey—you’ve got to protect your IoT systems. But I think it’s also the case that people don’t really fully appreciate all the time just what exactly the threat landscape is. So I’m wondering, from your point of view, are you seeing some significant risks that people generally are not aware of?

Louis Parks: Oh, absolutely. When you talk about attacks, and what have you, the threat landscape goes back before we got the label “IoT.” I remember well over 10-plus years ago being in Washington at a meeting where they were discussing technologies to help with border security. Many people listening to this and maybe on the podcast have a car where you can look at the air pressure in your tires on a dashboard or in a display to know if the air pressure’s good or not.

That technology comes to you courtesy of RF (radio frequency), little broadcasters in the wheels talking to your cars that have been paired. And if anybody’s had a damaged wheel, like I have, you know that the dealership will charge you dearly to pair a new wheel to your car. But because it’s RF (radio frequency), it’s not only talking to your car, but it’s broadcasting outbound too.

So the discussion was, "Gee, people are driving across the border. Perhaps we could use that broadcast, that radio-frequency broadcast, as metadata to identify a vehicle." So, that’s arguably a friendly use, if we believe in border security. But the point being is: that is what would now be considered an IoT device. A car itself is probably, to many people, an IoT thing now. So, these threats have been around for a long period of time. And probably a lot of people have not thought about their wheels on their car betraying them to somebody for the purposes of location, or tracking, or other nefarious activities.

Kenton Williston: Yeah, that’s a great example. I’ve got a pretty old beater myself, so no RF in my tires, but I have to admit that that was a security risk I was completely unaware of until you mentioned it just now. Now, having said all that, our audience is probably smarter than me, very well aware of the many different security risks that are out there, and doing a really good job of trying to secure their IoT systems. So, I’m just wondering, from your perspective—to the extent that there ever is any such a thing as a standard approach to anything in the world of IoT, where every system is a little bit different—what the standard/typical approach to security looks like today. And where you see it being strong, and where you see there being some gaps in the current approaches.

Louis Parks: There’s a couple of things that you want to do, or people are doing. And, in general, there’s a lot of attention being paid now, unfortunately again, because the news is not always great. And we always get reminders—although not IoT—things like SolarWinds remind us that if we’re going to be digital, we are all potentially susceptible to various types of attacks.

The challenge in IoT is significant, in the sense that we have a really wide range of devices—whether you look at industrial, whether you look at a commercial building, or a home—because the devices, number one, may come from many vendors. We’ve all seen the value of a single-vendor solution and the ability to control your world if you come from Apple. And then the value from a marketing perspective if you allow many players to play, like in the Android world. But at the same time, ensuring that all those players are good people.

So in the IoT, when you have a mix of technologies, it becomes a challenge. People are understanding that more and more. So there really isn’t one security thing that you should do. There’s probably many. Certainly the first thing is to know if you have an issue, and there’s a lot of really good anomaly detection, network-monitoring technologies, that are being developed. So that people who want to know, or should know, if they have an issue can know. That doesn’t prevent an attack, doesn’t prevent somebody from stealing data. But, arguably, a very critical issue to know is—is it happening? So that you need to increase or improve whatever it is you’re doing.

Of course, all the other technologies have been around for years and decades. Whether it’s malware protection, firewalls—on and on the list goes—you need to employ when you’re talking about networks. But the IoT and a lot of devices, number one, operate outside of these very controlled networks—the three floors of your office building. A lot of these devices are out in the open.

The other thing is that a lot of these devices are engineered or designed very eloquently to use absolutely the smallest processor that will deliver all the features. So one view of some of the audience might be, "I have all the tools I need. I’m using them today." They might be on a tablet, or a gaming PC, or a smartphone.

But when you go down to a very, very small 32-bit, or 16-, or even 8-bit processor that’s been optimized to provide a single function in a building or embedded platform network, you don’t have the luxury of the computational capability to put that authentication technology on it—to put that digital certificate and all of the signing and verification capabilities on it that you take for granted—the TLS or SSL solutions you use when you’re on a network.

So there’s a lot of attention being paid to that. There’s a lot of innovative technologies: from how do you take public-key or asymmetric technologies, as we do, both legacy things like ECC or ECDSA—which some of your viewers will know are 30- 35-year-old technologies that still lead the way for legacy—to upcoming quantum-resistant methods. How do you shrink them and make them work? As well as other technologies like PUFs—physically unclonable functions—which are fingerprint technologies, and enable you to provide unique identification on a per device basis, or a seed of identification, a root of trust.

So there’s really a lot of areas that are being brought together, again, because you have a really, really broad mix of devices. And a lot of them need to be out there by themselves, which again is why we focus on device-to-device as an area. But you would not look to us as a single solution. It would be us in combination, arguably, with some of these other technologies to make yourself secure.

Kenton Williston: Yeah, so let’s talk about your solution a little bit, because, like you said, I think when everything’s said and done one of the biggest challenges you really pointed to is—whether you’re talking about an industrial setting or a building-automation setting—you’ve got a landscape with a lot of existing legacy devices that aren’t going to go anywhere anytime soon. You’ve got a landscape with a lot of things that were designed for minimal cost, minimal power. So, what are you bringing to the table to help protect this very diverse, fragmented landscape that’s not really set up, like you said, for the kind of things you would think about in, like a data center or your own home PC kind of setting?

Louis Parks: So, pretty interesting, and we’ve been immersed for about a year now with our platform, DOME, that we developed a few years ago as a platform for device management, not unlike many IoT-product or device-management platforms that are out there. The difference, again, with ours was we were using, or we are using, the ability to shrink protocols, asymmetric or public-key protocols, that allow authentication capability down to fit on the actual device. So a device in the IoT, or a device out there, can actually manage its credential, manage its authentication, without the need to connect to a cloud or a server to do that.

Of course, connecting to a cloud and server is a very valid way with larger devices that come embedded with URLs to authenticate them. But, again, if you have a very small device it’s only going to operate in a limited network, but could provide an exposed platform. That was something that we were focused on.

So we developed DOME, a device ownership and management solution, where we manage a credential in the cloud in a blockchain for the device. But the device actually challenges and ensures it’s talking to something authentic. We took that and translated it to the building-automation world, where a building, again, as I mentioned earlier in the podcast, for years has run on processors managing elements of a building’s operation today.

And, of course, it’s getting even more sophisticated. There’s some really brilliant use of technology to make building smart, more comfortable, more adapted to our use. All of that involves introducing more processors on the operational-technology side. To manage them you connect them to the IT side. Of course, in the IT side is where we find the networks, and then the databases, and the back offices of the people in the building. That’s where the danger emerges. So that has been an interesting challenge and a great use.

There’s one additional element you alluded to, or may not realize you alluded to, and that is that 99% of the market that we’re talking about protecting exists. It’s already there. The buildings have been built, they’re running. So if you’re designing a brand-new smart building today, and if you were just fresh on the plane back—well, you wouldn’t be fresh—fresh off your Zoom or digital call from CES with ideas for all the new technology going to put in it, likely there’ll be some good security tools.

But if your building’s only two, three, five years old, you probably still want to use that very expensive air handler cooling system, what have you, you have installed, but it probably has not got the protections you need. So retrofitting security to a preexisting infrastructure is also a challenge, and something that we’ve addressed with something we call bump-in-the-wire technology, that we’d looked at for a period of time. And, in fact, developed some solutions with our partner Intel to deliver to industrial IoT, and have now adapted it for the building-automation protocols like BACnet, and later Modbus and KNX, to retrofit security to a preexisting infrastructure—in this case a building—which is another challenge in making things secure in current days.

Kenton Williston: Yes, I want to dig into that a little bit more, and here is just a little shameless plug. We’ve got an article that corresponds to this same conversation over on insight.tech, so I encourage our listeners to go check it out. You can get more details on this bump-in-the-wire solution, how it works, and why you might be interested in it. But, just to look a little bit closer at that here and now, can you tell me a little bit more about what this architecture looks like? And you mentioned that it’s got some Intel technology—what kind of technology is incorporated there?

Louis Parks: Sure. So bump-in-the wire’s not a unique solution to us; many industries and areas have it or contemplated it. What we’ve done here—a couple of things that are unique. Number one, we’ve based our initial solution on an Intel FPGA—a small, very powerful, low-cost FPGA. So not only does it ensure that we can address the security issues today, but an investment in this relatively low-cost device will give us the adaptability going forward—because the horizon for the attacks, the nature of the attacks, is continuously evolving.

And, typically, as you’ll see in many, many articles when they talk about buying something that’s connected, or the IoT, they always say, "Make sure you have a way to update to the latest patches and fixes, and what have you." So not only do we have a very powerful platform to provide the technology, but we have one that’ll allow adaptability.

For the building space what was critical is that we had a relatively simple plug-and-play solution. So it’s a simple plug in plug out between the controllers and the Edge devices that are already installed—typically running on some sort of IP platform or network in the building-automation space. Our initial solutions are designed for the BACnet world, which, again, is a building-automation standard for how devices and buildings communicate.

So, our device is running; it runs the initial ones, NIST-approved, legacy—what I refer to as legacy protocols and methods for certification purposes. But other versions of it will run a quantum-resistant crypto—and we should talk about that for a minute—which is critical for long-term protection. And of course, finally, this is BACnet, which is a building standard. It runs over BACnet IP. We’ve developed other technologies that coordinate with it to ensure that you can also monitor the discussions that are going on.

The summary is: we were creating a secure tunnel from the controller to this bump-in-the-wire device with encrypted data flowing over a BACnet-compliant communication. So we don’t replace anything that a building currently has, or anything in the standard. Then it protects the device it’s plugged into behind it. So, that’s a very simple description of this device. It’s designed to be flexible in the protocols it manages, and what have you. A lot of that power and flexibility, again, comes from the ability of having this FPGA-background platform that will allow us to adapt it. And so, unique functionality capabilities, as we move through the building space.

Kenton Williston: You’re talking about this bump-in-the-wire solution protecting the device that’s behind it. So, are we talking about something where you would need to deploy, like a one-to-one everywhere you’ve got a device you’d want one of these bumps-in-the-wire? Is it per floor, per building? What’s the architecture look like?

Louis Parks: The architecture needs to address a couple of different scenarios. We would suggest the ultimate protection, of course, would be one-to-one, and ensure that every device has this secure, encrypted element—authenticating all the inbound traffic, and encrypting and delivering back all the outbound data back to the controller in the building. That’s not always possible, or feasible, and sometimes it’s just probably not the right architecture.

So, although we do have these relatively low-cost, powerful, FPGA bump-in-the-wires, we also have a similar technology in a router form. Again, the secure connectivity—which we call S Link—so we can run it to a router, which then could have several devices. So it could be a one-to-one, or one-to-many configuration—as is exactly what you find in the building spaces today.

Kenton Williston: That makes sense. I do want for sure to ask you about the quantum cryptography. So, this is certainly, if you’re up to speed on the latest and greatest security, a hot topic. But in some ways it kind of feels like, "Gee, if we’re just talking about a building-automation system, isn’t this really kind of overkill?" So, what’s the rationale behind this, and why have you taken this really hardcore approach?

Louis Parks: Sure. It’s not overkill. As a matter of fact, in addition to providing DOME with NIST-approved methodologies, we—ourselves and my partners, their background is in the mathematics of asymmetric and public-key methods—we’ve developed and published methods which are quantum resistant, as well as we are working with several methods that NIST now has under review for the purposes of standardization.

But focusing just on the question about quantum resistance—again, many of your listeners will be aware—but quantum computers since the late ’70s, early ’80s, were a white paper/physics idea that was out there. And about three, four years ago, actually maybe five now as I think about it, IBM and MIT simultaneously managed to create working prototypes. Now, these are not full-functioning, or were not at the time full-functioning, but proving the science, the technology, behind a quantum computer.

And again, these computers are not in the future going to replace our current computing. It’s a different type of computing. You’re probably not going to have a smartphone running on quantum. But they do manage and process data differently than our current conventional computers. And, again, there’s a lot of articles—it’s years later—many of your readers would be familiar with it. But the reason we’re talking about it—and they have evolved, and they’re getting better, and they’re getting more stable, and they’re getting larger, which is a key element. So they become more practical to use—likely in a data center-type fashion. So they will be great for solving DNA-sequencing issues, discovery of new drugs, etc.

And, unfortunately, there are at least two algorithms that have been developed to run on quantum computers that have been mathematically proven that will attack a weakened—and in one case, break—the legacy methods which I’ve referred to a few times—elliptic curve, RSA, Diffie-Hellman—when you have a large enough quantum computer. So, the part I can’t answer—and it’s hard for anybody—when will that be? It’s not next year or the year after. Could it be five years out, or seven years out? Don’t know. People commercially are working on it, as are nation states. So, it will happen, but we don’t know the timeframe.

Which brings us back to the discussion today on a building, where you put up a building—not unusual to stand for decades, if not 100 years-plus. Arguably the systems get replaced, but they get replaced every 15, 20 years. So a system going in today will likely be around when there’s a large enough quantum computer. And that quantum computer will break the ECC or the public-key methods. You cannot increase the security of ECC or RSA to avoid it. They will actually be broken by Shor’s algorithm in particular, and weakened by Grover’s algorithm.

So we need to be thinking about: we can keep a building safe today, and certainly for the next five, six, eight years, but how do we keep it safe for the long term? And that’s where you will need to turn to quantum-resistant methods.

Kenton Williston: Makes sense. Then the follow-up question there, is: why use FPGAs for this role? Is there something particularly advantageous that they offer?

Louis Parks: I guess the fair answer is, yes and no. So, there are equal processing-capable technologies and microcontrollers and ASICs, and one could even argue in some cases even more optimizable technologies than an FPGA. But the critical element for what we’re doing today—and I think for a lot of the building space, which we have found to be years behind where the general processing community is, and certainly years behind a lot of the new IoT—is we’re providing the tools that we believe and think are critical today, and that landscape is shifting.

I think the key characteristic of the platform that we’re operating with is that it’s field programmable. So, we’re delivering solutions that are going through third-party testing and all the verifications you want to make sure that they’re secure, but will also give us the capabilities to adapt these devices, not only to different building and industrial IoT operations, but also to adapt to the market, and the threats, and the nature of what we’re looking to address, as we’ve been discussing.

So, although in some cases—certainly people are probably familiar with FPGAs—they can cost 1,000s of dollars, the ones we’re working with—and in particular with our partner Intel— are still powerful but are a fraction of that cost. So there is not a penalty from that side, but there is a significant dividend from the flexibility and our ability to address the market.

In some cases, even specific projects that we’re working on, where we’ve had discussions with building owners—sophisticated building owners, who have very extensive networks operating already within their buildings, understand all the operational technologies—and they have several requests that frankly we hadn’t contemplated in the basic platform, but because we’re working in the FPGA world we can answer, we can deliver. So we think it’s an ideal solution that the cost benefit—there is significant benefit from this FPGA approach.

Kenton Williston: So, I’m glad you mentioned the cost aspect, because I think historically there’ve been two big factors that have caused people to shy away from FPGA solutions. So, one is certainly been historically the cost—although, like you said, today there are a lot of very moderate-cost solutions that are available. The other, though, has just been the programming model. The way you configure an FPGA is very, very different from how you would program a microcontroller, for example.

So, if I were considering how I wanted to secure my building or my industrial systems, the thought of adding an FPGA in there I could see making me a little nervous, like, "Is this going to be something that I’m going to actually be able to manage? Or is it going to require me to learn a whole new skill set?" So, what do you say to that?

Louis Parks: So, first of all, to a lot of the industry this process will be obfuscated because we’re working with other partners, and this is their area of specialty—developing products and solutions based on FPGA technology. So, again, where the functionality of the device does need to be provisioned—whether it’s a microcontroller or an ASIC, and the other partners and other areas where we are doing similar solutions at a microcontroller setting—the FPGA, when it’s being provisioned both with the functionality of the platform will also be provisioned with the security technology.

So, again, it may not have the overall efficiency en masse for deployment, but the vendors who are working with it have the basic tools for doing the volumes that we’re talking about here. So, again, I think it’ll be proportional. If this was a high-volume consumer, low, low, low, low cost—yes, this would create probably a larger component of the cost of the device. So, we’re not in pennies; we’re 10s of dollars to low-100s of dollars in some of these cases.

So the provision and costs, I think, are proportional to the device. And certainly, again, the overall payback for this type of platform—I think certainly in the early stages of this industry—is easily there. This has not been an issue so far in the projects that we’ve been looking at or working with.

Kenton Williston: Got it. Great. So, I think we’ve covered a ton of ground here. So I’m going to ask you a very challenging question, which is: if you could wrap this all up and leave our audience with like one key takeaway, what would that be? What would be the one message you would want to convey?

Louis Parks: I think the message I’d want to convey is that we all need to have a realization that behind the things we’re using today there are processors. And just because it doesn’t have a screen and a keyboard, or it’s something that you’re not entering your credit card information into, or your banking, you still need to be thinking about security and protection because of the interconnectivity.

And, again, there are many, many examples—way beyond the couple of simple ones I gave, and much more eloquent ones. But I would suggest that everybody needs to stay aware that, whether it’s you’re working from home, or the fact that you can find a car spot easier in a car parking lot because of some new technology, it’s because things are connected and they’re communicating. And when they’re doing that it’s a convenience, but it’s also a threat platform. And they should recognize that just because, again, it doesn’t have your credit card in it, doesn’t mean that it can’t possess an equal threat. We should all be aware, and hopefully be seeking these solutions to try and stay even—maybe even get ahead of what’s happening in the world of attacks and hacks.

Kenton Williston: Very good. Well, with that, listen, I want to thank you for joining us on the program today. Really appreciate your insights.

Louis Parks: Great. Well, thank you for having us.

Kenton Williston: Absolutely.

And thanks to our listeners for joining us. If you enjoyed listening, please support us by subscribing and rating us on your favorite podcast app.

This has been the IoT Chat podcast. We’ll be back next time with more ideas from industry leaders at the forefront of IoT design.

The preceding transcript is provided to ensure accessibility and is intended to accurately capture an informal conversation. The transcript may contain improper uses of trademarked terms and as such should not be used for any other purposes. For more information, please see the Intel^® trademark information.