Introduction: In the 1950s, the cost of automotive electronics accounted for only 1% of the total cost of a car. However, with the advancement of Internet of Vehicles (IoV) technology, the cost of automotive electronics has increased to 35%. It is expected that by 2030, this figure will continue to rise to 50%. With the arrival of the software-defined vehicle era, the attack surface for automotive cybersecurity has become very broad, mainly distributed across 10 major modules, also known as the top ten vulnerable threat modules. These modules include the In-Vehicle Infotainment (IVI) system, T-BOX (Telematics Control Unit), vehicle gateway, Unified Diagnostic Services (UDS), On-board diagnostics (OBD), Advanced Driver Assistance Systems (ADAS), Telematics Service Provider (TSP), charging network systems, Over-The-Air (OTA) updates, and mobile IoV applications, as shown in Figure 1.
Figure 1 Key Modules of the Internet of Vehicles
▍Scenario 1: In-Vehicle Infotainment System
The In-Vehicle Infotainment (IVI) system refers to the in-car system that provides entertainment information to users. IVI systems use audio/video (A/V) interfaces, touch screens, keyboards, and other types of devices to provide these services. The IVI system typically has some control capabilities over the CAN bus, so attacking the IVI system could lead to remote control of the vehicle.
In 2018, researchers Thijs Alkemade and Daan Keuper from Computest discovered vulnerabilities in the IVI of a certain automotive brand. In some cases, this vulnerability could allow hackers to control critical functions, including turning the car’s microphone on and off, using the microphone to listen to the driver’s conversations, and gaining access to conversation history and the car’s contact list. Most importantly, the researchers stated that attackers could also track the car through its navigation system.
The IVI system is the most susceptible module to attacks, as it generally uses an Android system, so the security risks of the Android system may also occur on the IVI, as shown in Figure 2, which illustrates the main attack surfaces of the IVI (not exhaustive).
Figure 2 Attacks on IVI
▍Scenario 2: T-BOX (Telematics Control Unit)
The T-BOX is connected to the vehicle’s CAN bus internally and connects to the cloud platform and mobile devices externally, serving as a link for information exchange between inside and outside the vehicle, facilitating the transmission of commands and information. A simple schematic of the T-BOX structure is shown in Figure 3.
Figure 3 Structure of T-BOX
For research convenience, we generally need to remove the T-BOX from the car, which requires knowing the T-BOX’s position in the vehicle. The installation position of the T-BOX varies by manufacturer, but it is typically located inside the dashboard, next to the accelerator pedal, under the driver/passenger seats, inside the center console, inside the glove compartment, or inside the gear cover, as shown in Figure 4, which illustrates the installation position of the T-BOX under the driver/passenger seats.
Figure 4 Installation Position of T-BOX Under Driver/Passenger Seats
Since the installation position of the T-BOX is not fixed, the disassembly should be handled by professional mechanics. Therefore, teams working on automotive cybersecurity should ideally have members knowledgeable in vehicle repair, such as the T-BOX development board based on S32K148, as shown in Figure 5.
Figure 5 T-BOX Development Board Based on S32K148
The T-BOX, as an access point in the vehicle, is the core module within the car. Common functions of the T-BOX include remote control, remote diagnostics, OTA, high-precision positioning, near-field control, and V2X. The T-BOX system typically uses a Linux system, so it also carries the security risks associated with Linux, as summarized in Table 1 (not exhaustive).
Table 1 Security Risks of T-BOX
|
|
|
|
|
Remote Communication: Man-in-the-middle attacks, data eavesdropping, tampering, denial
Medium-range Communication: Man-in-the-middle attacks, data eavesdropping, tampering, denial (including Bluetooth, Wi-Fi)
CAN Communication: Data eavesdropping, tampering, denial
I2C/SPI/UART and other serial bus data eavesdropping
|
|
|
Private key extraction, log leakage, sensitive information leakage such as location data
|
|
|
Privilege escalation, reverse shell, buffer overflow, etc.
|
|
|
Firmware extraction, firmware reverse engineering, firmware tampering, etc.
|
▍Scenario 3: Vehicle Gateway
The vehicle gateway is a central hub that securely interconnects and transmits data between many different networks within the vehicle. The core function of the vehicle gateway is to securely transmit data within the vehicle. There may be multiple gateways in a vehicle, which can be centralized gateways and multiple domain gateways. Centralized gateways securely transmit data between the remote information processing control unit (TCU), powertrain, body, infotainment system, smart cockpit, and advanced driver assistance applications. Domain gateways (or domain controllers) have similar functions, facilitating communication between ECUs within their respective domains. Compared to domain gateways, centralized gateways typically require higher processing performance, interfaces, and higher bandwidth network protocols. Figure 6 illustrates how these two types of gateways are implemented in a vehicle.
Figure 6 Types of Vehicle Gateways
The gateway, as the core control device of the automotive network system, primarily functions to provide seamless communication between the in-vehicle network and various electronic control units, enabling information exchange across various functional domains (powertrain domain, chassis and safety domain, body control domain, infotainment domain, remote information processing domain, ADAS domain) through physical isolation between different networks and conversion between different communication protocols. Table 2 provides a summary of the key functions of the gateway (not exhaustive).
Table 2 Key Functions of the Gateway
|
|
|
|
|
Converts data and control information to enable communication between incompatible networks
|
|
|
Routes data at nodes to reach its intended destination, which may be located on different networks requiring protocol conversion
|
|
|
Routes diagnostic messages between external diagnostic devices and ECUs, possibly involving conversion between diagnostic protocols such as DolP and ECU
|
|
|
Filters inbound and outbound network traffic based on rules, prohibiting data transmission from unauthorized sources; advanced firewalls may include context-aware filtering
|
|
|
Captures data from received interfaces for transmission through another interface, used for diagnostics or data logging (storage)
|
|
|
Monitors network traffic for anomalies that may indicate an intrusion
|
|
|
Manages the status and configuration of the network and ECUs connected to the network, supporting diagnostics
|
|
|
Securely processes and stores network keys and certificates
|
|
|
Manages ECUs accessed through the gateway for remote OTA firmware updates
|
The gateway is also the most likely target for cyberattacks on smart vehicles, as it generally operates on an RTOS system, making understanding its instruction set critical. The main attack surfaces of the gateway (not exhaustive) are summarized in Table 3.
Table 3 Attack Surfaces of the Gateway
|
|
|
|
|
|
|
Warning lights and airbags
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
▍Scenario 4: Over-the-Air (OTA) Updates
Over-the-Air Technology (OTA) refers to the process of downloading and updating software through wireless transmission instead of local connections, where the speed and security of updates are crucial. OTA is a necessary foundation for achieving software-defined vehicles, serving as the only remote upgrade channel for intelligent connected vehicle systems and their applications. As the last line of defense for security, common types of OTA include SOTA and FOTA, enabling significant functional updates across powertrain, chassis, driver assistance, infotainment, and body domains.
-
FOTA: Firmware OTA, firmware upgrades aimed at firmware on the vehicle
-
SOTA: Software OTA, application software upgrades aimed at onboard application software.
OTA can add new features to the vehicle, fix vulnerabilities, etc. The traditional method of updating vehicle software is to go to 4S stores to perform software upgrades on the corresponding ECUs via UDS, or to upgrade the infotainment system through USB and other interfaces. With the development of smart vehicles, local upgrades are no longer suitable for the rapidly changing in-vehicle ecosystem, as illustrated in Figure 7.
Figure 7 OTA Process Flow
OTA is mainly divided into cloud and vehicle sides, where the cloud side includes SBOM management, task scheduling, package upgrades, software distribution, upgrade approval, upgrade notifications, upgrade logs, upgrade package uploads, version control, upgrade monitoring, and statistics. The vehicle side includes scheduled checks for updates, manual checks for updates, secure downloads, resumable downloads, subscription to upgrade notifications, upgrade package signature verification, ECU flashing, and upgrade log reporting. It can be seen that the challenges of OTA lie in ensuring security and transmission efficiency, as illustrated in Figure 8.
Figure 8 OTA Attack Surface Diagram
▍Scenario 5: Telematics Service Provider (TSP)
The Telematics Service Provider (TSP) provides the following services in the IoV system in a cloud format to users and vehicles: User information maintenance, vehicle positioning, status monitoring, etc. The TSP function is illustrated in Figure 9.
Figure 9 TSP Function Diagram
The TSP is an important cloud service in the IoV, and it shares the same security risks as general cloud services, which can refer to the OWASP Top 10. The cloud side primarily communicates with other ends via Application Programming Interfaces (APIs), which serve as an intermediary layer for data transfer between applications or processing systems, providing a simple and efficient interface for extending functionality and improving the connected vehicle experience. API security is not unique to automotive cybersecurity; more about API security can refer to the OWASP Top 10 API Security Vulnerabilities, as shown in Table 4.
Table 4 OWASP Top 10 API Security Vulnerabilities
|
API 1: Broken Object Level Authorization
|
|
|
API 2: Authentication Failure
|
API 7: Security Misconfiguration
|
|
API 3: Excessive Data Exposure
|
|
|
API 4: Lack of Resources and Rate Limiting
|
API 9: Improper Asset Management
|
|
API 5: Broken Function Level Authorization
|
API 10: Insufficient Logging and Monitoring
|
▍Scenario 6: On-Board Diagnostics (OBD)
The On-Board Diagnostics (OBD) system is a computer responsible for monitoring the vehicle’s status through a series of sensors. In a typical passenger vehicle, the OBD-II port can be found under the dashboard on the driver’s side; depending on the vehicle type, the port may have 16, 6, or 9 pins, as shown in Figure 10.
Figure 10 OBD-II Port in the Vehicle
OBD includes OBD-I and OBD-II. OBD-I has been the on-board diagnostic standard for vehicles manufactured in California since 1991 to control vehicle emissions in that state. All cars sold in that region must be equipped with OBD-I to detect engine problems and report fault codes. OBD-II became a national standard in the United States in 1996 and has continued to this day. Unlike OBD-I, vehicles equipped with OBD-II support the same type of scanner, and the fault codes themselves have been standardized, although manufacturers may customize some additional specific information. As automotive computers become increasingly complex, manufacturers have added more features to their vehicles’ OBD-II systems, which can be viewed using OBD-II scanners to access real-time diagnostic data, connect to the vehicle’s computer, etc., as shown in Figure 11. Through OBD-II, diagnostic services can be provided to external testing tools (OFF Board), and self-diagnosis of the vehicle during operation can be achieved.
Figure 11 OBD-II Diagnostics
The most significant improvement from OBD-I to OBD-II is that all OBD-II vehicles have the same type of port, sending the same type of data in the same manner. In other words, one can purchase an OBD-II scanner and obtain useful information from any vehicle produced by any manufacturer.
OBD-II includes a series of standardized diagnostic trouble codes (DTCs). DTCs are codes generated and stored by the Powertrain Control Module (PCM) when the OBD-II system indicates a fault. In short, when your vehicle’s system diagnoses a problem, it sends a code indicating the specific fault. According to the fault manual published by the Society of Automotive Engineers (SAE), one can check where the problem lies through the DTC codes, and there are many tools available to insert the OBD-II connector and access the DTCs, as shown in Figure 12.
Figure 12 Handheld Scanning Tool
Now, remote diagnostic functions can also be based on OBD-II diagnostic data, such as engine RPM, vehicle speed, fault codes, etc., which can then be uploaded to the cloud via remote information processing devices like the T-BOX, allowing for vehicle monitoring and remote diagnostics. It was also mentioned that in 2021, OBD-II interface attacks accounted for 5.4%; the attack paths for OBD-II are illustrated in Figure 13, which will be elaborated on later.
Figure 13 OBD-II Attack Path
▍Scenario 7: Unified Diagnostic Services (UDS)
Today, cars on the road contain hundreds of ECUs, each performing specific functions, which increases system complexity and necessitates more effective methods for testing and diagnosing vehicle systems in the event of a fault. The main difference between Unified Diagnostic Services (UDS) and OBD lies in its “unification”; specifically, it is aimed at all UDS of the entire vehicle, whereas OBD focuses on emission system diagnostics. Over time, many diagnostic protocols have been developed, such as KWP 2000, ISO 15765, and K-Line, for vehicle diagnostics. Therefore, to ensure universal compatibility, original equipment manufacturers and suppliers have agreed to rely on a standard protocol called Unified Diagnostic Services. UDS is the latest automotive vehicle diagnostic protocol used globally, and it complies with the ISO-14229 standard.
UDS is not only used for remote diagnostics but also for ECU flashing, which is frequently used in OTA upgrades for non-smart ECUs. UDS flashing refers to implementing service software ECU in non-volatile memory via UDS, where the ECU includes the Boot Manager, Application Software, and Reprogramming Software, as outlined in the ECU flashing execution process given by ISO 14229-1, as shown in Figure 14.
Figure 14 ECU Flashing Execution Process Based on UDS
The rapid development of OTA has raised higher requirements for ECU flashing, making it necessary to adapt to various extreme situations, thus increasing the importance of security. If security measures are inadequate, ECUs may suffer attacks such as deception attacks, password brute forcing, session hijacking, man-in-the-middle attacks, and privilege escalation.
▍Scenario 8: Advanced Driver Assistance Systems (ADAS)
Safety is a key design objective for Advanced Driver Assistance Systems (ADAS) and Automated Driving Systems (ADS). This book discusses only ADAS, and developers of ADAS need to ensure that they have considered and analyzed all aspects of the issues and provided measurable evidence to demonstrate that their functions are safe, while upcoming standards and regulations do not describe any specific methods. Automotive cybersecurity is not only a key requirement but also a prerequisite for ADAS and ADS. The layered architecture of general ADAS is illustrated in Figure 15.
Figure 15 Layered Architecture of ADAS
Ensuring the cybersecurity of ADAS and ADS is a challenging task, as any wireless interface may become a potential attack medium. ADAS is based on a complex mix of hardware and software, often integrating vehicle and V2X communication. Advanced driving assistance systems and automated vehicles deploy various sensors such as ultrasonic, radar, cameras, and LiDAR. For instance, camera sensors apply numerous image analysis, sensor fusion, and perception algorithms, especially those based on neural networks and deep learning systems, which are susceptible to cyberattacks. The attack surfaces of ADAS are illustrated in Figure 16.
Figure 16 Attack Surfaces of ADAS
▍Scenario 9: Charging Network Systems
Range anxiety is currently the biggest concern for users purchasing electric vehicles and is a key issue that the electric vehicle industry must address. With the development of the charging station market, different companies focus on specific areas of the charging ecosystem, as illustrated in Figure 17.
Figure 17 Charging Ecosystem
The charging ecosystem consists of the following parts: automotive manufacturers (OEMs), electric vehicles (EVs), electric vehicle charging stations (EVCS), charging point operators (CPOs), and electric vehicle service providers (eMSPs).
To better understand charging system security, we must first comprehend charging-related technologies. Figure 18 provides a more intuitive understanding of how current flows within electric vehicles.
Figure 18 Simplified Block Diagram of Current Conversion in Electric Vehicles (Image Source: Keysight E-Mobility Design and Test Technologies)
To understand the principle of the above image, one may need to clarify the following questions, which will be detailed in this book.
-
How is the charging current delivered to the electric vehicle?
-
How is the charging process controlled?
-
How do charging stations communicate, and what are their communication protocols?
-
How is wiring and installation performed?
Charging equipment is typically controlled via cloud platforms and mobile applications, thus having remote access and vulnerable APIs. An analysis of over 100 publicly reported automotive network-related incidents since early 2022 by Upstream concluded that electric vehicle charging has been identified as the number one emerging attack medium. These security vulnerabilities may affect all components of the electric vehicle charging network, and based on the vulnerabilities mentioned above, the security risk categories for electric vehicle charging equipment are summarized as follows.
▍Scenario 10: Mobile IoV Applications
As previously described, the process of manipulating vehicles via mobile apps is currently offered by most IoV manufacturers to vehicle owners. Using mobile applications, users can control door locks, adjust windows, and more via Wi-Fi, Bluetooth, and cellular networks. The use cases for mobile applications are illustrated in Figure 19, allowing users to check the vehicle’s real-time location and historical trajectory.
Figure 19 Use Cases for Mobile Apps
The security issues of mobile apps themselves exist not only in the IoV but also amplify security hazards by allowing vehicles to be controlled through mobile devices. The following are the attack surfaces for mobile IoV applications.
-
-
-
-
-
-
Reverse-engineered counterfeit applications
-
Improper session handling
As seen above, automotive cybersecurity involves web security, protocol security, wireless security, kernel security, mobile security, firmware security, hardware security, etc. Any of these may be a weak point, so strengthening automotive cybersecurity is more about laying a solid security foundation to avoid security shortfalls. With the acceleration of innovation in the automotive industry, smart vehicles are transitioning to automated driving, and each new advancement may introduce a new attack surface, necessitating ongoing security investment.
Open and Inclusive, Collaborating for Success
Sharing Opportunities and Achievements in Industrial Transformation
