Automotive Cybersecurity Engineering Handbook E-Book

Dr. Ahmad MK Nasser

• Herausgeber: Packt Publishing
• Kategorie: Fachliteratur
• Sprache: Englisch

Veröffentlichungsjahr: 2023

Beschreibung

The Automotive Cybersecurity Engineering Handbook introduces the critical technology of securing automotive systems, with a focus on compliance with industry standards like ISO 21434 and UNECE REG 155-156. This book provides automotive engineers and security professionals with the practical knowledge needed to integrate cybersecurity into their development processes, ensuring vehicles remain resilient against cyber threats. Whether you're a functional safety engineer, a software developer, or a security expert transitioning to the automotive domain, this book serves as your roadmap to implementing effective cybersecurity practices within automotive systems.
The purpose of this book is to demystify automotive cybersecurity and bridge the gap between safety-critical systems and cybersecurity requirements. It addresses the needs of professionals who are expected to make their systems secure without sacrificing time, quality, or safety. Unlike other resources, this book offers a practical, real-world approach, focusing on the integration of security into the engineering process, using existing frameworks and tools.
By the end of this book, readers will understand the importance of automotive cybersecurity, how to perform threat modeling, and how to deploy robust security controls at various layers of a vehicle's architecture.

Leseprobe

Automotive Cybersecurity Engineering Handbook

The automotive engineer's roadmap to cyber-resilient vehicles

Dr. Ahmad MK Nasser

BIRMINGHAM—MUMBAI

Automotive Cybersecurity Engineering Handbook

Copyright © 2023 Packt Publishing

All rights reserved. No part of this book may be reproduced, stored in a retrieval system, or transmitted in any form or by any means, without the prior written permission of the publisher, except in the case of brief quotations embedded in critical articles or reviews.

Every effort has been made in the preparation of this book to ensure the accuracy of the information presented. However, the information contained in this book is sold without warranty, either express or implied. Neither the author, nor Packt Publishing or its dealers and distributors, will be held liable for any damages caused or alleged to have been caused directly or indirectly by this book.

Packt Publishing has endeavored to provide trademark information about all of the companies and products mentioned in this book by the appropriate use of capitals. However, Packt Publishing cannot guarantee the accuracy of this information.

Group Product Manager: Pavan Ramchandani

Publishing Product Manager: Prachi Sawant

Senior Content Development Editor: Adrija Mitra

Technical Editor: Irfa Ansari

Copy Editor: Safis Editing

Project Coordinator: Neil D’mello

Proofreader: Safis Editing

Indexer: Subalakshmi Govindhan

Production Designer: Shankar Kalbhor

Marketing Coordinator: Marylou De Mello

First published: October 2023

Production reference: 2031023

Published by Packt Publishing Ltd.

Grosvenor House

11 St. Paul ’s Square

Birmingham

B3 1RB, UK.

ISBN 978-1-80107-653-1

www.packtpub.com

To my extraordinary mother, Amal Awada, whose influence ignited within me, from a young age, a profound inquiry into the limits of my abilities.

To my father, Mohamad Kheir, whose serene demeanor under intense pressure instills in me the belief that within oneself lies the strength to face the impossible.

To my wife, Dr. Batoul Abdallah, who set the academic bar high, motivating me to always strive for more both academically and professionally.

And finally, to my beloved son, Yahya, and daughter, Dalia, who displayed remarkable patience while I dedicated my nights and weekends to completing this book.

– Dr. Ahmad MK Nasser

Contributors

About the author

Dr. Ahmad MK Nasser is an automotive cybersecurity architect with a long experience in securing safety-critical systems. He started his career as a software engineer, building automotive network drivers, diagnostics protocols, and flash programming solutions. This naturally led him into the field of automotive cybersecurity, where he designed secure firmware solutions for various microcontrollers and SoCs, defined secure hardware and software architectures of embedded systems, and performed threat analysis of numerous vehicle architectures, ECUs, and smart sensors. Ahmad holds a B.S. and an M.S. in electrical and computer engineering from Wayne State University, as well as a Ph.D. in computer science from the University of Michigan in Dearborn. He is currently a principal security architect for NVIDIA’s autonomous driving software platform.

About the reviewers

Heinz Bodo Seifert received his master of science in electrical engineering from the University of Siegen in 1994. He has worked in the automotive industry since 1997 for companies such as GM, Audi, and Stellantis, as well as tier-one companies such as Magna Electronics, developing automotive systems. At Audi, he was responsible for running global test fleets to collect vehicle performance data. At Magna Electronics in Auburn Hills, Michigan, he led the advanced engineering department and was responsible for developing functions and technologies that are due to emerge in the automotive field in the coming years. At Torc Robotics, he leads the safety and cybersecurity efforts for the Torc self-driving truck.

