Vehicle-Level Security Controls

In Chapter 3, we discussed the different types of cybersecurity threats in automotive systems and how they relate to the vehicle’s E/E architecture. Instead of jumping straight into technical solutions, we emphasized the importance of a systematic engineering approach to identifying and managing risks. Now, in this chapter, we will shift our focus to technical solutions to minimize cybersecurity risks through a defense-in-depth strategy. It is sometimes possible to eliminate a risk by removing a risky feature from the product’s design. Most of the time, we must find ways to manage the risks using appropriate cybersecurity controls. As we will see in this chapter, introducing cybersecurity controls can lead to increased costs from added components as well as impact the system’s performance. Furthermore, with each design modification, the vehicle risk profile is impacted, sometimes negatively, due to the potential for misconfiguration...

Choosing cybersecurity controls

If the job of cybersecurity professionals were to simply look up cybersecurity controls to mitigate threats, then it would have been a relatively easy job. In reality, knowing which cybersecurity control to apply is only the first step in implementing effective threat mitigation. After choosing the control, security analysis is needed to identify emerging threats that can result in the bypass or disablement of the control itself. Furthermore, knowledge about the security pitfalls and weaknesses associated with a given control is critical to ensure that the mitigation can truly be effective. This results in several rounds of security analysis to identify and examine the new assets that are introduced by the control and how they are subject to attack before the job of threat mitigation can be considered complete. Take, for example, secure boot, a well-known cybersecurity control that is expected to detect tampering in electronic control unit (ECU) code...

Vehicle-level versus ECU-level controls

Just as the threat analysis and risk assessment (TARA) is performed at multiple layers of the design, the security controls are applied hierarchically. As a result of this layered analysis, cybersecurity controls are applied in a layered fashion, which is essentially a defense-in-depth cybersecurity strategy. With each security layer, the likelihood of a successful breach is reduced as attackers must defeat or find gaps in multiple security layers before achieving their objective. Figure 8.2 shows 11 security layers applied across the various vehicle life cycles:

Figure 8.2 – Defense-in-depth security layers and controls

Each security layer shown in Figure 8.2, is considered a single cybersecurity control family, which, in turn, relies on several technical controls. In the remainder of this chapter, we will walk through the layers of the vehicle architecture to present common cybersecurity controls that are...

Policy controls

This first type of control is enforced through organizational-level procedures that define what is permissible from a security perspective. Policy controls are simply dos and don’ts that must be observed to eliminate certain risks that would otherwise be very expensive or difficult to mitigate through technical controls. An example of a policy control relates to the use of aftermarket telematics units and onboard diagnostics (OBD) dongles. Such devices are known to be abused by hackers to gain access to a vehicle’s internal network and spoof its components. This can result in modifying the target ECU software or data, enabling the attacker to take control of the vehicle remotely.

To mitigate the risks associated with aftermarket telematics control unit (TCU) devices/OBD dongles, original equipment manufacturers (OEMs) can define a policy control that prohibits the vehicle owner from using such devices if they want to avoid voiding their vehicle’...

Secure manufacturing

The first set of technical cybersecurity controls deals with securing the manufacturing process both at the component and vehicle levels. This includes applying security controls for the process of installing firmware and software, provisioning critical security parameters (CSPs), and transitioning the component or vehicle into a secure production state. The goal of such controls is to ensure that the vehicle’s assets are protected from the start of production until the vehicle rolls off the production line. The usage of a secure key management infrastructure is fundamental to achieving these goals. This is enabled by hardware security modules (HSMs) deployed within the factory environment to generate secret keys that need to be provisioned into each vehicle. The HSM can also be used to sign software images and calibration sets before flashing vehicle ECUs. Wherever possible, the HSM should be leveraged to generate private/public key pairs and shared symmetric...

Secure off-board network communication

Earlier in this book, we discussed how attackers can use Wi-Fi, cellular, Bluetooth, and other external connectivity interfaces to eavesdrop or tamper with vehicle data and control functions. Some ways to reduce security risks linked to off-board communication technologies include creating network firewalls, setting up intrusion detection and prevention systems, using network segmentation and isolation methods, restricting network access to vehicle ECUs, and establishing secure communication channels with backend servers.

