Architectural Security for Embedded Control Systems

Authors:  Jan Tobias Mühlberg (@jtmuehlberg), Jo Van Bulck (@jovanbulck), Pieter Maene (@pmaene), Job Noorman, Bart Preneel, Ingrid Verbauwhede, Frank Piessens

Associate editor: Danilo Pianini (@DanySK86)

Security issues in computer systems are pervasive and embedded control systems – from smart home appliances, the Internet of Things, to critical infrastructure in factories or power plants – are no different. This blog post summarises a line of research on architectural support for security features in embedded processors, with the potential to substantially raise the bar for attackers.

Security in Embedded Control Systems

Sensing, actuation and network connectivity are the basic building blocks for smart infrastructure. In a smart building, sensors detect human presence, measure air quality or room temperature, and communicate these measurements to control systems that operate lighting, air conditioning or other appliances. In Industrial Control Systems (ICSs) and smart factories, similar sensing setups may detect delays, production faults or hazardous situations, and determine the need for human intervention. Supply chain optimisations or alerts may be triggered in response. A smart car can detect dangerous objects on the road and raise the attention of the driver while triggering similar alerts in nearby cars. A smart city may combine all these scenarios and accumulate, aggregate and evaluate sensor inputs at an un-preceded scale to optimise traffic flow, air quality, noise, power consumption, and many other parameters with the overall aim to facilitate sustainable use of resources and to increase the quality of life for the city’s inhabitants.

With the continuation of the trend to augment appliances and infrastructure with computerised sensing, actuation and remote connectivity, "smart environments" imply a range of threats to our security and privacy, and ultimately to our safety. The key amplifier for these threats is connectivity. The use of publicly accessible long-range communications – such as the internet or wireless communication technology – where data in transit may be subject to manipulation by adversaries, lead to an extended attack surface and to the exposure of sensing and control systems to attackers.

Of course, smart environments are insecure. Typicall sensing and control networks are even less secure than our personal computers: Many of these systems were not designed with security in mind, just because they were never meant to be connected to a global communications infrastructure and thereby exposed to attacks. A substantial role is played by legacy systems that were developed and deployed in a time when the idea of making these systems "smart" by permanently connecting them to, e.g., supply-chain management, was technically infeasible and not anticipated. Gonzalez et al. argue that two thirds of ICS vulnerability disclosures had an architectural root cause, while about one third of the vulnerabilities were due to coding defects. The problem is pervasive and control systems across critical domains suffer from vulnerabilities resulting in exploits: Since the Stuxnet incident we understand that industrial equipment can be physically damaged through cyber attacks.

At DEF CON 22, Scott Erven and Shawn Merdinger discussed the problem for medical devices and hospital equipment, and in 2017 UK hospitals are amongst the institutions that were hit hard by the WannaCry ransomware attacks against PCs, which encrypted and denied access to critical data until a ransom is paid. In the same year, the NotPetya ransomware ravaged Maersk's world-wide network, taking down harbour infrastructure and shipping routes and caused substantial real-world damage.

Screenshot of the WannaCry ransomware that infected PCs at a global scale in 2017, leaving mission-critical data in institutions such as many British NHS hospitals inaccessible.

With the advent of complex infotainment systems and remote connectivity in automotive vehicles, researchers discovered vulnerabilities that allow attackers to remotely control critical functionality of cars (e.g. Checkoway et al., and Miller and Valasek). And attacks against the Ukrainian power grid, led to pervasive and lasting blackouts during the Russian military intervention around Crimea.

Architectural Threat Mitigations

Our approach to architectural support for security leverages light-weight Trusted Execution Environments (TEEs). Intuitively, we enable the development of secure software by providing hardware extensions that guarantee that a computer will consistently behave in expected ways. Modern Trusted Computing systems provide some form of "enclaved execution" in a TEE, that protects a software, the enclave, from malicious interactions with other software. Ultimately, TEEs relies on cryptography and provides mechanisms to securely manage and use cryptography in distributed software systems. To date, a range of implementations of this idea exist, which are aimed at different application domains. Maene et. al provide a comprehensive overview of the available technology and its capabilities.