Robert Kaster is a chief technical expert at Bosch, leading the Americas' regional cross-divisional automotive product security team.  In his 27 years at Bosch, he submitted more than 100 invention records, was awarded 18 patents in automotive safety and security, and was recognized as CC-NA's inventor of the year three times. 

He designed more than 40 million braking controllers and implemented more than $70 million dollars in first-year cost savings.  He worked at Chrysler for five years in the pre-prototype electronic controller design team. Robert serves on the Auto-ISAC board of directors and led the effort to set up the Auto-ISAC in Europe.

He has bachelor's ('89) and master's ('95) degrees from the University of Michigan in electrical engineering and computer science and is working to complete a PhD in automotive cybersecurity in January 2024.

Table of Contents

Preface

Part 1: Understanding the Cybersecurity Relevance of the Vehicle Electrical Architecture

1

Introducing the Vehicle Electrical/Electronic Architecture

Overview of the basic building blocks of the E/E architecture

Electronic control units

Looking at MCU-based ECUs

Looking at SoC-based ECUs

Looking inside the MCU and SoC software layers

ECU domains

Fuel-based powertrain domain

Electric drive powertrain domain

Chassis safety control domain

Interior cabin domain

Infotainment and connectivity domain

Cross-domain

Exploring the in-vehicle network

CAN

FlexRay

LIN

UART

SENT

GMSL

I2C

Ethernet

J1939

Sensors and actuators

Sensor types

Actuators

Exploring the vehicle architecture types

Highly distributed E/E architecture

Domain-centralized E/E architecture

Zone architecture

Commercial truck architecture types

Summary

Answers to discussion points

Further reading

2

Cybersecurity Basics for Automotive Use Cases

Exploring the attack classes

Passive attacks

Active attacks

Identifying security objectives

Integrity

Authenticity

Confidentiality

Accountability

Availability

Cryptography applied to automotive use cases

Building blocks

One-way hash functions

Message authentication code algorithms

Random number generators

Public key cryptography

Key management

NIST defined security strength

Chinese cryptography

PQC algorithms

Security principles

Defense in depth

Domain separation

Least privilege

Least sharing

Mediated access

Protective defaults

Anomaly detection

Distributed privilege

Hierarchical protection and zero trust

Minimal trusted elements

Least persistence

Protective failure

Continuous protection

Redundancy

Use of standardized cryptography

Summary

Further reading

3

Threat Landscape against Vehicle Components

Threats against external vehicle interfaces

Backend-related threats

Connectivity threats

Threats against the E/E topology

Highly distributed E/E architecture

Domain-centralized E/E architecture

Central vehicle computer architecture

Threats against in-vehicle networks

CAN

FlexRay

Ethernet

The Unified Diagnostic Services (UDS) protocol

SAE J1939 protocols

SAE J2497 (PLC4TRUCKS)

Threats against sensors

Common ECU threats

Debug ports

Flash programming

Power and mode manipulation

Tampering with machine learning algorithms

Software attacks

Disclosure and tampering of cryptographic keys

Summary

References

Part 2: Understanding the Secure Engineering Development Process

4

Exploring the Landscape of Automotive Cybersecurity Standards

Primary standards

UNECE WP.29

Chinese regulation and standardization

Secondary standards

IATF 16949:2016

Automotive SPICE (ASPICE)

Trusted Information Security Assessment Exchange (TISAX)

SAE J3101 – hardware-protected security for ground vehicles

Coding and software standards

NIST cryptographic standards

Supporting standards and resources

MITRE Common Weakness Enumeration (CWE)

US DoT NHTSA Cybersecurity Best Practices for the Safety of Modern Vehicles

ENISA good practices for the security of smart cars

SAE J3061 – cybersecurity guidebook for cyber-physical vehicle systems

ISO/IEC 27001

NIST SP 800-160

Uptane

Summary

References

5

Taking a Deep Dive into ISO/SAE21434

Notations

At a glance – the ISO 21434 standard

Organizational cybersecurity management

Management systems

Intersection of cybersecurity with other disciplines

Tool management

Planning

Acquisition and integration of supplier components

Supplier capability assessment and the role of the CSIA

The concept phase

Item-level concept

Cybersecurity concept

Implications to component-level development

Design and implementation

Post-development requirements

Configuration and calibration

Weakness analysis

Unit implementation

Verification testing

Validation testing

Product release

Cybersecurity case

Cybersecurity assessment

Production planning

Operations and maintenance

Monitoring

Vulnerability analysis

Vulnerability management

Updates

End of life

Summary

6

Interactions Between Functional Safety and Cybersecurity

A tale of two standards

A unified versus integrated approach

Establishing a foundational understanding of functional safety and cybersecurity

Understanding the unique aspects and interdependencies between the two domains

Differences between safety and security scope

Differences in the level of interdependence between safety and security requirements

