Standfirst: The trend towards connecting everything to the Internet presents an increased threat to the IT infrastructure; one they can’t fix themselves. OEMs need to understand the risks and the security measures available to mitigate them.

In simple terms, what really separated the embedded and enterprise sectors in the past wasn’t the type of devices they featured, but the services those devices provided. Not so long ago, deeply embedded devices presented a very small (if any) profile to the wider world, but the IoT will ask those devices to increase that presence, by becoming an active part of the Network and contributing to it in more ways than simply providing data. Rather than just connecting disparate devices together, the Internet of Things (IoT) is about extending the reach of the IT infrastructure.

With that increased profile comes a security threat; if things are easier to detect on a network they will naturally become a target. For OEMs unfamiliar with the kind of security measures routinely found in the IT infrastructure, that may present new challenges. Adding IT-like security to IoT devices isn’t simple, but it is becoming more relevant and more important with every new device that gets connected.

Where to start?

An obvious place to start is, perhaps, the technology that will actually connect the devices. Communication interfaces, both wired and wireless, can be an open door (or window) to the criminal element, but they invariably come with a level of protection that should be exercised. Who hasn’t heard accounts of Wi-Fi networks being accessed because the password hadn’t been changed from the manufacturer’s default? It may seem obvious, but it can also be easily overlooked.

Access to a WPAN can extend beyond the physical boundaries in place.

Wireless interfaces continue to displace wired alternatives thanks to their convenience. However, that convenience shouldn’t extend to making the network open to all devices within range, yet if the security features aren’t applied appropriately the result is just that; an unsecured network (Figure 1). This is true for many wireless protocols but is perhaps more apparent in the IoT due to the widespread use of Personal Area Networks (WPANs). Since their inception, WPANs have suffered from security issues, possibly because the close proximity of the devices implies a secure environment. In fact, the reach of WPANs means anyone in the immediate vicinity, such as a public area or even the building next door, could access a network through an unsecured device.

A good example is Bluetooth; the specification implements four security modes, but any device operating in Mode 1 is not considered to be secure at all, as it doesn’t implement any authentication or encryption. Mode 4, on the other hand, is an enforced security mode which uses encrypted key exchange. OEMs should also be aware that paired devices can be either Trusted or Untrusted with respect to accessing the host’s services. Trusted devices have full, unrestricted access to all services, while untrusted devices could require further authentication. Applying the right security modes and trust levels will help ensure a more secure network.

For headless devices (those without a screen or keyboard), passwords may need to be exchanged wirelessly. Failure to apply encryption to these exchanges, even within an otherwise secure network, could represent a security threat.

Setting an indecipherable password is good practice for managing access to a network, but if the device accessing that network has no screen, keyboard or user interface with which to enter the password, it needs to be shared securely. It is possible (but not advisable) to share passwords and keys over an established connection without any encryption. This has been demonstrated by various ‘unplugged’ events in the WPAN arena (Figure 2).

The so-called Man in the Middle attack takes advantage of this, once access to a network is established, patterns on the network traffic can be analysed to identify regular exchanges. If these are sent unencrypted it is relatively simple to replace them with instructions that could, for example, initiate an over-the-air update and thereby take control of a device or its services.

Let’s get physical

It should be noted that securing a wireless interface doesn’t guarantee security if a physical attack is still possible. Many wired buses, such as CAN, are prone to attack if physical access is available and no security measures have been taken. Some serial interfaces, such as USB Type C, now offer security features such as cryptographic based authentication. Many more, older, protocols will not have considered security when conceived, such ‘legacy’ protocols are still widely used in embedded devices and for those that aren’t connected to a larger network they may present little or no security threat. But the trends towards total connectivity could even make legacy devices a weak link.

One major threat from unauthorised access to a system comes in the form of a software update, introducing functions that simply shouldn’t be present. These could be subtle changes, such as pushing data out over a CAN bus, making them difficult to detect. The answer is to protect the system from unauthorised software updates.

One way of doing this is to make the memory where the application code is stored write-protected during the production phase. Many modern MCUs offer this in the form of write-protect fuses for the on-chip Flash memory. Once the Flash has been programmed and the fuses blown, the on-chip Flash can no longer be (re)programmed. Of course, this also makes in-service upgrades impossible, so should be used with care.

For systems based on MCUs using off-chip memory, the solution may be to use some form of secure boot technology. NXP offers one such solution, called High Assurance Boot, or HAB. This is a software library executed from ROM (so it can’t be modified) at boot time. This then uses a digital signature to authenticate the code stored in Flash. It uses cryptography based on the Public Key Infrastructure (PKI), which involves signing the firmware using a private key during production and verifying it using a public key at runtime. Successful verification at boot time establishes a root of trust.

Hardware to the rescue?

Many MCU manufacturers, and IP providers such as ARM, now offer hardware-based security features that support and accelerate encryption and authentication. For example, the ARMv8-M architecture offers ARM’s TrustZone technology for manufacturers of ARM Cortex-M based microcontrollers. This has the effect of separating a system in to two distinct areas; a trusted zone and an untrusted zone. When this is used in conjunction with a secure operating system and secure boot technology it creates what ARM calls a Trusted Execution Environment. Some licensees have taken this a step further by adding their own security hardware features, so adding security to even the smallest and lowest power IoT nodes should now be possible.

Conclusion

The Internet of Things will increase the footprint of the enterprise infrastructure and that’s really where the threat lies. It won’t be enough to rely on the Internet’s ‘backbone’ to keep edge nodes secure from attack.

The volumes involved with the IoT are staggering, so getting it right will be challenging. But taking the right steps, such as adopting encryption and authentication, will help make the task more manageable.