Protecting Firmware is Crucial for IoT Technology

As computers grow more ubiquitous (linking household appliances to phones to cars in a vast, nebulous "Internet of Things"), new secrity challenges have emerged. Chief among them is how best to protect our firmware, the software that boots our computers. In recent years, firmware attacks have become increasingly more common, sophisticated and lucrative.

Motherboard spoke with Brian Richardson, a senior technical marketing engineer, Intel® Software Evangelist, and expert in firmware, about computer safety in the dawning era of the Internet of Everything.

MOTHERBOARD: Can you tell me a bit about what firmware is and why it's important?

RICHARDSON: Firmware is the software that makes sure the platform boots properly. It's a very short part of the life cycle, but it's extremely critical in making sure you're handing off to the operating system you're supposed to. It's what we refer to as the "software stack"—firmware is the bottom.

It's an area we're concerned about because as operating systems become more secure they get harder to attack. Firmware has since become a more attractive target.

We've spent a lot of effort over the past decade standardizing how firmware works so all the OS vendors have a more consistent experience. But now that it's standardized, there's one central resource where you can go to read about how it works. There's more cross-compatibility, which an attacker will take as a chance to find a consistent way to attack a large number of platforms.

M: So if a hacker messes with your firmware, the damage would be done before you would have a chance to click on anything to fix it?

R: Let's say I got on the internet without proper virus protection and my laptop gets infected with something terrible. If I backed up all my data magically in the cloud, I can say, "You know what? Forget it, I'm going to a wipe this thing and install everything from the start," and I knock everything off the hard drive. I've done away with that attack; it was installed in the OS.

But if that attack injected an item into the firmware, wiping out the hard drive wouldn't remove the presence of the attack. It would still be part of that lower end of the software stack. It's what they refer to as a "persistent attack."

There was an incident recently where a California hospital had ransomware installed on one of their computers, which essentially encrypted the hard drive. So they had to pay the attacker to un-encrypt it so they could retrieve the data. This attack wasn't persistent. They could have just formatted the drive and restored from backup and the ransomware would have gone away.

M: Now we have all kinds of tiny sensors and computers that don't rely on user interaction as much as, say, a laptop. How does this complicate things?

R: If I have my standard laptop and I go to the wrong website and download something I'm not supposed to, there are all kinds of user indications that maybe I shouldn't click on that. Maybe that person really isn't blond and Russian and wants to talk to me. There's a higher degree of user interactivity that we can use as a part of a security measure.

In a connected device that isn't monitored as heavily, there are more chances for somebody to just randomly slip firmware on your platform.

This has become a pretty common demonstration at security conventions. Someone will take a consumer electronic device like a "smart" television and demonstrate how to inject code into it. This is why you have people concerned about "smart" thermostats and the cameras that they're using as baby monitors: someone was able to inject software because they found some kind of bug in the OS or firmware stack.

So the issue we're looking at from an Intel standpoint is that once you have a fleet of these connected, "edge" devices on the IoT, how can you manage their software content, and securely update in a way where you are sure it will only use the signed version of the firmware you provide, not the hobbyist version someone baked up in their garage? How can we maintain what we refer to as a "root of trust"?

M: Ok, so what might that solution look like?

If we had this interview 5 years ago, we'd be talking about the management of firmware updates in industrial computing. Ten years ago, we'd be talking about updates in embedded computing. We've already solved a lot of these problems on a smaller scale for customers that are running more traditional embedded-style computing, like robotics companies.

But those devices are much bigger. And they aren't as exposed to the consumer process. Once you get into the land of "smart" thermostats and "smart" watches—small, more consumer-oriented devices—then you have a larger management issue to deal with. You're taking your updates out onto the public internet, as opposed to a private network. In most consumer settings, that edge device has some way of connecting back to the main corporate site or cloud service the manufacturer operates. It's a one-to-one relationship between that device and the corporation that manages it.

Now if I'm doing a factory setting, I may not actually want to connect that back out to the greater world. Say I'm a factory manager that just deployed 100,000 sensors in my factory. I now have to update 100,000 devices. Do I want 100,000 devices inside my factory randomly going out and talking to the greater internet? That sounds scary if I'm the guy in charge of IT at the company.

I would rather those devices go back to a central point, a gateway device. That's a bridge between the full internet and my internal network. It's the thing that says, "I have this firmware update, but it's not signed. That's weird. I'm going to throw that out."

That gateway device means that I download this firmware update once and then internally manage its distribution across all my devices. It's more efficient that way, so you don't have all these devices repeat their request for the identical image. But it's also a buffer, so that more complex security settings will be pushed on the gateway, which would have more computing power than the individual small devices around the factory.

M: Installing and managing hundreds or thousands of different types of sensors in a factory or home sounds really complicated. How do you ensure everything works together?

From a firmware standpoint, we try to provide the best examples of the product: We provide reference firmware, open source examples, and do a certain amount of enabling in remote specifications that gives everybody a standard base of operations. You'll have a standard mechanism that we can help promote and validate.

It's a toolbox to work from. They get to determine which features get plugged in, which one of our chips to use. If I ship a Galileo board, a tablet, or a server, a high percentage of that firmware stack is the same across all the devices. They're all compatible. It's the same basic operating system—just small differences in functionality and system scale.

The idea is that we have enough components and tools already built—like the things you find on the Intel Developer Zone—that someone can build a generic application for Linux or for one of the newer IoT-specific operating systems. The work has already been done in those operating systems so that they scale across different platforms. Easy to take an app you've written for Linux and move it all the way from a server down to a small headless unit that's connected to a network somewhere.

The way Intel works is we assume our customers are better at their jobs than we are. We don't necessarily know what our customers are going to do with our products that are going to be cool or innovative. We have ideas and suggestions, but at the end of day, these device makers have a particular problem to solve with our products.

To learn more about Intel® Software Evangelists, please visit evangelists.intel.com.