Meeting the Challenge of Multicore

Platform Architecture for the Internet of Things

The Internet of Things is mostly things—things with microprocessors and operating systems. This means many millions of possible security points that need to be guarded against hackers as much or even more than the large server farms.


  • Page 1 of 1
    Bookmark and Share

Article Media

All things must evolve—human anatomy, national constitutions, and religions—to handle the mercurial world around us. History is replete with examples of species gone extinct due to an inability to cope with environmental transformations. In industry, companies like Kodak and BlackBerry famously failed to adapt fast enough to consumer and technology trends.

At the same time, success goes to those who anticipate life’s inevitable challenges, converting foresight into business advantage. The Internet of Things (IoT) promises to be one of the digital age’s megatrends that will make or break many technology companies, depending on their ability to adapt. One of the most obvious challenges is privacy and security. If we think we have security problems with a billion human-controlled smartphones, imagine what awaits us with a trillion autonomous objects gathering untold information about our health, how we drive, how we think. As the brilliant mathematician and inventor Blaise Pascal waxed poetically 350 years ago, “Knowledge is like a sphere, the greater its volume, the larger its contact with the unknown.” The sheer breadth and diversity of IoT information generation, distribution and processing makes it hard for us to conceive all the threats and attack vectors we may face. Platform architecture for the Things in the IoT must adapt to future-proof designs against this challenge.

Internet of Things: Virtualized Architecture

The “Things” of the IoT are embedded systems. The difference between traditional embedded systems and Things is simply that Things are connected to the Internet, either directly or via a gateway. This connectivity brings with it both opportunities for increased functionality as well as increased security risk due to that remote access. The traditional embedded system platform architecture (Figure 1) is simple: embedded operating system, ported to the hardware (e.g., a board support package), and applications that sit above the operating system and use its application programming interface (API) to perform a variety of localized functions, such as interprocess communication (IPC).

Figure 1
Figure 1: Typical embedded system platform architecture.

In contrast, the platform architecture for Things is rapidly evolving into a system that employs virtualization at both the top and bottom of these stacks (Figure 2). At the top, the existence of the Web will drive many device-resident applications to be replaced with remote applications, invoked with remote procedure calls (RPCs) instead of IPCs, using Web APIs, such as RESTful Web services, instead of OS APIs. At the bottom of the stack, the hardware is being virtualized, enabling designers to more easily swap out operating systems or to mix and match multiple operating systems in a single system, utilizing whichever product best fits each subsystem’s requirements.

Figure 2
Figure 2: Virtualized platform architecture: top and bottom.

The inevitability of this platform architecture transformation is predicted by precisely the same transformation that transpired in the preceding digital megatrend, Cloud computing. During the first half of the 2000s decade, Cloud hypervisors (or cloudvisors) like VMware ESX server, Hyper-V and Xen matured, and Intel released its VT technology to help them operate more efficiently. By the end of that decade, every major data center in the world was virtualized. This incredibly rapid architectural change was driven by the massive resource efficiencies and increased fault tolerance and flexibility made possible by computer system virtualization.  

In the world of Things, “Thingvisors” such as the Green Hills Integrity Multivisor, have also matured over the past decade and are now bolstered by similar hardware virtualization capabilities. Recently, for example, they were added to the ARM architecture and are available today in many mobile devices, including the recently announced next generation real-time processor family, ARMv8-R.

Things have very different requirements than Cloud servers. While cloudvisors must virtualize CPU processing, storage and networking resources, Thingvisors must virtualize these plus an incredibly broad range of additional hardware that includes many types of wireless interfaces, sensors, multimedia accelerators and more. In addition, Thingvisors must often handle mixed criticality workloads. For example, in automotive systems, it will not be unusual to see a single system that runs a high-level OS such as Android (e.g., for infotainment) alongside a safety-critical, real-time workload such as a rear-view camera or cluster. 

Thingvisors allow for lightweight workloads to execute directly on the Thingvisor itself (Figure 3), avoiding the overhead of going through two layers of interrupt handling, scheduling and communication that would otherwise be required when hosting applications on a guest operating system. In the automotive realm, a lightweight Thingvisor application can handle the fast-boot and real-time requirements associated with automotive network communication (CAN bus), as well as safety-critical operation such as a rear-view camera, cluster or an advanced driver assistance system (ADAS). At the same time it can host higher-end consumer-grade workloads in a guest operating system such as Android. 

Figure 3
Figure 3: Thingvisor platform architecture.

The Thingvisor can also be thought of as a software root of trust upon which designers can grow an overall robust and secure system. Security-critical components, such as a trusted execution environment (TEE), cryptographic functionality and digital rights management, can be hosted in isolated processes on top of the Thingvisor, isolated from the general-purpose workloads in the system.

Data Protection for the IoT

