How to protect #IoT devices from software attacks!

#IoT devices are supposed to function properly in the field for many years without human intervention. Given that we know in advance that each #IoT node is going to be hacked in the future, it is essential that some trusted code be isolated from that hack to restore the #IoT application code to a known good state.

The debate continues regarding the best method for that software isolation. Before I add one more argument into that debate let me describe a bit where software isolation fits within the other set of technologies required to create that secure #IoT device.

When looking at #IoT device security from the point of view of the attacks we are trying to protect against we see four key ones:

Communication attacks
#IoT is connectivity. The #IoT device will be sending messages back and forth to a server. An attacker will try to use multiple means to intercept those messages. To protect against those attacks, all data traffic is usually encrypted and authenticated.

Life cycle attacks
A device changes hands many times as it goes from the designer to the factory and then to the field. We need to somehow protect the integrity of the device as it goes through this life cycle.

For example, a known common attack is to force a downgrade of the code of a device to a version that had a fault in order to extract the data. To protect against such an attack, people use a protected code upgrade counter to make sure only the latest code is used.

Physical attacks
If the data inside the device is extremely valuable then attackers may resort to physical means to extract that data.

For example, one could remove the plastic cover of the the device and insert probes into the circuit to extract the information or expose the device to extreme electric conditions to force faults that expose the data.

Software attacks
This is the most common attack where someone finds a way in the existing code to get access to restricted resources. It could be due to a software bug or to an unexpected sequence of function calls.

There are a few very good articles, like this one, that describe a security framework for building secure #IoT devices covering all the items mentioned above.

What’s the Difference Between Device Hardening and Security Appliances?

Usually, these articles do not dive into the details of how to implement software isolation to protect against software attacks. Since this is the centre of the ongoing debate please allow me to shed some light on that subject.

I propose that there are three main methods to implement isolation. Each method is better adapted to certain verticals and cost points. Actually, there is no reason what so ever to have a debate on which one is best as one size does not fit all in #IoT.

Starting from the diagram above:

Two distinct processors
What better way to create two isolated execution environments than having two processors? This is a straight froward approach. Each processor has a private memory to execute from. A mailbox interface is used to exchange requests and messages. There is some additional cost due to replication of hardware but in some verticals this is not a blocking item for mass deployment. Besides, sometimes having two processors is better for low power designs at the system level.

Memory protection unit (MPU)
Usually, in embedded designs, the kernel and interrupt handling routines run in privileged mode and have access to all resources in the system. Before a task is scheduled to execute, the kernel will setup the memory protection unit to limit which addresses of memory and I/O that task will be allowed to read or write. In this case, only one processor is used and the MPU is used extensively to control access on a per task basis. Keep in mind that interrupts destined for the #IoT application need to be virtualised otherwise a hacker can use them to gain privilege to configure the MPU to gain full access.

TrustZone for Armv8-M
With TrustZone for Armv8-M, the address space of one processor is split into two parts, one for the trusted firmware and the other for the #IoT application. The trusted part cannot be arbitrarily accessed by the application side due to this split. Isolation in TrustZone for Armv8-M is implemented in hardware by the processor thus removing the need for a run-time software layer that configures the MPU at each task switch. TrustZone for Armv8-M also reduces the number of function or API calls required to make a call from non-trusted firmware to trusted firmware. Since each side has a different set of dedicated interrupt lines then there is no need to virtualise interrupts. Removing software layers reduces instruction fetches from flash memory which is a major source of power consumption in an embedded solution. Most of all, TrustZone for Armv8-M brings a common scheme for the ecosystem to rally around which is good for the industry. Software written for TrustZone will run on any such device.

Don’t debate, deploy
A bit bold to claim but without some sort of isolation, there will be no secure long term #IoT. All isolation methods are good to use. Some maybe more suited to specific verticals than others depending on the application. It is all within the security framework that you apply. So, please, do not debate the merits of any solution, just deploy devices. A few million devices here and there will quickly add up to a trillion!

I am very interested to see your feedback on what frameworks and security validation/certification are getting traction these days.

Please share your choices with all of us…