How a Software Isolation Solution Protects IoT Devices

March 1, 2018

Yann Loisel Stephane Di Vito Emmanuel Puerto By: Yann Loisel, Stephane Di Vito, and Emmanuel Puerto
Embedded Security, Maxim Integrated


When it comes to security, internet of things (IoT) devices share some commonalities: there must be security in the way that the communications flows, in how the assets are stored and processed, and in the integration of the device. In this blog post, we’ll make the case of how a software isolation solution can protect IoT devices. But first, let’s consider all of the components of an IoT device: the architecture, communications, integration, and assets.

Architecture

While connected objects can handle a variety of functions, they still must do so within the confines of the smallest, cheapest, and simplest embedded system design. For cybercriminals, unfortunately, all of the assets handled by IoT devices are a treasure trove and the devices’ communication interfaces are their entryway into these assets. Often, their access is facilitated by a permissive integration and design.

Communications

An IoT device represents a link in the chain from data acquisition to data exploitation, or between the command control and the operation. It must have a communication interface in order to exchange data, or update its firmware and services. This is why an IoT device must always be, wired or wirelessly, linked to a network.

Integration

Once a connected device has been deployed in the field, how can a designer ensure that it will have as long a lifetime as possible? The best way to achieve this is to improve and add features and to add applications. This means that the same platform and the same microcontroller must host several different applications, which must coexist and concurrently execute to address the device features.

Considering multiple applications implicitly leads to a rich OS, with memory isolation mechanisms. The consequence is that only high-end CPUs (e.g. based on an Arm® Cortex®-A core) with large memories (RAM, flash) achieve these requirements. This appears to strongly contradict some key goals for the IoT: "smallest, cheapest, simplest."

Assets

IoT devices handle all sorts of assets, including sensitive and valuable data. Whether it acquires, modifies, sends, or stores the data, in the end it exposes this information, which adds another level of security need.

Example Case

As an example, let’s consider an embedded device, attached to a computer, that reads and handles fingerprints. It communicates in a bidirectional mode using a wireless channel (Bluetooth, Li-fi) to host the fingerprint minutiae verification information and a secret key and to run applications. This device is used primarily to control users’ access to a highly valuable service located on a remote server, accessible via a client computer.

This is the two-factor authentication method. When a user requests access to the service, a random number (a challenge) is generated and sent by the server to the embedded device via the computer. Then, if and only if the owner fingerprint matches the stored minutiae, the challenge is cryptographically linked (encrypted or signed) with the secret key, and finally sent back to the remote server for authentication.

To increase the lifetime of this device, the designer can integrate new applications, such as those that deliver additional access controls, for example. Because this type of device is generally constrained by price and form factor, the choice of the microcontroller running the device leans in favor of the smallest embedded memories and the simplest architectures. There a good chance that the device’s software will adopt a “flat model” where all applications share the same privileges and resources. In a flat architecture model, any weakness or failure in any application can impact all of the other applications and, therefore, how the entire device functions. This type of device is a prime candidate for a software isolation solution such as Maxim’s DeepCover® Security Framework (DSF).

The DSF software isolation solution provides a high level of security for large embedded applications, guaranteeing a very strong isolation between the software "boxes" running on Cortex-M-based microcontrollers. At its core, this solution relies on a hypervisor that enforces a strict software architecture configuration at any time. This configuration defines boxes, the boxes’ resources, and the boxes’ interactions. Different applications, each with their own defined set of privileges and resources, run in separate boxes. Applications may interact with each other through gateways. Everything described in the configuration is guaranteed by the hypervisor that guarantees that the boxes’ execution matches the configuration. Any difference with the intended configuration is immediately detected, such as access out of allowed memory ranges, attempts to interact with another box out of an allowed gateway, or direct access to disallowed resources. The hypervisor manages and controls other boxes’ resources and execution, while keeping its own ones for its execution.

Problems Stay in Their Own Boxes

Going back to our example, we see that DSF allows a simple but efficient architecture design that consists of the exclusive allocation of a specific box for the management of the biometric characteristics, including access to the fingerprint sensor and the extraction of the fingerprint minutiae. By preventing access to this sensor from other boxes, and thanks to the hypervisor’s control over this access, any fraudulent or unwanted attempt to read the sensor is detected and an exception is raised, leading to a safe failure. Using the same model, other boxes can be defined and developed with a focus on their very specific functional objective, after a careful study of their needs in term of resources and peripherals. With this approach, you can host multiple applications from multiple providers with different levels of confidence and robustness on a single device. Applications can be updated easily and securely. And since one box execution doesn’t hamper another box execution, any certification granted to one box is not impacted by another box modification: the certification remains valid.

independent, isolated images maintain their own properties

With software isolation, independent, isolated images maintain their own properties…and bugs.