Cyber-Hardening Autonomous Vehicles with the “Big Four”

By Xiangrong Li, Senior Cybersecurity Engineer

Modern vehicles are increasingly complicated systems dependent on an array of computing hardware and software. To meet the growing demand for increased safety and new features, manufacturers are using more sophisticated in-vehicle networks to connect more Electronic Control Units (ECU) and actuators.

Autonomous vehicles are even more complicated, creating additional possible attack angles for hackers and a greater potential for security vulnerabilities. A security breach could cause malfunction or unexpected behavior of ECUs and the vehicle as a whole, which lead to damages from reputational to serious safety accidents.

One of Motional’s core values is: “Safety as our bedrock.” To practice this, we reduce cybersecurity vulnerabilities through system hardening; or reducing our attack surface and introducing fundamental security mechanisms to mitigate threats. This post will discuss the key security mechanisms Motional uses that we call the “Big Four.” First, we’ll explore our threat identification process.

Identifying Threats

Threat modeling is a popular technique for analyzing a system to find and prioritize threats and their mitigations. While there are many potential approaches, our initial threat models were based on modeling our system using data flow diagrams in collaboration with engineers. We used STRIDE — spoofing, tampering, repudiation, information disclosure, denial of service or “DoS”, and elevation of privilege — to structure threat discovery, and a bug bar to prioritize issues. We structured this work within Adam Shostack’s four question framework:

1. What are we working on?

2. What can go wrong?

3. What are we going to do about it?

4. Did we do a good job?

Modern vehicles typically rely on discrete ECUs to implement different functions. For example, one ECU may implement radar sensing while another controls door locks and related body controls. Most ECUs are embedded systems powered by a microcontroller (MCU), system-on-chip (SoC), or application-specific integrated circuit (ASIC). ECUs talk to each other within the vehicle through different communication channels, most of which are wired for reliability. Common channels include Controller Area Networks (CAN), Local Interconnect Networks (LIN), Ethernet, etc. Since ECUs and the self-driving systems network provide the building blocks on which software is created, that is where we focused our initial threat modeling efforts.

We threat-modeled our early autonomous driving systems, including the system we use with Lyft. After identifying mitigations for threats across two different system versions, we clustered threats by priority and mitigation and determined that four mitigations covered a majority of the threats, including all that clearly presented unreasonable risk. We realized focusing on these four mitigations made a great way to simply and quickly communicate the most important but invasive mechanisms that needed to be introduced. Thus, we branded them as the “Big Four” and crafted messaging around them for internal purposes.

The “Big Four”

Threats tend to manifest due to the firmware and/or software (hereafter collectively referred to as “software”) each ECU runs, as well as the communications between ECUs. Thus, the Big Four are mechanisms that broadly defend either software or communications. In particular, the Big Four are:

  • Secure Boot — used to identify the source of software and to ensure it has not been altered since it was built.
  • Device Identity and Authentication — used to identify ECUs in the system and entities that interact with them.
  • Secure Communications used to ensure that messages between ECUs are not tampered with and are authentic.
  • Secure Update — used to ensure we can update the software ECUs are running if vulnerabilities are discovered in the field.

Let’s look at each in turn.

Secure Boot

ECUs run software stored on data storage located either internal or external to the processor. It is not uncommon that ECUs simply trust this software is authentic and untampered. To illustrate why this matters, there are several low-cost and fast ways to modify or replace software stored in flash memory. This leaves open the possibility that a malicious actor will modify the software to plant malware or change functionality.

Secure boot is the primary way to mitigate threats related to unauthentic or tampered software. To implement secure boot, there are some basic requirements of the ECU that can be summarized by stating that the ECU must contain a hardware root of trust. For example, a small piece of red-only memory to store bootROM code and a one-time programmable (OTP) memory to store credentials. On the software front, all code the ECU will load and execute must be digitally signed. A digital signature, if validated as part of the boot process, guarantees the authenticity and cryptographic integrity of the software. ECU software vendors sign the software as part of their software build process.

When putting the hardware and software together, normally the cryptographic key required to verify a digital signature is provisioned to OTP memory during ECU manufacturing; it cannot be altered throughout the lifespan of the ECU. During ECU boot time, the code stored in bootROM is executed to verify the image signature with the key stored in OTP. Only software images having a valid digital signature can be loaded and executed.

In practice, the secure boot procedure is generally defined by the chip vendor used for any given ECU and that is the only procedure available for use. For example, the secure bootROM is generally fixed and read-only. The OTP memory to store signature keys is also defined by chip vendors, with limited choice of key type and key size. The secure boot procedures offered by recent ECU processor vendors are generally sufficient to guarantee only authentic software can be executed.

Device Identity and Authentication

There are two key use cases for device identity and authentication:

  • To initiate secure communications between ECUs, those ECUs must be sure they are talking to their expected counterparts, not an imposter.
  • An external entity initiating a sensitive operation on an ECU must first identify itself to the ECU to ensure the entity is trusted by the ECU. Since, generally, ECUs in a self-driving vehicle operate on each other, an ECU that is, for example, updating the software on another ECU must first identify itself to the node it is updating.