Conflict resolution

Extending the safety and quality supporting processes

Planning

Supplier management

Concept

Design

Implementation

Testing and validation

Release

Production

End of life

Creating synergies in the concept phase

Item functions

Item boundaries and operational environments

Damage scenarios and hazards

Safety and security goals

Safety and security requirements

Finding synergies and conflicts in the design phase

Leveraging safety and security mechanisms

Self-tests across safety and security

Leveraging error detection safety mechanisms

Eliminating inconsistencies in the error response

Parallels in design principles

Secure coding practices versus safe coding techniques

Synergies and differences in the testing phase

Summary

References

Part 3: Executing the Process to Engineer a Secure Automotive Product

7

A Practical Threat Modeling Approach for Automotive Systems

The fundamentals of performing an effective TARA

Assets

Damage scenarios

Threat scenarios

Attacker model and threat types

Attack paths

Risk assessment methods

Risk treatment

Common pitfalls when preparing a TARA

Defining the appropriate TARA scope

The practical approach

Know your system

Make your assumptions known

Use case-driven analysis

Prepare context and data flow diagrams

Damages versus assets – where to start

Identifying assets with the help of asset categories

Building threat catalogs

Creating attack paths using a system flow diagram

Risk prioritization

Defining cybersecurity goals

Choosing security controls and operational environment (OE) requirements

Tracking shared and accepted risks

Review and signoff

Case study using a digital video recorder (DVR)

Assumptions

Context diagram

Identifying the assets

Damage scenarios

Cybersecurity requirements and controls

Summary

References

8

Vehicle-Level Security Controls

Choosing cybersecurity controls

Challenging areas

Vehicle-level versus ECU-level controls

Policy controls

Secure manufacturing

Challenges

Secure off-board network communication

Wi-Fi

Bluetooth

Cellular

Host-based intrusion detection

Network intrusion detection and prevention (NIDP)

Domain separation and filtering

Sensor authentication

Secure software updates

In-vehicle network protection

CAN message authentication

Ethernet

Securing diagnostic abilities

Security access control via UDS service 0x27

Role-based access control via UDS service 0x29

Securing flash programming services

Secure decommissioning

Summary

Further reading

9

ECU-Level Security Controls

Understanding control actions and layers

Exploring policy controls

Exploring hardware controls

RoT

OTP memory

Hardware-protected keystore

Secure Universal Flash Storage

Cryptographic accelerators

Lockable hardware configuration

CPU security

Isolation through MMUs and MPUs

Encrypted volatile memories

Debug access management

Exploring software security controls

Software debug and configuration management

Secure manufacturing

Key management policies

Multi-stage secure boot

Trusted runtime configuration

TEEs

Secure update

Spatial isolation

Temporal isolation

Encrypted and authenticated filesystems

Runtime execution hardening

Security monitors

Exploring physical security controls

Tamper detection and prevention

Printed circuit board layout pin and trace hiding

Concealment and shielding

Summary

Further reading

Index

Other Books You May Enjoy

Part 1:Understanding the Cybersecurity Relevance of the Vehicle Electrical Architecture

In the first part of the book, we aim to understand the cybersecurity relevance of vehicle electrical/electronic (E/E) architectures to gain perspective on how such systems can become vulnerable to attacks and the relevant threats that apply. After walking through the evolution of vehicle E/E architecture, we introduce basic cybersecurity concepts that will aid us in later chapters when we perform security analysis and derive security controls. We end the first part of the book by surveying the threat landscape to give us a clear idea of the security problem that lies ahead.

This part has the following chapters:

Chapter 1, Introducing the Vehicle Electrical/Electronic ArchitectureChapter 2, Cybersecurity Basics for Automotive Use CasesChapter 3, Threat Landscape against Vehicle Components

1

Introducing the Vehicle Electrical/Electronic Architecture

The vehicle Electrical/Electronic (E/E) architecture refers to the set of electronic components, electrical wire harnesses, networking technologies, and software applications that coalesce to manage a diverse suite of vehicle functions tasked with controlling the vehicle and user experience.

While the combination of software and electronics has revolutionized how vehicle features are designed and deployed, it gradually produced a rich attack surface that made vehicles vulnerable to cyber threats. Therefore, understanding the fundamental concepts of the E/E architecture is a prerequisite to analyzing vehicle security. To help provide the necessary background, first, we will explore the various hardware platforms supported in the electronic control unit (ECU) and the corresponding reference software architectures. Next, we will examine how ECUs can be grouped into domains (which are distinct functional subsystems that have specific responsibilities) along with the networking technologies needed for their communication. With the ECUs and network layers defined, we will turn our attention to the sensors and actuators that enable the vehicle to sense the environment and react to it. Finally, we will put all these components together in the different vehicle architecture topologies while showing current and future trends in this area. Following this hierarchical approach should help us gain perspective on how the vehicle can be attacked.

