Trusted Execution Environments (TEEs) in Connected Cars

Today a connected car is not much different than a smartphone on wheels. In the future, the number of autonomous driving capabilities will create a data center on wheels. However, a vehicle is currently less secure than a smartphone! Connected cars are complicated machines that possess large and expanding attack surfaces (Figure 1). This cat has been out of the bag since the famous 2015 Jeep® hack. Most recently, Consumer Watchdog also warned of car vulnerabilities in its July 2019 Kill Switch report. 

 

Figure 1. Connected and autonomous vehicles: a cyber-risk classification framework. Image courtesy of Science Direct [CC BY-SA 4.0].

 

Trusted Execution Environments

In the context of comparing smartphones and connected cars, there are fundamental security methodologies that the auto industry can borrow from the phone industry. If your phone can perform mobile payments, you have a secure element (SE) on it. SEs are also prevalent for several industries to protect communications, financial services, and identities. 

Cars are more complicated than a phone and have safety-security functional blocks, which is why trusted execution environments (TEE) should be considered. TEE, similar to SE, is also a trusted computing module (TPM). A TEE is an isolated environment that ensures critical operations can be compliant with the “CIA triad” (confidentiality, integrity, and availability), that its assets such as code, keys, and data are also compliant with CIA. In addition to smartphones, TEEs can be found in a variety of applications including set-top boxes, industrial IoT, enterprise, and government identification programs.

 

Uses of TEE in a Car

With an understand of what TEE is and where it's found, there are use cases to explore that focus on how it works in a connected car.

 

Secure Boot and Over-the-air (OTA) Updates

Secure boot is the process of booting the hardware systems such as electronic control units (ECU) to trusted firmware and software. An ECU is one of many embedded computers in a car that controls everything from locks to transmissions to brakes. The cryptographic functions, keys, firmware executables, and bootrom code all should be kept immutable. Any tampering must be prevented and detected, and this is the value of a TEE.

Secure OTA update is used to receive new firmware or software, and then securely upgrade the target system. Recently OTA has expanded to remote management — vehicle diagnostics and sensor data are processed and status transmitted back to the cloud for driving, safety or maintenance use cases. These safety-critical functions can be safeguarded by utilizing a TEE.

 

Digital Rights Management and Financial Transactions

As autonomous driving levels advance, passengers expect to do more tasks while in transit, such as digital entertainment, shopping, banking, etc. Media copyright and financial transactions are best kept confidential and untampered in a TEE just as it is currently done on set-top boxes or smartphones.

 

Zero Trust Model for Mixed-criticality Systems

The software supply chain of a vehicle is extensive. Dozens and even hundreds of third-party libraries are used for each vehicle. Frequently they are compiled and linked with safety-security code and share memory resources. As a result, faults and vulnerabilities from the less trusted third party components can affect the safety-criticality of the system. To mitigate this risk, a zero-trust model is desired. For example, network stacks are susceptible. Open-source software is great but it originates from different developers; a TEE can be deployed to contain faults and attacks of network and open-source software.

 

Workload Consolidation

A modern car has over 100 ECUs and two to three miles of electrical wiring. The cost of electronics as a percentage of the total cost of a car is projected to hit 35% and 50% in 2020 and 2030 respectively. To reduce the size, weight, power, and cost (SWaP-C), the automotive industry has been consolidating multiple workloads onto single platforms.

For instance, on a domain controller network configuration, the infotainment control unit may combine a digital instrument cluster that runs on RTOS, and in-vehicle infotainment (IVI) on a rich OS. Because the former functional block is of ASIL B class (Automotive Safety Integrity Level), it ought to be protected in a TEE.

 

Why are There Limited TEE Deployments on Cars?

Despite the various use cases, TEEs are not widely utilized in cars today. They are mostly tasked for secure boot where the TEE is typically implemented using a hardware security module (HSM) which is an on-chip module to the main system-on-chip (SoC) of the ECU. The drawback of an HSM is that it’s costly and unscalable — the car-maker has to rely on tier one and tier two suppliers to customize the interface to each ECU. As a result, not every ECU is outfitted with an HSM, thus exposing security weaknesses.

For the workload consolidation use case, certain embedded hypervisors are used for guest OS colocation. Potential functional limitations for these hypervisors are the requirement of  complex virtualization extensions, e.g. a two-stage memory management unit (MMU), the need to modify the code or toolchain of the guest systems, and the associated performance impact. There are security tradeoffs: the hypervisor software footprint presents a sizable attack surface; if the guest OS’es communicate via shared memory, that violates the zero trust model. 

In Part Two of this article, I will explore candidate TEE solutions. And how TEE fits into a defense-in-depth strategy for connected vehicles. Stay tuned to the path of making our connected cars more secure than our smartphones.

Industry Articles are a form of content that allows industry partners to share useful news, messages, and technology with All About Circuits readers in a way editorial content is not well suited to. All Industry Articles are subject to strict editorial guidelines with the intention of offering readers useful news, technical expertise, or stories. The viewpoints and opinions expressed in Industry Articles are those of the partner and not necessarily those of All About Circuits or its writers.