One of the fallacies in Cloud security is that solutions providers can focus their investment on fortifying the data center—with subterranean bunkers, armed guards, multi-factor access controls, and a multitude of hardware security appliances protecting the network—and essentially ignore the security of the remote endpoints that may connect into the data centers.  This is dangerous thinking in the Cloud era, and is downright folly in the IoT era. Attackers always search for the weakest link, and if Things remain weakly protected, then they will be targeted first.

Once a Thing is commandeered, attackers can use the Thing to gain access to the crown jewels in the data centers. Another aspect of the fallacy is that there is not much information worth protecting out on the edge. Again, this is a questionable attitude in the Cloud era, but incredibly wrong in the IoT era. Things generate a treasure trove of valuable and private information—about our health, our social activities and our location just to name a few examples. As the IoT grows to tens of billions and ultimately trillions of connected objects, the aggregate value generated by Things presents an incredibly valuable target. 

By way of example, in the recent cyber attack against Target Corporation, malware was inserted into the retailer’s Things—the point of sale (PoS) terminals—rather than infiltrating the corporate or payment processing servers. The attackers purloined more than 100 million credit card numbers and personal records. Also recently, security researchers identified a botnet made from smart home appliances, including refrigerators. These Thing-based attacks are the tip of the iceberg; we can expect such attacks to grow at least as fast as the number of Things themselves.

Another simple error often made in Cloud computing is thinking that an HTTPS-connection between access device and the Cloud is enough to protect information traversing the web. As the IoT grows in complexity, it is not practical for developers to know how data will flow across the net and whether the various systems along the way will be worthy of our trust. For example, when you connect your browser to Facebook, the use of SSL may protect information in transit to Facebook’s DMZ (note, however, that the lack of strong mutual authentication in most web transactions makes even this assumption questionable), but what happens to the data once it enters the Facebook cloud?  The data may be sent to advertisers, databases and third-party web services (Figure 4).

Figure 4
Figure 4: HTTPS is not the answer to IoT data protection.

It will not be practical for Thing developers to be assured of the quality of the security controls implemented by all these actors. Therefore, we must adopt a zero-trust strategy, wherein we assume the Cloud is inherently insecure. If our system generates valuable data on the edge, then we must take measures to protect that data, regardless of where it may flow across the Web. For example, a wearable health care device may encrypt information generated locally with a key that is controlled by the device owner and shared out-of-band only with healthcare providers that have a need-to-know.

Preventing the Target Breach with Secure Platform Architecture

The platform architecture principles described above give developers a powerful toolbox with which to build secure IoT systems. To demonstrate, let’s take a look at the Target breach and how it could have been easily prevented. While not all details are currently available regarding how malware was installed into the PoS terminals, we do know that the malware was able to gain full privilege and memory scrape RAM to gather personal information as it was entered into the terminals by shoppers.

An evolved PoS architecture would use a de-privileged operating system and a lightweight security-critical application, called the tokenizer, to handle the processing of personal information. The tokenizer executes directly on the Thingvisor and manages the physical USB device used for card swipe. The tokenizer uses a secure connection to a back-end Web service for mapping personal records to tokenized records and then issues a virtual USB swipe, passing the token to the point-of-sale operating environment. While the main PoS OS may be infiltrated with malware, the malware has no personal information to steal. The mapping of tokenized data occurs in the back-end. The Thingvisor may also include a virtual security appliance, such as unified threat management (UTM) system, that sits between the physical network and a de-privileged virtual network interface exposed to the PoS OS. Such an approach gives Things the ability to incorporate server-class network security capabilities without the size, weight, power and cost associated with traditional data center network security hardware. 

Hardware Root of Trust

It is also important to note that Things require a hardware root of trust, below even the Thingvisor software root of trust. A hardware root of trust, in its simplest embodiment, is a tamper-resistant key storage used, at a minimum, for secure boot of the Thingvisor and associated security-critical components like the tokenizer in the preceding example. The boot sequence must utilize the key to signature check these components before launching them. Subsequently, the hardware root of trust can also be used for remote attestation and for higher assurance protection of keys used for both data-in-transit and data-at-rest protection. If an attacker attempts to overwrite the firmware flash memory with malicious code, the secure boot will detect this and can take corrective action. Once securely launched, the Thingvisor can recursively apply measurement checks to other components, including the guest operating system kernels, if desirable.

The overall Thingvisor-based point-of-sale architecture is shown in Figure 5 with Windows Embedded as the main PoS OS. This has already been developed and demonstrated at the National Retail Federation (NRF) Big Show.

Figure 5
Figure 5: Thingvisor architecture prevents Target breach.

The IoT will enable incredible functionalities and efficiencies that promise to drive new business opportunities for solution providers. But with great power comes great responsibility, and the security and privacy challenges of the IoT demand that developers commit early and often to future-proofing their systems for security. This strategy starts with a platform architecture that utilizes hardware and software roots of trust and proven security principles, such as least privilege, to harden Things and defeat common attack vectors.

Green Hills Software
Santa Barbara, CA
(805) 965-6044