As we dive through the E/E architecture layers, we will pose a series of questions in the form of discussion points to help you explore threats against your vehicle components. A brief answer list will be provided at the end of this chapter. The next few chapters will offer deeper insights into these discussion points as we navigate the cybersecurity threat landscape.

Note that this chapter does not attempt to offer a comprehensive list of every possible E/E architecture and component, but rather focuses on the aspects that are most relevant to vehicle cybersecurity. If you are well acquainted with vehicle E/E architecture concepts, this chapter can be considered a review to set the stage for cybersecurity analysis.

In this chapter, we will cover the following main topics:

Overview of the basic building blocks of the E/E architectureElectronic control unitsECU domainsExploring the in-vehicle networkSensors and actuatorsExploring the vehicle architecture types

Overview of the basic building blocks of the E/E architecture

Before we explore the multiple layers of the E/E architecture, we must start with ECUs. These ECUs are grouped into ECU domains, which are interconnected by a suite of in-vehicle network communication channels. The ECUs are further connected to sensors and actuators through a mixture of hardwired and network-based connections. The combination of ECUs, sensors, actuators, and network channels can be arranged in different configurations, giving rise to several variants of the vehicle E/E architecture. Figure 1.1 shows a simplified example of an E/E architecture:

Figure 1.1 – Simplified vehicle architecture view

Our first stop will be ECUs.

Electronic control units

ECUs are at the heart of the E/E architecture and consist primarily of the processing elements and electronic components necessary to perform one or more vehicle functions, such as steering, information display, seat control, and more. In the simplified view of Figure 1.1, we can see seven ECUs interconnected through the vehicle network (for demonstration purposes only). One such ECU is the electronic braking control module (EBCM), which is responsible for active safety functions such as anti-lock braking systems (ABSs) and electronic stability control (ESC). Another ECU is the battery management system (BMS), which is commonly found in electric vehicles.

Figure 1.2 – Closed box view of an ECU

The electronic components of the ECU are housed in a sealed enclosure that is designed to withstand harsh environmental conditions such as heat, vibration, and electromagnetic interference. The black connector shown in Figure 1.2 enables the ECU to interface with the rest of the vehicle E/E architecture through a set of cables known as the wire harness. Mapping the pin out of the connector is the first step to determine which signals are relevant for cybersecurity. The power inputs, physical network bus lines, hard-wired sensor inputs, and actuation outputs are among the typical assets that are considered for protection against security threats.

If you were to crack open the ECU enclosure, as shown in Figure 1.3, you would find a PCB populated with various passive and active electronic components, such as relays, solenoids, resistors, capacitors, diodes, the power management integrated circuit (PMIC), network transceiver memory chips, and, most importantly, a microcontroller (MCU) or system on chip (SoC).

Figure 1.3 – Open box view of an ECU

Due to their power, cost, and timing performance constraints, most ECU types are driven by an MCU that realizes the vehicle functions through software running on one or more CPU cores embedded within the MCU.

SoCs, on the other hand, integrate several components into one chip to offer higher computation resources with larger memory and networking capabilities, making them well suited for applications such as infotainment and autonomous driving systems.

Discussion point 1

Can you think of any assets that are worth protecting once the PCB layout is exposed?

Answers to all discussion points are provided at the end of this chapter.

To answer the preceding question, let’s first dive a bit deeper into the hardware architecture of MCU-based ECUs before moving on to SoCs.

Looking at MCU-based ECUs

An MCU-based ECU executes software through one or more symmetric CPU cores that fetch code and data from the MCU’s internal flash memory. Code execution from the internal flash is a key requirement to meet the hard real-time constraints of these ECUs. Even when external flash memory is used, it is normally restricted to storing data such as images or audio files, as is the case with an instrument cluster ECU.

Figure 1.4 – A typical MCU block diagram

MCUs come in many variants, each tailored for a specific vehicle ECU application type. For example, an MCU for engine control will have many high-precision timer units, while an MCU for body control will have a large number of general-purpose input/output (I/O) pins. When analyzing the cybersecurity threats of a specific ECU, it is important to understand the different peripherals that are available as they may introduce a unique set of assets and attack surfaces. Figure 1.4 shows a block diagram for a typical 32 bit microcontroller with multiple peripherals and networking interfaces.

Looking back at Figure 1.3, we can start to explore the assets that can be probed for by an attacker who has possession of the ECU. For one, the MCU’s memory contents are an interesting target for exposure. This is where the ECU control software and calibration data are stored and therefore are of value at least to the ECU supplier, who may wish to protect their intellectual property against illegal access. Together with the vehicle’s original equipment manufacturer (OEM), they both want to prevent probers from discovering exploits that can be leveraged in more sophisticated attacks. However, since the memory is embedded inside the MCU, by having possession of the open ECU, an attacker cannot directly probe the memory contents. Instead, they will have to explore ways to leverage the on-chip debug features or serial flash programming interfaces to gain access to the memory’s contents.