When adopting such controls, automotive engineers must be aware of the impacts on computing resources, power consumption, real-time performance, and cost factors. In the remainder of this section, we will explore the controls at each communication interface layer and point to ways they can be tailored to fit within the vehicle’s environment.

Wi-Fi

Wi-Fi can be used in vehicles to provide hotspot services, stream...

Host-based intrusion detection

Even with state-of-the-art security controls, the OEM has no visibility of how effective those controls are during normal operation. Indeed, some controls may start out being quite effective yet diminish in strength over time as attackers’ abilities and tools increase in sophistication. Therefore, a security strategy that relies only on preventive security controls is incomplete unless complemented by attack detection mechanisms. Building anomaly detection systems in the vehicle accompanied by a backend security operation center (SOC) enables an OEM to bridge that gap and gain real-time perspective about the level of threats that the entire vehicle fleet is experiencing. This further enables the OEM to react promptly after an incident is detected when patching vulnerabilities is needed. With the distributed E/E architecture, no single ECU can know about all security events in the vehicle, so the host-based intrusion detection system (IDS) itself...

Network intrusion detection and prevention (NIDP)

While host-based intrusion detection systems can be effective in alerting the OEM of potential active attacks, the time to respond makes them inadequate to fully mitigate active breaches. Naturally, there is a need to incorporate network intrusion prevention systems that can eliminate breaches before they become a persistent threat. However, any such solution must be carefully designed to account for the requirement of determinism in automotive systems. Unlike an IT environment, where a false positive that may lead to closing a network connection is tolerated, in a vehicle environment, falsely denying a network message that carries safety-related data can produce a high degree of indeterminism, which can eventually affect the availability of safety-related functions. Therefore, when picking network intrusion prevention solutions, eliminating false positives is a high-priority objective.

Some techniques for deploying NIDP in vehicles...

Domain separation and filtering

Besides filtering unwanted traffic and detecting malicious network packets, enforcing domain isolation over the internal vehicle network is a critical security control to prevent the corruption of a single network segment from propagating to deeper layers of the vehicle network architecture. It is not uncommon to find vehicle network architectures with multiple gateways that route messages between different vehicle control domains. The challenge with multiple gateways is that it is easy to create unintended communication paths, which result in traffic flowing into network segments that must have a high degree of integrity and availability. To eliminate weak architecture design, central gateways and domain controllers provide a clean way of domain separation, which further eases the application of network filtering. Network segmentation can be used to separate connectivity domains such as telematics and infotainment from actuation domains such as the...

Sensor authentication

Sensor data integrity and identity protection were shown to be primary security objectives to ensure the correctness of the vehicle control functions. With the rise of ADAS use cases, the need for trusted sensors experienced a sharp rise. A secure sensor needs to support one or more of the following security controls:

• Identity authentication
• Cryptographic data integrity and confidentiality
• Physical attack mitigation

The first control ensures that before accepting any communication from a sensor, a secure session is established, where the sensor can prove the authenticity of its identity. This can be done using a pre-provisioned sensor root public key in the ECU communicating with the sensor. Then, the sensor can be challenged to prove possession of the private key by submitting a random challenge that the sensor must sign. This step can involve exchanging an ephemeral session key (for example, using ECDH(E)) to protect further communication...

Secure software updates

Securing software updates over the air is a critical component in the overall strategy of keeping the vehicle software patched while preventing the tampering of ECU software. To achieve this objective, an end-to-end approach is needed, starting with the backend and terminating at the target ECU. This holistic approach requires a series of security controls to be applied at each stage of the OTA update process, including a robust update service architecture, strict access controls and privilege separation in the backend, secure data transfer to the vehicle, and authentication and encryption of software packages before software reprogramming. Let’s examine these security controls closely throughout the software update chain.

First, a code-signing service is needed to protect the authenticity and integrity of software updates before they are deployed. Establishing a secure service that enables suppliers to submit their software packages for signing is...

