Security is often the last thing developers want to think about when developing IoT-based systems. Ideally, they’d like to add connectivity to existing systems and be done with it. However, there are many issues in shoehorning security into designs, and these are only more challenging when devices are resource-constrained.

I talked with Derek Atkins, CTO at SecureRF, about how to secure IoT-based devices and systems. Specifically, he shared his insights on the difference between large systems and resource-constrained devices. A cellphone, with its operating system integrated with many security features, for example, is a supercomputer compared to an IoT-based sensor. The cellphone has an operating system with many security features. It also has a wide bus, high performance processor, plenty of storage, and relative infinite power, when compared to a battery-operated device that may have to run for up to 10 years on a single charge.

Begin at the Beginning

According to Atkins, the key to developing effective IoT security is to first consider a) who might want to compromise your system, b) what they might gain, and c) what you need to secure. By understanding how your system can be used – and consequently misused – you can assess what someone could do if they had full access to your device.

A threat model brings together all of the ways your system can be compromised. Spending time upfront creating this model is essential because you cannot develop robust security if you don’t know what you are securing against. Especially important is looking at ways a device can be used that you hadn’t considered.

For example, Wired ran an article in 2015 on hacking a car while it was being driven. The hacker got in through the infotainment system. Hackers modifying the system’s firmware gained access to the CAN bus that controlled the car. Among the many lessons to be learned here is that even devices that are not mission-critical may be connected to systems that are.

Security can be simplified by thinking about protecting data-at-rest, data-in-motion, and data-in-action. The most important data-at-rest that a system must protect is its firmware. Ideally, this requires a “secure boot” mechanism and a full cryptographic signature that can be used to verify the integrity of the firmware. Firmware can be divided into multiple sections, one of which is a trusted boot loader. This boot loader is loaded first and validates the main system code. If the code is not valid, the system reverts to a previous good version, moves to safe mode, or shuts itself down, as appropriate to the application. At the highest level of security, a system will regularly confirm that the software it is running has not been run-time modified.

To protect data-in-motion, a secure communications channel is required. This could be a wireless link or a system bus that interconnects multiple devices or systems. Secure communication can include authentication (you know who sent it), confidentially (you know only the intended receiver can read it), and integrity (you know the data have not been changed in transit).

Protecting data-in-action refers to understanding how someone may attempt to compromise a system. Consider a door access system that wirelessly unlocks a door when the correct code is entered. In case someone captures an “open” command, the door should not open if that same command is replayed later.

Note that security needs to go beyond software to physical considerations. Not every visitor to a factory can be trusted. You also have to make sure that someone can’t remove a plastic cover and access wires that control the system.

The Cost of IoT-based Security

Many OEMs are wary of the cost of implementing security. In general, security has been developed for large systems. The algorithms are optimized for wide busses, lots of storage, and expansive instruction sets. The fear some OEMs express is that these algorithms will not only increase cost but slow the system down, making them infeasible to use.

And often this is true. However, there are a growing number of security development tools available designed specifically for resource-constrained systems. Rather than try to squeeze down security for a large system, these algorithms are designed for the capabilities of even 8-bit MCUs. This has a tremendous effect on efficiency in terms of processing, storage, and power resources required. There is still a cost, but it is much lower.

There are also many ways to minimize the cost of security. Often, security is not part of the regular operation of the system. Many embedded MCUs offer hardware acceleration for security. If you aren’t sending a lot of data, you may not need to rekey as often given that key vulnerability is more a matter of the amount of data sent and less the time the key has been in use.

From a comprehensive threat model, you can create a threat matrix. This matrix maps threats to the cost of a breach as well as to the cost to prevent a breach. Atkins recommends using a threat matrix to evaluate what types of security to implement. Some functions need more protection than others. For example, the intercom feature of a door access system may not need to verify integrity while the door actuator function definitely will. This approach also makes it easier to estimate the actual power consumption of the security subsystem over time.

Avoid security algorithms based on “secret” (e.g., unpublished) methods. If these methods are ever exposed– remember how DVDs were once secure – the system based on them is at risk. Published algorithms have the advantage of many eyes analyzing them for vulnerability.

There may be a temptation to develop a cryptographic algorithm of your own. In short, if you aren’t an expert, this is likely a bad plan. As the saying goes, it’s easy to design a secure algorithm you can’t break yourself.

Certainly, IoT-based security technology has room for growth. But much is already being done natively, not just ported from larger systems. There’s no need to reinvent the cryptographic wheel, so to speak. Learn from what others have done before you.

After all, you wouldn’t write your own USB stack, would you?