ECU-Level Security Controls

In the preceding chapter, we delved into security controls at the vehicle level. To maintain our stance on the principle of defense-in-depth (DiD), our focal point now shifts to the establishment of resilient vehicle components at the electronic control unit (ECU) hardware, software, and physical component layers. However, before implementing any security controls, an understanding of their potential challenges and pitfalls is crucial. As we walk through each class of security controls, we will share hints on ways to securely deploy them. In the first section, we explore hardware security mechanisms, specifically at the microcontroller (MCU) and system-on-chip (SoC) levels. These controls are fundamental building blocks upon which higher-layer software security controls are established. They include controls such as hardware root of trust (RoT), secure storage, cryptographic accelerators, chip-level isolation techniques, and trusted execution environments...

Understanding control actions and layers

As with vehicle-level cybersecurity controls, ECU-level controls aim to detect, protect, and recover the ECU to a safe and secure state in response to ECU-level threats. As we mentioned in Chapter 7, in terms of the controls’ effectiveness in risk treatment, the control actions can be classified in this order:

1. Protect: These controls prevent the attack from happening in the first place. For example, encrypting filesystems prevents private data exposure.
2. Detect: These controls can effectively detect abnormal behavior. For example, authenticating the filesystem image allows the system to detect when it has been tampered with.
3. Recover: These controls allow the system to recover to a secure state when an anomaly is detected. For example, upon detecting that a filesystem has been tampered with, a backup image is used to avoid an inoperable system.
4. Log: These controls log the event to enable user notification and root cause...

Exploring policy controls

Just as with the vehicle-level analysis, policy controls must be applied at the ECU level to prohibit design decisions that unreasonably increase the attack surface and significantly alter the threat model of an ECU. Examples of attack surface reduction policy controls are the requirement that all debug interfaces are either locked or disabled, the removal of code profilers, and the elimination of security log traces from production intent builds. The removal of such tools and abilities lowers the attack feasibility related to reconnaissance and the discovery of ECU weaknesses and has a significant return on investment (ROI) in terms of risk elimination. An organization can also enforce policy controls to prohibit certain design choices that would alter fundamental assumptions made during threat modeling. For example, assume the threat model considers that all external network connectivity is filtered through a central gateway. For improved customer experience...

Exploring hardware controls

When it comes to building a secure ECU, hardware security controls are king, earning them the first spot among cybersecurity controls to consider. This family of controls forms the foundation upon which software-based cybersecurity controls become possible. This becomes evident when vulnerabilities in hardware are discovered, creating challenges for software developers due to the complexity of crafting and deploying workarounds. In the same vein, if the performance needs of hardware security controls are overlooked, their deployment in time-sensitive automotive systems can become a significant hurdle. Even when implemented correctly and with adequate performance, lack of attention to the usability factor can make such controls hard to deploy, which in some cases results in the user disabling them altogether. Thus, hardware controls should be seen as critical security enablers that must be carefully selected to ensure they can achieve their intended cybersecurity...

Exploring software security controls

Now that we have previewed some of the commonly used security controls in automotive ECUs, we can switch focus to software security controls. As we will see, many of these controls are built on top of hardware security primitives and aim to provide more sophisticated security mechanisms that hardware alone cannot offer.

Software debug and configuration management

Building on hardware debug access protection, it is equally important to eliminate and/or restrict access to software debug tools. It is common for developers to use a wide range of such tools to aid in troubleshooting and testing the ECU prior to production. A common mistake is to leave these tools in the ECU even after the product is shipped. In MCU-based ECUs, these tools range from proprietary diagnostic protocols that are used in factory mode to trace tools that log extensive error codes to pinpoint the file and line of code where an error occurred, to standard calibration protocols...

Exploring physical security controls

Attackers with physical access to the target are normally after high-value assets whose compromise can be leveraged on a larger scale. For example, they may be interested in recovering global secrets, reverse engineering software, or even simply mounting denial-of-service (DoS) attacks through a physical attack surface. While most physical-based attacks require direct access to the target, some can be carried out by simply being within proximity to the target. In this section, we briefly survey cybersecurity controls implemented through hardware, software, and packaging techniques to raise the difficulty of physical-based attacks.

Tamper detection and prevention

While not the most effective at eliminating risk, physical security measures, such as tamper-evident seals or secure enclosures, can be useful in preventing or detecting unauthorized physical access to the system by raising the difficulty level of carrying out such attacks. For example...

Summary

In this ninth and final chapter, we looked at the most commonly used security controls applied to the hardware, software, and physical layers of the ECU. With this layered approach, we continued with the theme of DiD, which started at the vehicle interface level in Chapter 8. We showed the role that hardware plays in establishing the foundation of a secure system. Hardware security controls included the hardware RoT, secure memory, and authenticated debug ports. Then, we looked at security controls in the software domain that build upon the hardware security controls, such as multi-stage secure boot, virtualization through hypervisors, and process and temporal isolation through OSs. Finally, we looked at controls applied at the physical layer to reduce the feasibility of attacks by agents who have gained physical access to the ECU. While exploring the various security layers, we highlighted areas in which competing priorities emerge between security on one hand and the need...

Further reading

Studying cybersecurity controls is perhaps one of the most technically interesting aspects of cybersecurity. To further expand your knowledge about cybersecurity controls that can be applied at the ECU level, we recommend the following list of resources:

• [1] CyBOK, The Cyber Security Body of Knowledge: https://www.cybok.org/
• [2] Secure Application Programming in the presence of Side Channel Attacks: https://www.riscure.com/publication/secure-application-programming-presence-side-channel-attacks/
• [3] Development of TEE and Secure Monitor Code: https://www.arm.com/technologies/trustzone-for-cortex-a/tee-and-smc
• [4] Achieving a Root of Trust with Secure Boot in Automotive RH850 and R-Car Devices – Part 1: https://www.renesas.com/us/en/blogs/introduction-about-secure-boot-automotive-mcu-rh850-and-soc-r-car-achieve-root-trust-1
• [5] Securing distributed systems: A survey on access control techniques for cloud, blockchain, IoT and SDN: https...