Since 2012 we have been working on Sancus, an open-source TEE solution for embedded systems security. The current incarnation, Sancus 2.0, features strong software isolation, efficient built-in cryptography and key management, software attestation, and confidential loading of enclaves. While we can currently not guarantee that our processor design is free of architectural vulnerabilities, we developed Sancus as an open security architecture, for which we can collectively develop a clear understanding of execution semantics and the resulting security implications. We advocate and aim for formal approaches to reason about the security guarantees that these architectures can provide, including the absence of micro-architectural bugs and side-channels. We consider such a principled approach essential in an age where society increasingly relies on interconnected and dependable control systems. Closed commercial products in this domain are certainly responsible for important achievements, e.g., secure virtualisation extensions, TPM co-processors, and enclaved execution environments such as Intel SGX, ARM TrustZone, and AMD SEV. However, we strongly believe, that it is close to impossible for the vendors of these products to comprehensively guarantee the absence of certain classes of critical vulnerabilities in their highly complex products.

Sancus builds upon the openMSP430, an open-source implementation of Texas Instruments’ MSP430 processor core. The MSP430 and openMSP430 are designed for the Internet of Things and embedded control systems: they are relatively inexpensive low-end devices that feature a very low power consumption. Natively, the device provides little security, which is very common for processors in this domain. Sancus guarantees strong isolation of software modules, which we refer to as Protected Modules (PMs), through low-cost hardware extensions. Moreover, Sancus provides the means for remote parties to attest the state of, or communicate with, the isolated software modules. Importantly, our implementation of these security features is designed to be small and configurable: Sancus-secured openMSP430 processor cores can be synthesised for a varying number of PMs. The configuration necessarily affects chip size (in gates) and power consumption. Yet, even the biggest (sensible) configuration will still result in a moderately cheap processor (probably below USD 1 per unit) and less than 6% increase in power consumption in active cycles. The Soteria extension of Sancus even allows for offline software protection in low-end embedded devices.

Authentic Execution

Based on TEE primitives in commodity processors and in Sancus, we have developed approaches that provide strong assurance of the secure execution of distributed applications on shared infrastructures, while relying on a small Trusted Computing Base (TCB). Here, "secure execution" means that application modules are protected against a range of attacks that aim to steal secrets from the application, modify the application or tamper with the application’s control flow (notions of confidentiality can easily be implemented on top of authentic execution). These guarantees hold even in the presence of other applications, malware or an untrusted operating system executing on the same (shared) processor. A cryptographic process called remote attestation guarantees that components of a distributed application are mutually assured of the authenticity and integrity of other components of this application, regardless of whether these components execute on the same processor or on a remote site, or even on systems controlled by third parties such as cloud providers.

We build upon and extend security primitives provided by a TEE to guarantee authenticity and integrity properties of applications, and to secure control of input and output devices used by these applications. More specifically, we can guarantee that if such an application produces an output, then this output can always be explained in terms of the application’s source code and the inputs it received. This is fundamentally different from how these applications were built in the past: traditionally, the security of a distributed application would rely on the security of the hardware and an enormous stack of software, including e.g., operating systems, communication stacks, and system libraries, all of which can be seen as attack surface. Authentic execution on TEEs mitigates this by isolating application components, at least with respect to their security properties, from the overall software stack that is required to operate a device and to facilitate communication. This is what we refer to with our claim of containing functionality in a small TCB: The security properties of an application depend on trusting a substantially reduced volume of software. Ideally, this TCB can be reduced to the processing hardware and the core application software. Experiments (see Noorman et al., Van Bulck et al., Mühlberg et al.) show that we are often able to rely on only 1% to 10% of the software volume to implement critical functionality securely.

Applications and Demonstrators