Discussion point 2

Looking at the block diagram in Figure 1.4, can you guess what might be another asset that is of interest to an attacker who has possession of our ECU?

Looking at SoC-based ECUs

At first glance, the main difference between the SoC and MCU is the increased level of complexity and the diverse set of peripherals offered. For one, the SoC has a combination of CPU clusters that serve different use cases. The application CPUs feature multiple symmetric cores that target computationally intensive functions such as perception, path planning, and sensor fusion. On the other hand, the real-time CPUs feature multiple symmetric cores that target safety-critical functions such as fault monitoring and error reporting. In addition to the common network peripheral types of an MCU, we expect to see a higher number of network interfaces with higher bandwidth (for example, Ethernet 1 GB/10 GB links and PCIE). One significant difference with the MCU-based architecture is that code execution is out of DRAM as opposed to the embedded flash. Additionally, eMMC and QSPI flash interfaces are commonly used to support loading code and data from external storage devices. As is the case with the MCUs, SoCs come in different variants as they aim to serve specific vehicle use cases. For example, you will find that SoCs for ADAS applications are equipped with computer vision and deep learning accelerators, while SoCs for infotainment are equipped with video encoders/decoders for media streaming:

Figure 1.5 – Typical block diagram of an automotive SoC

In addition to storing typical software and calibration data, an SoC has additional unique objects of value, such as machine learning models that are programmed in storage, as well as stored camera images, videos, and vehicle logs that may contain users’ private data. Machine learning models are valuable intellectual property to the ECU supplier and the OEM that helped create them. On the other hand, camera images and video data are important to vehicle owners who care about protecting their privacy. Vehicle logs serve many purposes and can be especially useful in accident investigations. Furthermore, since memory is exposed on the PCB, an attacker can attempt to directly dump the contents of the eMMC or probe the QSPI lines to extract memory contents.

Discussion point 3

Looking at the block diagram in Figure 1.5, can you spot other assets that are interesting to an attacker who has possession of an SoC-based ECU?

Continuing with our “peeling the onion” exercise, let’s look at the MCU and SoC software layers.

Looking inside the MCU and SoC software layers

The most differentiating feature of MCU-based automotive ECUs is their hard real-time performance requirements and their high degree of determinism, both of which are critical to controlling time-sensitive operations such as braking, deploying airbags, steering, and engine combustion. As a result, an MCU periodic software task may only deviate within milliseconds, and sometimes even microseconds, from its nominal execution rate before the application starts violating its safety and reliability objectives.

Before AUTomotive Open System ARchitecture (AUTOSAR) was founded, if you wished to examine the software architecture of an ECU, you would have to work in a software team at the OEM or for an automotive supplier. But thanks to the AUTOSAR consortium’s efforts of creating a standardized basic software architecture and standard application interface layer, security professionals can gain insights into a typical ECU software architecture simply by learning the basics of the AUTOSAR software architecture.

Note

AUTOSAR is a worldwide development partnership of vehicle manufacturers, suppliers, service providers, and companies from the automotive electronics, semiconductor, and software industries.

Let’s start by looking at the MCU-based software architecture based on the AUTOSAR classic variant:

Figure 1.6 – Simplified AUTOSAR classic software block diagram

At the heart of the AUTOSAR classic software architecture is the AUTOSAR real-time operating system. The AUTOSAR operating system offers several memory, timing, and hardware resource isolation and protection guarantees to support safety-critical applications. As we will see in the following chapters, some of these safety features are also useful for hardening AUTOSAR-based applications against cyber threats.

Another signature feature of AUTOSAR classic is the hardware abstraction layer, which exposes the MCU features through well-defined interfaces to ensure software portability across different hardware platforms. Configuring the microcontroller abstraction layer (MCAL) correctly and with security in mind is a critical part of reducing the attack surface against the rest of the AUTOSAR layers.

Besides the MCAL, several AUTOSAR software layers are critical for security. For example, if the Com services layer is improperly configured, it can be abused by a software application to send spoofed messages to other ECUs on the shared CAN network. Similarly, the memory stack can be exploited to tamper with the non-volatile memory contents. The diagnostic layer can cause fake diagnostic data to be erased or inserted, or even worse, critical diagnostic services to be unlocked under unsafe conditions. Even without a deep knowledge of the AUTOSAR Crypto services layer, we can guess that cryptographic keys and critical security parameters could be exposed or at least be used illegally if this layer is not properly configured or implemented.

Discussion point 4

Can you spot additional AUTOSAR layers that may be critical for security? Hint: Think about the ECU mode management.