On the web, HTTPS, which uses TLS, is the most common means to authenticate a server to a web browser. ECUs using our device identity approach share a similar authentication procedure as the one used during a TLS handshake. On the web, only the server is authenticated to the client. In Motional’s system, both sides of a communication channel authenticate to each other.

However, the automotive industry is generally slower to adopt the most up-to-date authentication techniques due to compatibility concerns and the lead times required to update all applicable ECUs. For example, a popular protocol to allow ECUs to operate on each other (or for external tools to operate on an ECU) is called the Unified Diagnostic Services (UDS), and it has historically not used authentication approaches that reach the level of security seen on the web. In 2020, a new UDS authentication service was introduced, which supports Authentication with PKI-based Certificate Exchange (APCE). This service is cryptographically stronger, but will not see immediate adoption. Thus, we have established a mechanism on top of the traditional UDS authentication approach to achieve a degree of security closer to what we desire for cases that cannot utilize the more TLS-like approach.

Secure Communication

After authentication, the sender and the receiver on a communication channel can start exchanging data. However, the communication channel may not be secure. Attackers may spoof messages, alter them in transit, resend old messages, etc. Therefore, communication channels need to be secured to guarantee data confidentiality, integrity, and authenticity. For a self-driving system, secure communication includes scenarios such as communication between the vehicle and external systems (e.g., cloud update server, remote command center, etc.), vehicle-to-anything (VX) communication, and communication between ECUs within the vehicle.

Before any data exchange, proper unilateral or bilateral authentication is needed to identify the source and/or destination of the data transfer. After both sender and/or receiver are identified, communication can start. Several factors need to be taken into consideration when deciding what security measure should be used, for example:

  • The physical communication media;
  • The communication protocol being used;
  • The computing power of sender and receiver devices;
  • Whether there is secure hardware or trusted execution environment (TEE) presented on sender and receiver devices, and their supported algorithms;
  • The desired data throughput; and
  • The content sensitivity of the data being transferred.

These factors determine whether a certain security measure is necessary and/or feasible, and the bounds for the complexity of any security measure to be used. Thus, no one mechanism can be used to secure all possible communications in a self-driving vehicle. Generally, we pick the most appropriate mechanism from a range spanning from mutually authenticated TLS on the high end, to message authentication codes and a counter per message on the low end. In other words, depending on the entities communicating, we can achieve a level of security suitable for a hostile environment such as the Internet or at least ensure that messages are authentic and have not been altered or resent.

Secure Update

New threats and vulnerabilities are identified and exposed every day. Even if the ECU software is secure after manufacturing, it may be subject to attacks after new vulnerabilities are disclosed. Thus, the capability to securely update software throughout the lifespan of ECU devices becomes crucial. For modern vehicles, software updates may also bring new features and non-security bug fixes, but this is not the focus of this discussion.

Secure update process guarantees secure delivery of software update packages from the software developer’s build process to the code storage device on the ECU. A general best practice is to sign the software update package with an asymmetric key-based digital signature during the build process. Then transfer the update package through the cloud update server, vehicle local update server, and eventually to the code storage device of the specific ECU, with authentication and secure communication for each hop. The software update is finally accepted upon successfully verifying the digital signature and/or decrypting the software image.

Different technologies and frameworks are available to fulfill each of the generic secure update steps. For update package signing, the ECU manufacturer can either use in-house infrastructure or commercially available code signing as-a-service. The delivery of an update package from the update server to a vehicle can use any security best practice specific to the communication channel and selected protocol, such as TLS over TCP/IP network. Vehicle local update servers can transfer the software images to ECUs by making use of unified diagnostic services (UDS).

Uptane is an end-to-end framework for automotive secure update applications. It limits the possibility of security incidents during software updates by providing a “compromise-resilient” system that prevents hackers from installing inauthentic, out-of-date, or otherwise compromised software via the update process. Uptane accomplishes this by using a combination of offline and online security key signings by multiple roles with configurable key thresholds. It addresses a comprehensive threat model for highly complex vehicles with multiple ECUs and supporting software and data requirements.

Beyond the “Big Four”

It should be noted that the Big Four don’t preclude the use of other mitigation approaches. It is still necessary to build security in using lifecycles, such as Motional’s Autonomous Vehicle Cybersecurity Development Lifecycle (AVCDL), and to use additional mechanisms such as sandboxing, intrusion detection, full disk encryption, etc., where applicable to further harden systems.

Additionally, the Big Four do not live in a vacuum. As alluded to earlier in this post, there are off-board infrastructure pieces necessary to support the vehicle and enable these four mitigations. These include but are not limited to:

  • Code signing infrastructure
  • Key management infrastructure
  • Security operations infrastructure
  • Software deployment/update infrastructure

Although the Big Four cannot cover 100 percent of threats to autonomous vehicles, many important threats can be handled by these fundamental security mechanisms.

Reference

1. “Threat Modeling: Designing for Security” by Adam Shostack

https://github.com/adamshostack/4QuestionFrame

2. STRIDE

https://en.wikipedia.org/wiki/STRIDE_(security)

3. Microsoft threat modeling

https://www.microsoft.com/en-us/securityengineering/sdl/threatmodeling

4. Uptane

https://uptane.github.io/

We’re making driverless vehicles a safe, reliable, and accessible reality. Join us on our mission to change how the world moves: https://motional.com/careers