In contrast, even entry-level cars now incorporate at least a dozen microprocessors; higher-end cars have more than a hundred. Figure 1 shows some examples of the embedded computers in a modern car. With infotainment systems running sophisticated operating systems such as Microsoft Windows and various versions of Linux, the total embedded software content can easily exceed 100 million lines of code.
Complexity is driven by the relentless demand for enhanced performance, the digitization of manual and mechanical functions, and the interconnectedness of today's world. While this growth in electronic content has been beneficial to society, it has also been a key factor in our concerns regarding reliability, safety, cost, and time to market. The architecture of next-generation infotainment systems must help developers manage this complexity.
Consolidation of Electronics in the Automobile
Another important trend in the automotive industry is the consolidation of the engine control unit (ECU). As the automobile continues to transform into a system of electronic systems, the number of electronic components increases, hence the dramatic increase in the amount of associated wiring harnesses. This growth in electronics presents a major challenge for automakers in terms of production costs, sizing, and time to market. The solution lies in reversing this upward trend and instead combining disparate functions into fewer electronic components.
Processor consolidation is closely linked to the trend toward mixed-criticality systems, in which components critical to protection, safety, or real-time operation must coexist with less critical components. For example, combining the main infotainment unit with the safety-critical real-time rearview camera and/or the driver information panel components results in a mixed-criticality system, as shown in Figure 2.
The architecture of a next-generation infotainment system must ensure that components do not interact in unforeseen ways, which would call into question the reliability of critical systems.
Automotive Electronics Security:
In 2010, researchers from two universities studying security in modern cars disabled the engine and brakes of a moving vehicle by hacking into the on-board diagnostic port. This serves as a sobering example of the formidable challenges ahead in ensuring automotive security, including pre-existing components not designed for safety and a supply chain that has likely reached its scalability limits.
Also in 2010, US automakers introduced a feature allowing car owners to control the locks and start the engine remotely from anywhere in the world using a smartphone. This connectivity relies on the car's remote telematics system, which is standard equipment on many models.
Connecting the car to wide area networks (WANs) is the factor that poses the threat of sophisticated attacks. A single failure could allow a remote attack to damage an entire fleet of vehicles. These communications include those from the car to a service center or other OEM infrastructure, from the car to a multimedia provider, from car to car, from car to the electrical grid (electric vehicles), from car to smartphone, or even from car to a bank. Figure 3 provides some examples of long-distance radio connections in next-generation vehicles.
Unlike high-end data centers, cars are not expected to incorporate a full suite of IDS, IPS, firewalls, and UTMs. Regardless, recent intrusions at Sony, Citigroup, Amazon, Google, and RSA clearly demonstrate that these defense mechanisms are incapable of withstanding sophisticated attacks.
When the Stuxnet attack came to light in 2010, the Director of the U.S. Department of Defense Cyber Command, General Keith Alexander, suggested that critical U.S. infrastructure should be isolated on its own secure network, separate from the internet. While this may seem like a radical solution, it is precisely the necessary approach. Critical car systems must be tightly isolated from non-critical ECUs and networks to ensure their secure operation.
While physical network isolation is desirable, some points of contact will inevitably exist. For example, in some markets, a car's navigation system must be disconnected while the car is in motion, which involves communication between systems of very different security criticality. These connections increase the risk of software-related threats such as privilege levels due to operating system vulnerabilities, sideways attacks on cryptography, or service failures.
The architecture of a next-generation infotainment system must overcome these significant emerging security threats from the outset. Interactions between critical and non-critical systems and networks must be justified at the highest management levels, with rigorous real-time monitoring and vulnerability-free analysis and certification with the highest levels of assurance.
Solution: Secure Environments.
Open-source operating systems like MeeGo or Ubuntu are well-suited due to their compliance with major multimedia standards and the availability of third-party applications. However, we cannot rely solely on the multimedia operating system to control all aspects of next-generation combined infotainment systems. General-purpose operating systems cannot boot quickly enough, cannot guarantee real-time response for protocols like CAN, and are not sufficiently reliable and secure for safety-critical functions such as the rearview camera and instrument cluster. Therefore, we need a system architecture in which multimedia operating systems and their applications can coexist harmoniously with highly reliable real-time applications managed by a dedicated real-time operating system specifically designed for protection.
One potential solution is to use multiple processors dedicated to different tasks. However, this results in the same problems as multiple ECUs currently used: it slows down communication between applications and increases complexity at the edges.
The need to integrate these functions into a single processor is very real, as it allows for optimization of cost, processing cycles, data availability, and complexity. We need secure execution environments (sandboxes) for these mixed-criticality workloads. We can identify each of these secure environments with an isolated profile.
These four multi-profile techniques have been commercialized in one form or another:
• Multiboot
• Webtop
• Type 2 Hypervisor
• Type 1 Hypervisor
Multiboot
The concept of multibooting has been implemented in some laptops and network computers for a few years now. In a dual-boot laptop, a secondary operating system, usually a simplified version of Linux, can be activated instead of the platform's main operating system. This simplified system is typically used only for web browsing, and its main purpose is to allow the user to browse just a few seconds after booting. The secondary operating system is stored separately and never runs at the same time as the platform's main operating system. In some cases, this lighter environment runs on a secondary microprocessor (e.g., an ARM SoC separate from the computer's main Intel processor).
The secondary operating system is characterized by its good isolation from a security standpoint; however, the drawback of restarting and its inability to switch between different profiles has severely limited its adoption. The multi-boot option is also impractical in the integrated infotainment environment, which requires the concurrent execution of profiles, for example, the multimedia infotainment system along with the instrument panel and real-time communications.
webtop
concept (web desktop with integrated networking) offers a limited browsing environment independent of the primary operating system. However, instead of dual-booting, webtop functions as an application running on top of the primary operating system. As long as webtop runs non-security-critical system components and the primary operating system can handle critical applications in isolation, this option can meet all requirements. However, a browser-based environment may not meet the demanding functionality requirements of modern infotainment systems.
A similar option involves running the webtop or playback interface from a smartphone connected to a docking station. This method could also meet the requirements (the smartphone's processor is used for multimedia applications instead of the vehicle's infotainment computer). This remote smartphone technique has been marketed in some vehicles and remains an interesting option. One of its challenges lies in ensuring that the smartphone can provide an experience tailored to the car.
Type 2 Hypervisors
: Type 2 hypervisors are similar to webtops in that a secondary profile runs an application on top of the primary operating system. However, instead of simply incorporating a browser, the secondary profile is a fully functional guest operating system running in a virtual machine created by the hypervisor application (Figure 4). This guest operating system could be a real-time operating system suitable for hosting critical applications such as the rearview camera or instrument panel. The hypervisor uses the primary operating system to handle I/O. The virtualization-based technique fulfills the requirement of providing complete functional environments for both critical and non-critical profiles.
However, the Type 2 model fails to provide robust isolation. Security flaws or vulnerabilities in the primary operating system will affect critical real-time functions running in the virtual machine. Furthermore, it has also been discovered that Type 2 hypervisor applications installed in the company's environment also harbor vulnerabilities capable of compromising the secure execution environment.
Type 1 Hypervisors:
Type 1 hypervisors also provide full functionality and concurrent execution of multiple profiles. However, since the hypervisor runs in the open, profile isolation cannot be compromised by weaknesses in the profile's operating system. Therefore, a Type 1 hypervisor represents a promising solution from both a functional and security standpoint. Nevertheless, the threat of hypervisor vulnerability remains, and not all Type 1 hypervisors are designed to achieve high levels of protection and security.
One version in particular, the microkernel-based Type 1 hypervisor, is specifically designed to meet the demanding real-time, fast boot, and security requirements of modern infotainment environments. Microkernels offer a superior architecture for protection and security compared to large, general-purpose operating systems like Linux, MeeGo, Android, and Windows. A microkernel runs only a minimal number of system-critical services, such as process management, exception handling, and inter-process communication, in supervisor mode. It provides an architecture that allows software to run on complex systems in user mode when it is only granted access to the resources the system designer deems appropriate. A vulnerability or flaw in one component cannot damage a critical component because the infected subsystem simply cannot access that resource. Because the microkernel is relatively simple, it can be formally verified and certified by independent regulators to the highest levels of protection and security.
In a Type 1 hypervisor with a microkernel, system virtualization is added as a service within the microkernel itself. Therefore, in addition to isolated virtual machines, the microkernel provides an open, standard interface for lightweight, mission-critical applications such as driver information, cryptographic subsystems, and CAN bus controllers, which cannot be entrusted to a general-purpose host. Figure 5 illustrates the Type 1 microkernel architecture.
An example of a Type 1 hypervisor with a microkernel is the INTEGRITY Multivisor from Green Hills Software, which is based on the
INTEGRITY microkernel, widely used in automotive infotainment and other critical real-time protection applications.
Applying the Type 1 hypervisor architecture with a microkernel to the aforementioned mixed-criticality infotainment system, consisting of the main infotainment operating system and critical protection applications for the rearview camera and driver information, results in the architecture shown in Figure 6.
Secure Network Transactions
Figure 6 also illustrates a manageability application. Another useful application of the Type 1 architecture with a microkernel is hosting secure remote communication subsystems that are native to the microkernel. Examples of secure next-generation network transactions in infotainment systems include protected media content and digital rights transmission, as well as remote system management (e.g., firmware updates and remote diagnostic instructions) by technicians and OEMs.
In this regard, a key idea is that this solution creates a secure connection, logically outside the reach of the host system. Since the encryption keys, server certificates, and protocol software are managed in native processes, this critical data cannot be stolen or corrupted by the host operating system, regardless of malware infiltration. Furthermore, the native security subsystem can leverage its TPM (or equivalent) capabilities, if present, for hardware-based key storage and platform authentication. The secure connection rejects man-in-the-middle attacks and malware attacks that attempt to steal the cryptographic keys used for secure communications.
GENIVI
GENIVI is an industry alliance that promotes reference platforms for in-vehicle infotainment, aiming to reduce time to market and development costs. These reference platforms incorporate pre-competitive features deemed essential in any system, allowing organizations to focus on innovative features that drive competitive advantage. A key principle for achieving these goals is the use of open standards and their associated certification of conformity. Given that traditional infotainment systems rely on powerful, general-purpose operating systems, it is no surprise that GENIVI's first reference platforms are based on Linux distributions that meet the requirements of the GENIVI Declaration of Conformity.
Looking ahead, stakeholders in the automotive infotainment sector, including OEMs and their suppliers, government regulators, and passengers, must look beyond the multimedia system itself and consider a new world of mixed-criticality requirements. Next-generation system software architectures are needed to ensure that future infotainment systems, characterized by their complexity and numerous features, deliver the reliability, security, real-time operation, and manageable size demanded by the automotive industry and consumers. Systems embedded in future cars will experience a convergence of critical safety functionality alongside traditional telematics and digital entertainment applications. Delivering this functionality on a single computing platform is critical to minimizing the size, weight, power consumption, production cost, and complexity of the electronics. However, achieving this securely requires a new approach to system architecture.
A promising option for secure execution environments is Type 1 system virtualization, which can isolate and manage security-critical applications for real-time protection, as well as powerful open-source multimedia operating systems. Furthermore, the availability of virtualization technology for a wide variety of computing platforms offers developers and technologists the ultimate open platform: the ability to run any type of operating system in any combination, creating unprecedented flexibility for installation and use. This flexibility is welcome in automotive applications, desktop computers, and servers alike.
Authors: David Kleidermacher, Chief Technology Officer, Green Hills Software
Matt Jones, Vice President, GENIVI Alliance