In "Sancus 2.0: A Low-Cost Security Architecture for IoT Devices" we outline a number of possible applications for Sancus-like technology. In the last years we have built a range of demonstrators and conducted feasibility studies to  illustrate these use cases. We have conducted extensive evaluation of the security and performance aspects of our approach; the prototypes show that Protected Module Architectures (PMAs) together with our programming model form a basis for powerful security architectures for dependable systems in domains such as Industrial Control Systems, the Internet of Things or Wireless Sensor Networks. Amongst our demonstrators are, for example, ideas to implement periodic inspection and trust assessment functionality for legacy IoT applications and proof-of-concept components for a secure smart metering infrastructure.

Demo setup for the VulCAN approach to secure automotive CAN networks. This demo has two dashboards, illustrating the integration of legacy car components in a secure environment. One side of the demo will react to attacks as a conventional, insecure car would do, the other side uses Sancus based software protection and attestation.

The video above shows our most comprehensive demonstrator, a secured vehicular control network. Specifically, we provide a generic design for efficient and standard compliant vehicular message authentication and software component attestation, named VulCAN. This demonstrator is based on the understanding that vehicular control networks, in particular the pervasive (beyond the automotive sector) CAN bus, provide no security mechanisms. Our approach advances the state-of-the-art by not only protecting against network attackers, but also against substantially stronger adversaries capable of arbitrary code execution on participating Electronic Control Units (ECUs). We demonstrate the feasibility and practicality of VulCAN by implementing and evaluating two previously proposed, industry standard-compliant message authentication protocols on top of Sancus. Our results show that strong, hardware-enforced security guarantees can be met with a minimal TCB without violating stringent real-time deadlines under benign conditions.

In our experience, practitioners have difficulties in understanding how enclaved execution can be leveraged, in particular in heterogeneous distributed networks. Over the past six years, our research group has gained significant experience with applications of Sancus and TEEs. To cover gaps in the understanding of these domains amongst software developers "in the wild", we have developed extensive tutorial material that explains how to build secure distributed applications along the lines of the authentic execution idea.

Wrapping Up

Security issues in computer systems are pervasive. So pervasive that media attention, even for attacks that affect millions of users, fades away within a few days. Up till now, most of these attacks have caused little more than financial damage and the compromise of personal data. Yet, recent incidents have shown that with the advent of connected cyber-physical systems, cyber attacks will, to an increasing extent, have physical consequences and can put the population at large at the risk of suffering physical harm, in particular when critical infrastructure is affected. To counter these risks, we must pervasively embrace security in our engineering efforts.

There are technological solutions to provide security for distributed applications such as control systems. In this blog post we summarise our work on open-source TEEs and the Sancus processor, which addresses security in low-end systems. The current incarnation of Sancus, version 2.1, is available on GitHub. We developed a research agenda for security extensions in processors, which leverage open-source concepts for the community to collectively develop a clear understanding of execution semantics and the resulting security implications. Here we envision Sancus to serve as an open-source research vehicle with limited complexity, which allows to address micro-architectural vulnerabilities in processors in a principled and step-by-step way. We argue that without such an understanding, regulatory and legal requirements regarding safety and security, but also privacy-related regulations such as the GDPR are hard to satisfy. Our ongoing research in this field focuses, e.g., on extending Sancus with provably resistant against side-channel attacks such as Nemesis. In a second line of research, we are exploring novel application domains for Trusted Computing technology in the context of distributed mixed-criticality systems with stringent real-time constraints. An up-to-date overview of our research activities and publications is available on the Sancus website.

Importantly, TEEs alone will not solve security: Any secure development process must embrace requirements analysis and threat modelling early to be effective and to advise the choice of appropriate technologies. Moreover, implementing security requires engineers at all levels of a system stack to understand the security implications of their choices of technology, to develop effective communication strategies to inform other levels of their assumptions, requirements and guarantees, and to be ready to adapt to change.

Beyond understanding and using the right technological basis for building secure systems, we believe that there is need for a proactive legislative approach, that combines a careful assessment of state of the art of protective technologies with a gradual increase of liability for software and hardware vendors for security and privacy incidents.