Your browser is not supported. Please update it.

20 July 2020

Trusted execution is critical for IoT security

Amid the wider turmoil over 5G and national security, operators and their customers are more concerned in the immediate future over threats to emerging use cases, especially around the IoT (Internet of Things).

To date, damaging attacks relating to the IoT have tended to involve recruitment of relatively dumb devices such as CCTV security camera in botnets for launching DDOS (Distributed Denial of Service) attacks. However, the attacks that brought down the Ukrainian power grid around Christmas 2015 gave an early, if as yet almost unique, demonstration of the potential threat posed to both national infrastructure and the Industrial IoT (IIoT) from the increased connectivity.

In that case, the attack exploited the connectivity between the grid’s operational systems and the back end data center, which was then a relatively recent development. This allowed the hackers, suspected of being state-sponsored actors from Russia (although that was never proven), a backdoor into the operational systems to crash the grid.

Since that attack, the IoT has proliferated with the number of connected devices increasing about two and a half times globally, from 3.8bn in 2015 to 9.9bn in 2010. More to the point, the scope of IoT platforms has expanded to envelop a growing number of distinct use cases and platforms, to the extent that there is no one size fits all for IoT security, if there ever was.

On the one hand, many of the end devices such as sensors are dumb with virtually no capability for remote updates and as such do not pose an immediate security risk because hackers cannot get at them directly. But the corollary is that many of those devices that do have two-way connectivity lack the processing resources to run sufficiently sophisticated security software.

In the first case of dumb devices, the security threat is simply transposed to an intermediate IoT gateway supporting typically a number of the end clients. In the second case, again a gateway can provide the main line of defence and prevent access to the resource-limited end devices themselves. In some cases though, the end devices will need in-built security, requiring a compromise between risk and cost or size.

Another variable is the scale of deployment. Major national projects involving utilities, public infrastructure, or perhaps some larger smart city deployments, may connect larger numbers of endpoints running well into five figures, serving multiple applications and complex infrastructures. These will call for bespoke development involving experienced systems integrators. On the other hand, smaller projects involving individual campuses or enterprises may be better served by plug-and-play packages comprising pre-certified IoT devices and gateways.

There are also significant differences between infrastructures, with automotive deployments clearly requiring full cellular connectivity over public licensed spectrum supporting roaming, in some cases between countries. But this is not the case for many enterprise and especially IIoT deployments, where there is no need to support even regional roaming. After all, process control systems and industrial robots do not roam about and the demand for wireless connections is more for convenience, safety and flexibility, than mobility.

That has implications for security, because in those more static cases, wireless connectivity can be provided over private spectrum in isolated islands. In fact many, if not the majority, of early IIoT deployments are isolated islands disconnected from any public macro network. Operators can still be involved but would ideally like to be playing a more central role as orchestrators of end to end connectivity, which is why they promote themselves as the ideal providers from a service continuity perspective.

In practice though this argument is not compelling because those devices that do need wider roaming, brought in perhaps by maintenance staff and for testing on a temporary basis, may not be subscribed to that given operator’s network anyway. There are other factors, such as the fact these private networks do not always involve SIMs, using other identifiers instead, which can all be part of a coherent package encompassing security in part through isolation.

This point about isolation suggests a thread connecting almost all of these disparate scenarios, which is the need to protect critical security functions from tampering, intrusion and eavesdropping. This requires logical isolation which in the past was achieved in many cases through dedicated hardware, whether in a TV set top box or some dedicated device. The point is such devices could only be accessed by their service provider, which is a model that has been blown away by internet connectivity and associated functions such as remote software updates and app downloads.

The industry has had to put this particular genie of tamper-resistant dedicated hardware back in the bottle and that has been achieved by the Trusted Execution Environment (TEE), which is an isolated component of a chip or module that is otherwise general purpose and open to external access via the Internet or otherwise.

A TEE then is a secure area within a device’s processor shared by its OS and applications but insulated from them so as to prevent mutual interaction or communication except for delivery of vital credentials such as encryption keys. TEEs then run security-related processes such as decryption of data and other cryptographic operations.

As implemented so far in devices such as modern connected set-top boxes,  smartphones, smart watches  and some IIoT devices, TEEs effectively have their own secure OS running in parallel with, but separated from, the general OS such as Android or Apple iOS. As such, the TEE is capable of running multiple processes and supporting a variety of trusted applications that in turn will want to be separated from each other. Given that these processes are running side by side, such internal separation can only be achieved through software-based cryptographic operations involving keys and so cannot be quite as secure.

It all comes down to trust and those processes inside the TEE have already undergone significant verification. Only trusted applications can run in the TEE, which relies ultimately on a hardware root of trust to distinguish itself from say external software attempting to masquerade as a TEE. The root of trust comprises private keys, known as endorsement keys or provisioned secrets, embedded directly into the chip during manufacture. These have counterparts residing in the manufacturer’s database, alongside a non-secret scrambled version of a public key belonging to the trusted party.

That party is normally the device’s chip vendor, which uses the key to sign trusted firmware alongside those circuits in the TEE handling cryptographic operations and controlling access. The hardware is then designed so as to prevent all software not signed with the trusted party’s key from accessing the privileged features of the TEE.

Increasingly TEEs are embedded either in IoT gateways, or end devices that do have some processing capability. In the latter case especially, the TEE may be a stripped-down version by necessity, not incorporating a full OS but instead software embedded during manufacture. Often these devices cannot take software loaded by end users either directly or over the internet and so do not constitute as great a threat of compromise, but at the same time the security capabilities of their TEEs may be less.

Their success lies in implementation of a coherent chain of command uniting fragmented components, no one of which may be able to trust all the others. Yet the whole chain can be trusted because the links are tied together sufficiently in a line of trust command.

One of the most widely deployed TEEs is Trustonic’ s Kinibi OS, built with a microkernel technique designed to enforce greater isolation by stripping functionality to the bare bones of what is needed for the specified operations. There are two versions, Kinibi and Kinibi-M. The first is widely used to protect higher end application processors, such as the ARM Cortex-A range used in most smartphones and higher end IoT devices. Then Kinibi-M is the low power cheaper version for sensors and other dedicated IoT devices, often using chips from ARM’s Cortex-M range.

This leads to another trend among IoT devices away from physical towards integrated SIMs (iSIMs). Since the SIM itself evolved to provide dedicated hardware based security for phones and other cellular connected devices, the iSIM naturally should run in the TEE. This will involve interaction between chipmakers, IoT device makers and service providers.