Before moving on, let’s look briefly at the AUTOSAR runtime environment (RTE), which separates the base software modules from the application software components. This standardized application interface layer makes it possible to interchange application software components between automotive suppliers if they abide by the RTE interface definitions. The RTE configuration dictates how application software components interact with each other, as well as with the basic software modules. Therefore, tampering with the RTE configuration has significant impacts on the ECU software security.

Note that an AUTOSAR classic-based ECU software is built as a single software executable image, along with one or more calibration images.

An important software subsystem for MCU-based ECUs that is not covered by AUTOSAR is the flash bootloader, which manages how the ECU software is started and updated, two areas that are critical for security:

Figure 1.7 – Block diagram of a typical bootloader architecture

At startup, the flash bootloader performs basic hardware initialization and may control which software partition is executed based on the partition validation check results. Manipulating this stage can result in the startup of a tampered application or the improper safety and security initialization of the system. During runtime, the bootloader provides the functionality to reprogram the software and calibration images either through a diagnostic client or through an over-the-air (OTA) application. Illegal access to the flash bootloader update mechanisms can result in the ECU being programmed with unsafe or maliciously crafted software. Let’s assume the bootloader manages two partitions – one that contains a backup image and one that contains a recently updated image that must be booted. The bootloader memory flags that determine which software partition to boot after reset are critical for security because if they’re tampered with, this can result in the execution of an invalid or corrupt software image. Additionally, flash drivers containing the routines to erase and reprogram flash contents are important for security as they can be misused to reprogram or erase the ECU software or calibration data.

Discussion point 5

Investigate the software layers of the bootloader to see whether you can spot any services that can be abused by an attacker so that they can reprogram or erase the software.

Once again, let’s turn our attention to our SoC-based ECUs and look inward at the software architecture. Luckily, AUTOSAR has also standardized a software architecture that targets such systems through the AUTOSAR adaptive variant. While AUTOSAR adaptive has not reached the level of market adoption as AUTOSAR classic, it still serves as a useful reference. A key feature of this software architecture is the transition from signal-based software design to a service-oriented architecture (SOA). Rather than a monolithic software image built for a specific ECU with a pre-generated RTE, AUTOSAR adaptive offers a flexible architecture that allows for dynamically updated and deployed applications. Another key feature is its reliance on high-bandwidth networking technologies such as Ethernet:

Figure 1.8 – AUTOSAR adaptive block diagram (credit: AUTOSAR)

The adaptive architecture offers the main set of basic services needed to enable computationally intensive user applications. Rather than defining its own operating system, AUTOSAR adaptive defines an operating system interface layer that is compatible with any POSIX PSE51-compliant operating system. This ensures the portability of the AUTOSAR adaptive implementation across various operating systems and hardware platforms. The POSIX PSE51 profile represents the core set of POSIX APIs, which include support for features such as thread priority scheduling, thread-safe functions, synchronized I/O, real-time signals, semaphores, shared memory, inter-process communication (IPC) message passing, as well as a few utilities. Moreover, AUTOSAR adaptive can be hosted directly on a single hardware platform or as a virtual machine, sharing the platform with other operating system instances. A brief look at the AUTOSAR adaptive software architecture shows several security-related concepts. For one, data read or written to the non-volatile storage through the persistency cluster can be considered security-relevant. Error information reported through the platform health management cluster to enable the user application to take safe action is also worthy of protection. Communication data handled through the communication management cluster is another interesting area to consider when you’re analyzing the security of an adaptive-based system.

Discussion point 6

How about the logs captured by the Log and Trace cluster? What does the cryptography cluster manage, and could these assets be vulnerable? How about the Update and Configuration Management cluster?

Before we finish this section, we must look at how SoC-based ECUs are booted and updated:

Figure 1.9 – Example boot flow from a typical SoC

Unlike the flash bootloader of the MCU-based ECU, SoC-based ECUs rely on a series of bootloaders that load software and calibration data from the external non-volatile memory into DRAM and other internal volatile memory types before handing control over to the respective cores that run the loaded firmware and software. The boot process typically starts with a MaskROM boot partition, which performs the initial hardware configuration, loads the next boot stage, and then jumps to the next boot partition after verifying its integrity and authenticity (assuming secure boot is enabled). This process continues until all firmware is booted in a staged fashion up to the point where the hypervisor kernel is started (if multiple virtual machines are supported). The hypervisor, using a loader utility, then loads one or more guest operating systems in memory and allocates the necessary CPU, memory, and hardware resources to allow the guest operating system to function as an isolated virtual machine. The latter is then responsible for launching its applications and managing its resources. Alternatively, if the operating system is running directly on the hardware (also known as a host OS), then a hypervisor is not needed. The boot sequence is one of the most security-critical execution paths of the ECU because any exploitable weakness in the boot chain can result in the execution of malicious software, which can spell disaster for a safety-critical ECU.

