Realizing the IoT security imperative -

Realizing the IoT security imperative

It’s true that in the animal kingdom there is safety in numbers. But in the IoT, where billions of devices are expected to be connected within the next decade, the sheer volume of devices isn’t expected to mitigate the security risk. In fact, given that many devices may share the same codebase or hardware design, it will simply increase it.

This is the reality of creating a more connected world; it will become easier to infringe personal space both in the real world and online. To some extent modern society has little choice, it needs that level of connectivity to meet the rising demand for food production, mass transit and energy distribution. Reconciling these two paradigms will be where the emerging IoT meets the established IT infrastructure.

There is much the embedded industry can learn from the enterprise sector, in terms of the technology developed to provide security. Firewalls, authentication, encryption and intrusion detection have all evolved within the enterprise space and perhaps the most important thing to understand is that all of these technologies are intended to work cooperatively. There is no single solution to security in IT; each technology must play its part.

Unfortunately the technology isn’t directly transferable. Putting a firewall in a device intended to communicate with other devices on an ad hoc basis would be difficult, for example (although embedded firewalls do exist). Similarly, intrusion detection may be challenging to implement reliably in resource-constrained devices such as smart sensors and other ‘edge nodes’. However, authentication and encryption are security techniques that most definitely could — and should — be implemented in the embedded domain.

A significant aspect of the IoT security imperative stems from the way disparate devices will participate, by its nature this will involve known and unknown devices joining and leaving networks on a relatively frequent basis. When those networks are considered ‘local’ and comprise only devices in the local area, the security risk is perhaps limited. But in reality a wireless device can join a ‘local’ network from some considerable distance; physical barriers such as locked doors and high walls offer little or no barrier to a wireless signal.

Even wired interfaces represent a threat where physical access is possible and no security measures have (or can be) taken. This could be any kind of serial or parallel port, such as PCI Express, CAN, USB or even (and, as it turns out, quite ubiquitously) JTAG/Boundary Scan.

The problem isn’t necessarily the lack of security in the interface itself, but the lack of security in the devices and data that the interfaces connect to and, by extension, its network. Some work is already being carried out; the introduction of the USB Type C authentication protocol intends to inhibit unauthorized USB Type C chargers and devices from gaining full access to a system. Similar steps should perhaps be taken with other prominent interfaces, particularly those that implement a message-based protocol. While such action wouldn’t help protect the many millions of instances already deployed, it would at least help to protect future devices that are also more likely to be connected to the IoT.

Until all wired and wireless interfaces are protected — and even after — using encryption and authentication can significantly improve overall security in the IoT. The Open Web Application Security Project has identified a number of so-called Attack Surface Areas in the IoT, due mainly to missing or poorly implemented encryption or two-factor authentication.

Many of the microcontrollers that will enable the IoT now provide support for encryption and authentication. ARM has extended its TrustZone technology to Cortex-M cores based on its ARMv8-M architecture, a technology that provides a ‘hardwired firewall’ at the transistor level. This allows trusted software to run completely isolated from untrusted software. Because it is implemented at the hardware level, Cortex-M microcontrollers that employ TrustZone can still deliver real-time operation, making them applicable to many of the IoT applications that need real-time response levels.  When TrustZone is used in conjunction with secure boot and a trusted operating system, it creates what ARM refers to as a Trusted Execution Environment (TEE).

Even with encryption and authentication, devices can still be compromised. An increasingly common form of attack is instigating a system reboot or update, and using that opportunity to install malware. Secure boot is a technology that strives to ensure the firmware in a system cannot be compromised in this way. This may be as simple as inhibiting on-chip Flash from being overwritten, or as extensive as authenticating the firmware at boot time. Some manufacturers now support this with dedicated solutions, such as High Assurance Boot developed by NXP. This is implemented through a software library stored on-chip in ROM, which is used to cryptographically authenticate firmware stored off-chip. It achieves this using a digital signature and the Public Key Infrastructure methodology; the firmware is signed with a private key and verified using a public key. Such approaches are used to establish a ‘root of trust’ between devices.

Creating a root of trust between devices is seen as an effective defense in the IoT. It requires that the two devices authenticate themselves before any sensitive information is exchanged. The type of information that should be considered sensitive would typically be a password for accessing a network. In many cases, an absence of assured trust can be exploited to request and receive passwords in an unencrypted data exchange. Most wireless protocols default to unencrypted exchanges, which is predominantly common in short-range wireless technologies that predate the IoT. More recent protocols, such as Thread, have security and encryption ‘built in’ at their core, while Bluetooth now offers a security mode that enforces encrypted key exchange. Understanding and instigating the security features of a chosen wireless technology is now an essential part of product design.

As billions of devices come online, the attack surface for IT infrastructures increases. As many of the IoT nodes are currently — and may continue to be — designed without full regard for security, the threat this presents is causing referred pain. Without doubt, the responsibility of securing IoT nodes lies with the OEMs developing them and not with those responsible for the security of the infrastructure.

The point at which both these worlds collide will be the gateway, the device responsible for channeling the IoT data and services to the rest of the Internet. As this is essentially an entirely new application space, it is unclear who will secure this space and how. As yet, no single solution or provider has emerged as the ‘de facto’ gateway provider; both the embedded and the enterprise sectors have it in their sights.

But as with all aspects of security, it cannot be fully deferred to ‘someone else’ and even the most secure gateway will still need to have confidence in the security measures put in place throughout the network.

Yannick Chammings has led Witekio as Chief Executive Officer since 2009. He oversees the overall executive, operational, sales, engineering and strategic leadership of the company from the headquarters in Lyon, France. Yannick brings more than 20 years of industry experience, with deep expertise in embedded software and smart object technologies. Prior to Witekio, he developed Adetel's embedded software branch, which became the foundation for Adeneo Embedded. In 2007, he set up the US operations and develop the overall activity before spinning it off and transforming it into Witekio.  Yannick holds a Master in Computer Engineering from INSA-Lyon, France.

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.