In-vehicle network protection

As we saw in Chapter 1, in-vehicle networks play a critical role in modern automobiles, enabling different systems to communicate and work together efficiently. The CAN network is a standard protocol that allows ECUs to exchange data in real time. However, the openness of the CAN protocol makes it vulnerable to malicious attacks, which can compromise the safety and security of the vehicle.

Before applying cryptographic measures to secure in-vehicle networks, it is important to consider all external access points that may be abused to directly tap into the in-vehicle network. It is common for vehicle network architects to leave easily accessible network ports to help in quickly troubleshooting network issues during development. Unfortunately, these also enable attackers to easily tap into the vehicle network after the vehicle is in operation. Easy access to the internal network means an attacker can install CAN sniffing tools that can inject malicious...

Securing diagnostic abilities

During development and maintenance, diagnostic and debug services are seen as lifesavers when it comes to identifying and troubleshooting vehicle issues. However, with this ability comes the risk of abuse. Diagnostic services in the hands of an attacker can pose serious risks to the vehicle data and control functions. This can cause unsafe actuation while the vehicle is in motion or tampering with diagnostic records or settings such as mileage manipulation or emission records tampering.

There are two strategies to protect the vehicle from the misuse of diagnostic services:

• Disable diagnostic services where they are not needed: The first type of control entails accounting for all diagnostic service protocols and features in the vehicle. This includes ISO 14229 UDS-based diagnostics, XCP calibration and flashing, and any proprietary diagnostic routines that an ECU supplier may enable during development or manufacturing. Services that can be eliminated...

Secure decommissioning

There are several events in which a single ECU or the whole vehicle needs to be decommissioned.

Such events include replacing a defective ECU, disposing of a vehicle involved in a major accident or simply when it reaches end-of-life. Besides decommissioning scenarios, having the ability to securely erase user private data arises in events such as the transfer of vehicle ownership and returning a rented car.

To ensure that user private data and intellectual property of the OEM or supplier is not exposed during these events, the vehicle needs to support routines for the deletion or destruction of such confidential data. A common technique to support secure decommissioning is to ensure that all such data is encrypted. Then, by destroying the encryption key, the data becomes practically unusable. Another technique involves securely deleting all private data by identifying and then erasing all copies of the data inside an ECU. This option is harder to achieve...

Summary

In this chapter, we delved into the essential role of security controls in establishing robust and secure automotive systems. By employing a defense-in-depth strategy, we showed how to deploy multiple layers of protection within the vehicle architecture, making it exceedingly challenging for attackers to bypass these safeguards and accomplish their malicious objectives. To do so, we focused on security measures that apply to various layers of the vehicle architecture, beginning with the backend and extending to the in-vehicle network layer. We emphasized that developing effective security controls necessitates a continuous process of risk assessment to ensure that these protective measures are resilient and resistant to tampering or disablement. This comprehensive analysis of security controls should inspire automotive organizations to invest in the development of security control catalogs and recognize the significance of implementing appropriate measures based on a risk-based...

Further reading

To learn more about the topics that were covered in this chapter, take a look at the following resources:

• [1] ISO, I., & FDIS, S. 21434-2021, Road Vehicles – Cybersecurity Engineering.
• [2] National Highway Traffic Safety Administration. (2020). Cybersecurity Best Practices for the Safety of Modern Vehicles. National Highway Traffic Safety Administration: Washington, DC, USA.
• [3] Automotive Intrusion Detection Systems | Vector.
• [4] Schmidt, K., Zweck, H., & Dannebaum, U. (2016). Hardware and software constraints for automotive firewall systems? (No. 2016-01-0063). SAE Technical Paper.
• [5] Overview of Unified Diagnostic Services Protocol: https://nvdungx.github.io/unified-diagnostic-protocol-overview/
• [6] Uptane Standard for Design and Implementation: https://uptane.github.io/uptane-standard/uptane-standard.html
• [7] 802.1AE: MAC Security (MACsec).
• [8] AUTOSAR Intrusion Detection System: https://www.autosar.org/fileadmin...