When it comes to reprogramming the firmware and software binaries, different types of update solutions exist, including OTA. AUTOSAR adaptive provides one reference architecture through its update and configuration management cluster. This enables updates through a diagnostic client in addition to an OTA application. As you might have guessed, this functionality is also security-critical as it exposes the software platform to the possibility of malicious software updates and the execution of potentially dangerous code.

Now that we have been introduced to the general hardware and software architecture of ECUs, let’s explore the various ECUs and the domains in which they are grouped based on their related functionality. This will prove useful in later chapters as we analyze the threats that impact such ECUs.

ECU domains

An ECU domain is a grouping of ECUs that collaborate to achieve a common vehicle-level function, such as propulsion control or active braking. Such a grouping improves the efficiency of communication by limiting communication messages to the ECUs that are most co-dependent, thus reducing network congestion caused by non-domain-related messages. As the vehicle architecture evolves, ECU domains may be arranged in different configurations (as we will see in the last section of this chapter). For now, our focus is on understanding the various ECUs that are typically found in a standard vehicle architecture.

Note

The following list of ECUs is meant to be representative of ECUs found in vehicles rather than a comprehensive one with the aim of highlighting the security relevance of each.. Some ECU names can change as OEMs differ in the way they partition vehicle functions across different control units.

Fuel-based powertrain domain

The fuel-based powertrain domain is responsible for producing power in an internal combustion engine (ICE) and transmitting it to the wheels. An attacker who can gain access to any ECU in the powertrain domain may be able to affect the vehicle’s longitudinal motion, which has an obvious safety impact. However, the more common attack target of this domain is engine tuning to illegally increase performance, which has the side effect of increasing vehicle emissions.

Engine control module (ECM)

A vehicle engine’s performance is precisely regulated by the ECM, which pulls data from sensors layered throughout the engine. Among the control functions of the ECM are the engine starting procedure, spark plug ignition, fuel injection, and the cooling process.

Transmission control module (TCM)

The TCM uses different gear ratios to convert a fixed engine speed and torque into a variable driving speed and torque in automatic transmission vehicles. The TCM determines when to shift gears to optimize the vehicle’s performance, balancing factors such as fuel efficiency, power, and engine protection. This is based on a variety of input data, such as engine speed (RPM), vehicle speed, throttle position, and load on the vehicle.

Electric drive powertrain domain

This domain is responsible for battery charging and managing and distributing electric power to the motors, as well as the other electronics that require varying power levels. Like the fuel-based powertrain domain, protecting this domain against security breaches is essential to prevent several hazards, such as erratic vehicle motion control and unsafe battery management. The latter is a unique problem for electric vehicles with the potential to cause catastrophic thermal events if the batteries are not operated safely.

Battery management system (BMS)

The BMS’s primary function is to manage thestate of charge (SoC) and state of health (SoH) of the battery pack by controlling the charging and discharging of the battery cells. It also monitors the battery pack’s status for hazardous conditions such as overheating or high current events to ensure fail-safe action is taken before it leads to a catastrophic failure.

Onboard charger

The onboard charger’s primary role is to convert the AC power provided by the electric vehicle supply equipment (EVSE) into DC power, which can then be used to charge the vehicle’s battery pack. This involves controlling the rate of charging to ensure the battery is charged safely and efficiently.

Additionally, it provides communication between the EVSE and the vehicle’s charging system. This is done using a power-line communication protocol, which allows data to be sent over the electrical power lines. This can be used to negotiate the charging rate based on factors such as the vehicle’s current state of charge, the capacity of the EVSE, and the temperature of the battery [8].

DC-AC converter

In electric vehicles, the high-voltage DC-AC converter, also known as the inverter, converts DC output from the battery pack to AC power for the electric motor(s).

Powertrain electronic control unit (PECU)

This ECU manages the speed and acceleration of the electric motors by controlling the supplied voltage frequency and magnitude.

Chassis safety control domain

The chassis safety control domain encompasses a variety of ECUs and in-vehicle sensors with a clear focus on active and passive safety management. Since the ECUs in this domain are responsible for vehicle safety, it can be argued that this domain is at the top of the list for security professionals regarding what needs to be protected against cyberattacks.

Electronic braking control module (EBCM)

The EBCM is a specialized module that supplies brake pressure to the wheels to achieve several active safety functions, such as ABS, ESC, and automatic emergency braking.

Airbag control module

As a passive safety system, airbags protect occupants from bodily harm in the case of a collision by inflating the airbags through controlled explosions of the squibs embedded in the airbag.

Electronic power steering (EPS)

The EPS is responsible for providing electronic steering assistance to the driver through the actuation of steering motors. The EPS can provide several enhanced driver assistance features, such as lane departure warnings and lane correction.

