IoT security best practices: Questions to ask yourself before your next design

In this interview with Phil Attfield, CEO of Sequitur Labs, the security expert affirms that Internet of Things (IoT) security vulnerabilities are for real, reveals what software developers are overlooking in the hardware security toolbox, and provides best practices and examples that can benefit every level of an IoT organization.

There’s been a lot of publicity around security. How much of that is practical?

ATTFIELD: Turn the clock back 20 years when people first started connecting printers on networks. What were some of the early hacks on printers? Well, for one, they had spooling hard drives that had interesting information on them, but also, if I got into your printer I could get into your human resources server or your payment system. So it’s a similar problem, only now you can do it through a light bulb. Any device on the network is potentially a target itself, or it’s a vector to other devices.

Step forward in terms of what the compromise of the individual device means. A light bulb? Maybe not terrible. Automotive? That could have really serious repercussions, and if there’s a lack of separation, that’s a really big problem.

The other one is what it means in terms of loss of control of the device itself or system that’s attached to it. If you can make a pump spin faster, what does that mean in an irrigation system? If you can burn one out or cause a sensor to not behave, what does that mean in terms of a system failure?

Another that was never addressed in the desktop world is piracy, or outright IP theft. If you have the ability to design a device and you’re going to make millions and millions and millions of these things, there’s value in the IP and firmware. From the standpoint of the company that manufactures it, how do you protect that or update it in a safe manner so it can’t be taken over?

It’s very real, but the good news is that the enterprises that are not newcomers to the world of embedded are the early adopters and already understand a lot of this. They’re jumping on it quickly because they know they’re staring down the barrel of this.

Given the reality of the threats, what do you see as the biggest roadblock for IoT security right now?

ATTFIELD: If we look at code integrity and the practices there, a lot of the RTOSs don’t even make use of existing security features that are available on devices. For example, a memory protection unit gives the ability to provide separation if you know how to code and use the thing, but most RTOSs don’t make use of it. There really is not a terrible performance hit in chipset or design to do real-time operations. They’re very well categorized, they’re deterministic in terms of their behavior, so it’s not as if they’re spending microseconds wasting time.

Part of it is developer laziness; part of it is also product laziness. If somebody wants to get to market quickly, then a developer needs to understand annotation of their software when they write it. Also, I’d say there is a lack of tooling and methodology for them to realize they need to do this, it actually matters, and it starts to protect resources.

The thing that’s going to be a big differentiator is how easy it’s going to be for a developer to use that functionality. It can’t be buried in the mystery of white papers and the mystique of data sheets. It’s got to be exposed in a reasonable manner, because people will never figure this stuff out because they’ve got to get the job done.

Given this lack of transparency, can you provide any development or organization best practices around IoT security?

ATTFIELD: It’s not an art, it’s a science. You have to step back and look at what the functions are that you care about, and for C-level executives, that steps back to risk. What does the loss of control or loss of manageability mean? What’s the nature of the system that this is a part of? Is it life saving? Is it healthcare or automotive? Is it a light bulb you don’t care about?

From a developer perspective, think early in terms of code layout and resource use. Because we work with some of the ARM A class hardware, we start from the perspective of the functions you want to perform, and what you want to be trustworthy. Running a trusted OS, whether it’s in a hypervisor or a trusted execution environment (TEE) where you have hardware virtualization, what is the separation and what are the peripherals that need to be isolated? What types of controls need to be on those for regular applications? Should they have any access, or be severely limited? What APIs need to be exposed?

It’s like a software architecture, except the difference is you’re not just passing parameters, you’re also passing a trusted boundary. It’s another abstraction, so when we write trusted services it looks like a function call. It’s just happening in a different place.

I’ll give you an example. On a whole pile of handsets there is a TEE and trusted applications are populated on those. Something that’s pretty darn cool that’s not so easy to do on a PC is a trusted user interface. Say you’re interacting with your Android handset. All of the drivers for the digitizer, the LCD, all of that are within Android itself. If you wanted to do something like a PIN capture, it’s not really so safe because if the device is rooted or there’s a compromise within Android itself, it can gain access to the driver stack and it can intercept your key presses. That can be automated from the standpoint of injecting software in a place you can get at it. You just need to breakthrough and root the device, and you’re there.

Think now in terms of PIN capture for bank transactions. Step over into the trusted OS, and change the security property of the underlying hardware. The digitizer now becomes secured, its driver is in the trusted OS. The display now becomes secure through the LCD controller and its driver is in the trusted OS. Say the banking server authorizes this transaction, and the normal world gets handed this encrypted blob you can’t do anything with. The keys, the certificates to open that transaction up, to bring up the trusted interface, to capture the pin, to sign the transaction, encrypt it, and send it back, think of those happening as one single operation inside the trusted OS. You can actually program that. When the trusted function is completed, it hands back the blob that was signed and encrypted and fires it back on its merry way to the backend processor to complete the transaction. If you try to fish my PIN, you can’t get it because you can’t interfere with the device driver. It’s basically protected by a hardware firewall. That’s a big step forward. This start making differences when you look at building system management interfaces.

For somebody who is developing a system, think in terms of separation of function. So if I have the requirement to store information or store credentials, do I want to store that on the same flash chip or area as I store the kitchen sink? And should the software that gets at that all be in the same place? This may mean it makes sense to use an external device for the time being because that’s as good as it gets for today. It may mean looking at a processor that has some sort of split architecture, multiple cores, or offers some additional features. What’s the lifecycle of the part? For a lot of consumer products it’s a couple of years, then you throw it out and get a new one. In a lot of devices, it’s ten years. When you look at the evolution of the threat landscape over the course of ten years, what does that mean? If two years from now some genius comes up with the AES-256 cracking algorithm, a lot of products are really up the creek.

There’s a term “crypto agility,” where maybe you don’t want hardwired crypto on the device, but you want some set of math primitives that let the ciphers be built quickly and efficiently. Things aren’t necessarily soldered or baked in, but the basic building blocks to work with are present. So if 256-bit encryption is broken, when you change this bit around or use the algorithm this way, then it works. It means that your part doesn’t have to be pulled from the field, you could do an over-the-air update and remedy that.

Where is investment required for IoT security?

ATTFIELD: The first place I would say is education and training. I’m not Chicken Little. I’m not saying “The sky is falling!” We’ve seen systems compromised. Education is the first step. The second is then trying to remove some of the skepticism and putting it into real dollar terms or the impact of that or a business or ethical level in terms of what are the side effects.

Sequitur Labs