Advanced driver assistance (ADAS) control module

While several ADAS functions can be integrated within the EBCM and EPS, a dedicated ECU is common in more modern vehicles to achieve higher levels of autonomy.

This module can command the ECM, EBCM, and EPS to control engine torque and apply braking and steering based on the situation at hand. It integrates inputs from multiple sensors, which makes it possible for the ADAS ECU to perform autonomy functions such as automated parking and autonomous highway driving, to name a few.

Interior cabin domain

The interior cabin domain encompasses the comfort features expected from a modern vehicle. At first glance, this domain may seem less critical for security. On the contrary, due to its ability to control physical security, this domain is among the most targeted by attackers today as a breach of this domain translates to vehicle break-in and theft.

Body control module (BCM)

The BCM manages the remote keyless entry and access to the vehicle’s interior. Additionally, it can control seat positions and power windows, light controls, and windshield wipers.

Climate control module (CCM)

The primary function of the CCM is to provide heating and cooling of the cabin. It typically heats the air with a heater core and cools the air with an evaporator and a refrigerant that absorbs heat from the cabin’s air.

Infotainment and connectivity domain

The vehicle functions that engage the driver through the human-machine interface (HMI) are usually grouped in the infotainment domain. ECUs in this domain include the vehicle’s head unit, the central console, as well as the driver-facing instrument cluster. You have probably guessed by now that this domain is also security-critical due to the rich user interfaces it offers.

In-vehicle infotainment (IVI)

The IVI offers entertainment and information delivery to drivers and passengers. The IVI system accepts user input through touchscreens and physical controls and serves the occupants with audio, video, and navigation data. In some cases, the instrument cluster can be integrated with the IVI to provide the driver with a digital display of vehicle information such as speed, fuel level, and more. IVI systems enable vehicle occupants to connect their phones through Bluetooth and USB, making them an attractive target for attackers.

Telematics control unit (TCU)

The TCU is the primary remote access point to the vehicle and therefore is considered high on the list of security-critical ECUs. Among its features are the reception of GPS signals and providing connectivity through cellular and Wi-Fi communication to facilitate OTA updates, as well as the transmission of remote messages such as telemetry data and emergency assistance requests.

Cross-domain

The interconnection of all domains can be viewed as its own domain whose primary objective is providing reliable communication across the previously mentioned domains when message exchange is needed.

Central gateway (CGW)

While some vehicles may rely on individual ECUs to act as gateways between two or more vehicle subsystems, a more common trend is to dedicate a single gateway ECU to perform this function. When a CGW is used, it behaves as an in-vehicle router by allowing ECUs from different network segments to communicate with one another. The CGW translates data across different network systems, such as CAN to CAN, CAN to Ethernet, and CAN to LIN. Due to its access to all vehicle domains, the CGW can play an important role in security by segmenting the network architecture and dropping unwanted traffic.

Discussion point 7

Can you think of some unique assets of the CGW? Hint: Network filter rules are one such asset.

Now that we have explored the different ECUs and ECU domains, it’s time to dive into the networking technologies that enable them to exchange information.

Exploring the in-vehicle network

The plethora of ECUs, sensors, and actuators gave rise to a diverse set of in-vehicle networking technologies. A common goal of these technologies is the need for reliable communication with deterministic behavior under harsh environmental conditions within low-cost constraints. The bulk of the ECUs rely on signal-based communication through automotive bus systems such as Controller Area Network (CAN/CAN-FD), FlexRay, Ethernet, and Local Interconnect Network (LIN). The increased demand for network bandwidth is constantly driving the in-vehicle networks to transition to higher bandwidth solutions such as Ethernet and GMSL.

While securing in-vehicle networks shares common challenges with general network security, the real-time performance constraints and limited payload sizes present unique challenges for many of the automotive networking protocols. In the following section, we will survey the most common automotive networking technologies and touch upon their unique security challenges. Understanding the primary features and common use cases of these protocols will serve as a basis for analyzing the security of the in-vehicle networking protocols in the following chapters.

CAN

It is hard to work on vehicle security without learning about how CAN works and the various security problems it suffers from. CAN is a serial communications protocol that is perfect for real-time applications that require dependable communication under harsh environmental conditions. It has been and remains a popular communication protocol due to its low cost and excellent reliability. CAN is used in a variety of vehicles, including commercial trucks, cars, agricultural vehicles, boats, and even aircraft:

Figure 1.10 – Typical bus layout with multiple CAN nodes sharing a single CAN channel

The CAN physical layer supports bitwise bus arbitration, which ensures that the CAN node transmitting with the lowest CAN ID wins the arbitration, causing the other nodes to wait until the bus is idle before re-attempting transmission. This arbitration scheme can be potentially harmful if CAN nodes misbehave by attempting to acquire bus