Among the three major areas of automotive electronics and software security—anticipated functional safety, functional safety, and information security—anticipated functional safety remains at the theoretical level and is insufficient to support practical implementations in enterprises, so it will not be discussed in depth here. Functional safety, on the other hand, has already gained significant recognition and is now entering a phase of gradual stabilization.

In recent years, information security has gained increasing popularity and shows broad prospects. However, at present, its system integrity and implementation maturity still lag behind functional safety and require further development.

Nevertheless, one aspect where information security surpasses functional safety is its mandatory nature backed by law, akin to the relationship between ethics and law.

Against this backdrop, this article will provide a comprehensive explanation of the basic concepts, regulations, standards, and technical framework of automotive information security, spanning approximately 10,000 words.

1. Concept of Information Security

When discussing automobiles today, the term 'intelligent' is often appended, resulting in the phrase 'intelligent automobile.' However, a more academic and comprehensive term would be 'intelligent and connected vehicle,' which further divides into 'intelligent' and 'connected' components.

According to GB/T 44373-2024 Intelligent and Connected Vehicles: Terms and Definitions, intelligent functions are defined as 'environmental perception, intelligent decision-making, automatic control, etc.,' while connected functions refer to 'the use of communication technology to enable information exchange between the vehicle and the outside world (including other vehicles, pedestrians, the cloud, infrastructure, etc.).'

Our discussion today primarily falls within the realm of connected functions. Although 'network security' is more intuitive in Chinese for cognition and communication compared to 'information security,' the latter term is more commonly used in domestic automotive industry standards. In daily communication, the two can be considered equivalent.

Let's delve deeper into the definitions of information security and information security systems:

Automotive Information Security: The state in which the electronic and electrical systems, components, and functions of a vehicle are protected, safeguarding its assets from threats (source: GB/T 40861-2021 General Technical Requirements for Automotive Information Security).

Automotive Information Security Management System: A risk-based systematic approach encompassing organizational processes, responsibilities, and governance to address risks associated with vehicle cyber threats and protect vehicles from cyber-attacks (source: GB/T 44373-2024 Intelligent and Connected Vehicles: Terms and Definitions).

This understanding is still relatively broad, so let's continue.

2. Overview of Functional Safety

In the discussion of automotive safety, passive safety in the traditional sense enjoys the widest consensus and is most easily understood by consumers. However, passive safety is already highly mature and rarely debated.

Therefore, functional safety, which may be less understood by the general public but is richer in theoretical frameworks and practical experience, has effectively become the core safety focus at present (note: the present focus).

Let's start with functional safety to introduce the connotation of information security.

2.1 Understanding Safety in Functional Safety

There are three key points to consider here:

(1) Safety Means Sufficiently Low Risk

First, there is no absolute safety in this world. Safety is relative to the level of risk; as long as the risk is sufficiently low, it can be considered safe, as illustrated in Figure 1.

One may further ask where the boundary between high and low risk lies. It lies in the minds of the 'common people.' However, a more precise expression for 'common people' would be the State of the Art, referring to current technological capabilities.

In other words, the goal of functional safety is to reduce risks to a level acceptable to the general public. This has significant ethical implications and is a topic that current autonomous driving systems must consider.

Figure 1: Meaning of Risk and Safety

(2) Inherent Safety

Second, although there is no absolute safety, there is inherent safety, which eliminates inherent risks. For example, when I was young, there was a railway track not far from my home that crossed a path near our house. This not only caused frequent close encounters between pedestrians, vehicles, and trains but also became a playground for us children to press coins and nails under the tracks, making it very dangerous.

Later, someone installed wooden planks between the tracks to facilitate quick passage and added simple railings. When a train approached, red warning lights would illuminate...

However, this was still insufficient, as evidenced by a tragic accident that occurred. Eventually, a small tunnel was dug under the tracks, and the tracks near the intersection were fenced off. Although rainwater would often accumulate, no further accidents were reported...

This small example illustrates two types of safety: digging a tunnel under the tracks is an example of inherent safety that fundamentally avoids risks, while installing wooden planks, railings, and warning lights falls under functional safety when inherent safety cannot be achieved, as shown in Figure 2.

Figure 2: Inherent Safety vs. Functional Safety

(3) People-Oriented

Third, functional safety is people-oriented, focusing on personal injury, including drivers, passengers, pedestrians, and occupants of other vehicles, while not concerning itself with property safety.

2.2 Objects of Functional Safety

The ISO 26262 standard clearly states that functional safety applies to the electronic and electrical systems in automobiles, specifically systems that include both software and hardware, and does not cover mechanical, hydraulic, or chemical domains.

It is important to note that functional safety addresses the safety loops of the entire control system and is vehicle-oriented, not component-oriented. It typically involves at least one sensor and one actuator. The most typical example is the ECU system.

Moreover, only products that are determined to involve 'functional safety' after analysis will proceed to further functional safety development. These include systems or ECUs related to braking, steering, parking, cruising, airbags, seat belts, lighting, body control, suspension control, motor control, battery management, etc.

Entertainment systems such as so-called smart cockpits are generally not involved or only involve a small number of components (e.g., instruments) related to low-level functional safety.

2.3 Issues Addressed by Functional Safety

Although it contains the word 'functional,' functional safety does not address issues of insufficient functionality or poor performance (which fall under SOTIF). Instead, it does not alter the nominal characteristics of the system but rather guides us on how to achieve safety goals by reducing system failure risks, ultimately reducing harm to humans.

For example, in electronic handbrakes, functional safety aims to achieve the safety goal of 'preventing unexpected brake failure,' focusing on the diagnosis, monitoring, and handling of failures in any part of the electronic handbrake loop. It does not involve increasing the clamping force of the caliper to change functionality or performance.

Furthermore, where do the failures addressed by functional safety originate? There are two main sources:

First, humans have limitations, so during product and project development, they may introduce 'systematic failures' into software or hardware, such as setting the wrong parameter values or directions during calibration. Theoretically, these failures have definite causes and can only be eliminated through process execution or design changes.

Second, objects are imperfect, and hardware may experience 'random hardware failures' that conform to probability distributions, such as electromagnetic interference, shock and vibration, high-temperature aging, etc. These failures are unavoidable and unpredictable, stemming from the material and process properties of semiconductors.

2.4 Handling Failures in Functional Safety

Failures are important, but not the most important aspect. We should focus on the risks that failures pose to personal safety. Risks are also crucial, but they are not the ultimate concern because there is no such thing as 100% zero risk or safety. Therefore, we must identify unacceptable risks and reduce them to acceptable levels through safety mechanisms (processes and technologies). Less precisely, this is referred to as sufficient 'functional safety.'

In essence, the core purpose of functional safety methodology is to reduce unacceptable risks to acceptable levels by adding safety mechanisms.

3. Understanding Information Security in Comparison to Functional Safety

This section examines the characteristics of information security by comparing it to functional safety.

3.1 From 'Hurting People' to 'Hurting Hearts'

Functional safety has a clear focus: harm to people, limited to physical harm, which can be called 'hurting people.' Why is information security described as 'hurting hearts'? This leads us to a core concept of information security mentioned in Section 1—'assets,' the damage to which can cause 'heartache.'

(1) Assets

In the Chinese context, when we mention assets, money easily comes to mind. While money is partially related to assets, it cannot directly replace the broader concept of assets used here.

Next, let's delve into the academic definitions of assets and related concepts in ISO/SAE 21434.

Asset: An object (tangible or intangible) that has value or contributes to value and possesses one or more attributes worthy of protection (i.e., information security attributes), the violation of which may lead to one or more adverse consequences (i.e., damage scenarios).

Information Security Attributes: Include confidentiality, integrity, and availability. Confidentiality ensures that information is not disclosed, such as personal vehicle account information; integrity ensures that information is accurate and cannot be unauthorizedly modified; availability refers to the effective use of authorized users. Note that different models may define information security attributes differently, and this is just one example.

Damage Scenario: Involves a vehicle or vehicle function and causes adverse consequences for road users such as drivers, passengers, pedestrians, and vehicle owners.

Threat Scenario: A potential cause that results in the violation of one or more information security attributes, ultimately leading to a damage scenario.

(2) Purpose of Information Security

Correspondingly, let's identify the issues that information security addresses. Automotive E/E systems or components (i.e., items) possess assets of value to humans. When certain attributes of these assets are compromised, they can cause adverse consequences for humans.

The role of information security is to protect the attributes of assets from being compromised as much as possible, thereby reducing the risk of adverse consequences to an acceptable level, so that relevant individuals are not overly 'heartbroken' (hurting people is also a form of heartbreak, meaning that information security also concerns harm to humans), as shown in Figure 3.

Figure 3: Basic Purpose of Automotive Information Security

3.2 From 'HARA' to 'TARA'

Let's revisit the development logic of functional safety. Generally, it identifies risk levels based on hazardous events, defines ASIL and corresponding safety goals, thereby establishing the overall goals and standards for functional safety. This is followed by conventional V-model development through breakdown. For functional safety, HARA (Hazard Analysis and Risk Assessment) is the core incremental method.

Now, let's turn to information security. The overarching goal is to control the occurrence of harmful events to humans at a low level. Therefore, information security introduces a core methodology—TARA (Threat Analysis and Risk Assessment).

Upon seeing this term, one immediately notices the word 'threat,' which extends from the concept of threat scenarios. It can be analogously compared to hazards in functional safety, representing potential dangers (ISO 26262 also explicitly states that information security threats can be analyzed as hazards from a functional safety perspective to support hazard analysis, risk assessment, and the integrity of safety goals). The aforementioned damage scenarios are equivalent to harm in functional safety, representing actual consequences resulting from potential dangers. The subsequent risk assessment is literally identical to HARA (although the specific methods may differ).

In comparison, TARA and HARA have a highly intertwined mapping relationship, with fundamentally consistent methodological logic. Similar to HARA, TARA is the primary incremental content for information security, and it can also guide the development of information security.

At this point, we have a vague outline of what automotive information security entails, but many details have yet to be expanded, such as the sources of threats, the primary components of assets, the understanding and protection of confidentiality, integrity, and availability within attributes, the impacts of adverse consequences, their probabilities, the corresponding risk levels, and how TARA ties these elements together... These questions will be addressed below.

4. TARA

TARA is primarily divided into seven parts, which will be expanded upon one by one. However, it is important to note that in ISO/SAE 21434, the overall process does not have a clear linear order. Each part, including the seven components of TARA, has a certain degree of independence, with inputs and outputs intertwined.

4.1 Asset Identification

Asset identification has a certain degree of ex post facto and dynamic nature, meaning that assets are not clearly listed in a single list (although there may be some references, they are not the only source). Identification requires analysis, confirmation, and updating.

What are other channels for identification? Generally, assets can be identified in item definitions, derived from threat scenarios, and judged based on the impact ratings of adverse consequences.

Of course, such general statements may be confusing. Let's understand this logic through an example.

First, let's recall the definition of assets: an object (tangible or intangible) that has value or contributes to value and possesses one or more attributes worthy of protection, the violation of which may lead to one or more adverse consequences.

(1) Potential Asset Identification

Therefore, the first step is to roughly delineate a range of valuable objects when identifying the research object in the item definition. For example, when analyzing the brake CAN message in software, its tampering may result in functional deficiencies. Clearly, this has value, so it can be classified as a potential asset.

(2) Threat and Damage Scenario Identification

Furthermore, the three attributes of assets—confidentiality, integrity, and availability—were mentioned. Corresponding to the tampering of the brake CAN message, it can be classified as a violation of integrity, which will first create a threat scenario.

So, what does this threat scenario lead to? It may cause brake failure, resulting in vehicle damage or even fatalities. This consequence is the so-called damage scenario.

(3) Impact Rating

However, is the impact of this damage scenario really that severe? We need to conduct an impact rating. If the rating indicates that the impact is indeed severe, then the 'brake CAN message' can be considered an asset or an asset that warrants further information security activities.

Therefore, asset identification corresponds to a process of cognition. To understand what assets are more concretely, let's look at some typical examples, as shown in Table 1.

Table 1: Examples of Information Security Assets

As can be seen, these assets are related to money but not intimately so.

Finally, to summarize, the content that needs to be output in this section includes: assets, information security attributes of assets, and the "harm scenarios" caused by violations of relevant attributes.

4.2 Threat Scenario Identification

Threat scenarios are the potential sources of harm scenarios, and their identification is the upward tracing of technical root causes.

Generally, it is necessary to reflect what information security attributes are violated and the reasons for the violation. For example, tampering with EPS steering assistance CAN messages can lead to the violation of CAN message integrity, resulting in abnormal steering assistance functions.

4.3 Impact Rating

Impact rating is essentially an assessment of harm scenarios, which is a process of exploring the consequences downward.

As we mentioned earlier, assets are not just money, and impacts are not just financial losses. According to the SFOP model, impacts can be divided into four categories:

safety (personal safety), financial (property), operational (vehicle operation), privacy (personal privacy)

Of course, there can be other reasonable classification methods, but a consensus needs to be reached within the development supply chain.

From a level perspective, each category can be expanded into the following four levels:

severe, major, moderate, negligible

Among them, the safety aspect is comprehensively and detailedly discussed in functional safety and can be fully referenced. If necessary, it can also be comprehensively defined in combination with exposure and controllability. Relatively speaking, the safety evaluation will be more comprehensive. For the remaining categories, most of them are based on experience and team evaluation models.

4.4 Attack Path Analysis

At this point, we have not yet discussed another important factor: who exactly caused this consequence? Information security is essentially a defense contest between people. We need to know how attackers execute attacks and create threat scenarios. This series of premeditated and deliberate actions by attackers is the concept of attack paths. For example, in the example of threat scenario identification in Section 2, a hacker forwarding a reverse assistance signal through a gateway is an attack path.

Formally, the analysis of attack paths can be carried out in a "top-down" and "bottom-up" manner.

Top-down starts with the threat scenario and considers different possible ways to achieve it, thereby inferring the attack path. The bottom-up approach is to construct attack paths from identified vulnerabilities.

4.5 Attack Feasibility Rating

A basic strategy in information security is to make the cost of an attack greater than the benefits of the attack. If this situation is achieved, it will generally significantly reduce the attacker's willingness. Attack feasibility refers to the cost of successfully implementing an attack path, which is also divided into four levels: high, medium, low, and very low.

Specific methods generally include methods based on attack potential, methods based on CVSS (Common Vulnerability Scoring System), and methods based on attack vectors, which are briefly described below.

(1) Method based on attack potential

Attack potential depends on five important parameters, namely:

Required attack time: The duration for an expert to identify a vulnerability and develop an exploit. Required expertise: The difficulty of each step of an attack obviously differs between ordinary individuals and professionals. The level of understanding required for the product or component: Some attacks may only be possible with inside help. Window of opportunity: The attackable time period, such as the time between vulnerability disclosure and patching or the duration of a Bluetooth connection. Required equipment: Whether specialized tools are needed to discover and execute the attack.

After determining and summing the values of each parameter, the rating is then performed according to a predefined value range.

(2) Method based on CVSS

In 21434, the exploitability metrics of the CVSS assessment framework are selected to evaluate the feasibility level, which is calculated by substituting the values of the following four parameters into a specific formula.

Attack vector: Evaluated under the premise that the attack feasibility rating increases with increasing physical or logical attack distance, such as the increasing feasibility of attacks from JATG ports, USB drives, Bluetooth, to mobile networks. Attack complexity: The ease or difficulty of the conditions required for an attacker to successfully exploit a vulnerability. Privileges required: The privilege level and number of authorizations required by the attacker when exploiting a vulnerability. User interaction: The more interaction required between the attacker and the victim, the lower the attack feasibility, such as requiring the user to click on a vehicle infotainment system link prompt.

(3) Method based on attack vectors

Simply using attack vectors for evaluation is also a straightforward and brutal method, often used for rough estimates in the early stages of a project or other stages where sufficient information is not yet available.

4.6 Risk Value Determination

After determining the impact level of harm scenarios and the attack feasibility level of related attack paths, it is best to have a comprehensive indicator to represent the risk level of information security threat scenarios, which is the risk value determination discussed here. For example, it can be determined through risk matrices based on empirical values or weighted formulas.

In addition, one threat scenario may correspond to more than one harm scenario, and one harm scenario may continue to have multiple impact categories. We can determine a separate risk value for each impact category derived from one threat scenario.

However, when a threat scenario corresponds to multiple attack paths, it is necessary to perform aggregate analysis on the dimension of attack feasibility. For example, the highest attack feasibility rating among the corresponding attack paths can be assigned to the threat scenario, as we are concerned here with the feasibility and likelihood of consequences, which depend on the shortest plank in the barrel.

4.7 Risk Response Decision Making

Based on the risk value, the next response strategy needs to be determined, generally divided into the following four types:

Risk avoidance, such as removing a function. Risk mitigation, such as strengthening the security control process or fixing vulnerabilities. Risk transfer, such as through insurance purchase or contract signing. Risk acceptance.

Since the last two types do not address the risk itself, the risk of the entire supply chain is not addressed, so specific declarations or supervision are required.

Here, we will find a situation where the risk value actually changes with the implementation of response measures.

So, what target line do we use to determine what to do and to what extent, similar to ASIL in functional safety and the two-tier acceptance criteria in expected functional safety? Information security has added a concept logically similar to ASIL—CAL (Cybersecurity Assurance Level), which will serve as a fixed indicator to guide information security activities and their stringency.

5 Information Security-Related Regulations and Standards

The content of Sections 3 and 4 is referenced from the well-known 21434 from an engineering perspective, but the information security system certainly does not stop there. This section will provide a summary.

5.1 International Typical Regulations and Standards

Frankly, like many other fields, foreign countries are still ahead of us in establishing information security regulations and standards. Among them, the most typical and popular are R155, R156, and 21434.

(1) R155

R155, or "Uniform Provisions Concerning the Approval of Vehicles with Regard to Information Security and Cybersecurity Management Systems," is the world's first mandatory regulation for automotive information security. It is Regulation No. 155 issued by the World Forum for Harmonization of Vehicle Regulations (WP29) of the United Nations Economic Commission for Europe (UNECE) and came into effect on January 21, 2021, marking the entry of automotive information security into the "rule of law" era.

R155 only applies to contracting parties to the 1958 Agreement, including 62 countries such as EU member states, Japan, South Korea, and Australia. Since China has not yet joined this agreement, domestic automakers will not be directly affected, but they still need certification if they plan to export to these countries.

The core requirements of R155 include two major parts:

OEMs must establish and implement a Cybersecurity Management System (CSMS), which mainly includes security policies and objectives, risk management processes, a secure development lifecycle, and secure operations and maintenance. It aims to address risks related to cyber threats and protect vehicles from cyber-attacks.

OEMs must pass Vehicle Type Approval (VTA), which mainly requires two conditions: possessing a CSMS certificate of conformity and demonstrating that the CSMS has been effectively implemented for the vehicle project.

This means that the legal responsibility for R155 lies with the OEM. Of course, the OEM will pass these requirements on to the entire supply chain.

In addition, there is a transitional period after the regulation comes into effect, and there may be variations in specific implementation among countries. The EU timeline is relatively representative, as follows:

Applicable to new vehicle types from July 1, 2022, with exemptions for minor facelifts of existing architectures without electronic and electrical changes.

Applicable to all vehicle types from July 1, 2024, meaning that older models still in production also need to be upgraded to comply.

During the period from 2022 to 2024, for the launch of new models based on existing architectures that cannot be developed according to CSMS, VTA should demonstrate that cybersecurity has been fully considered during the development phase.

From January 1, 2025, the transitional period ends, requiring all OEMs to obtain CSMS+VTA certification for all vehicle models, marking the beginning of full implementation and strict supervision of the regulation.

(2) R156

R156, or "Uniform Provisions Concerning the Approval of Vehicles with Regard to Software Updates and Software Update Management Systems," requires OEMs to establish a comprehensive software update management system to ensure safe and reliable updates of automotive software, including software update processes and strategies, pre-update verification, monitoring during updates, and post-update verification.

Like R155, this regulation also came into effect on January 22, 2021 and applies to contracting parties to the 1958 Agreement, with certification also requiring Software Update Management System (SUMS) certification + Vehicle Type Approval (VTA). However, regarding the implementation timeline, only the EU's official implementation in July 2022 is known, and no other transitional time points have been defined.

(3) 21434

ISO/SAE 21434, or "Road Vehicles - Cybersecurity Engineering," is the first international standard in the field of automotive cybersecurity. It was officially published on August 31, 2021 and covers the entire lifecycle of automobiles, including all processes such as conception, development, production, operation and maintenance, and decommissioning.

Naturally, one may ask about the relationship between R155 and 21434. Overall, R155 only specifies what to do and provides broad requirements at a conceptual level without guidance on how to do it. In contrast, 21434 can serve as a standard to guide our specific practices to meet R155 requirements.

5.2 Domestic Regulatory and Standard Framework

In China, at the highest level, we have national laws, including the Cybersecurity Law, Data Security Law, Personal Information Protection Law, and Cryptography Law.

On this basis, the Ministry of Industry and Information Technology issued the "Guidance on the Construction of the Standard System for Vehicular Network Cybersecurity and Data Security" on February 25, 2022, systematically guiding the establishment of the framework for the information (cyber) security standard system (as shown in Figure 4). As of the issuance of the guidance, 103 regulations and standards had been issued or were under development, as shown in Table 2 (the status at the time of the guidance's issuance; there have been changes since then, so only the content of the items is for reference).

Among them, the most noteworthy are "GB 44495-2024 Technical Requirements for Vehicle Cybersecurity" and "GB 44496-2024 General Technical Requirements for Automotive Software Updates," similar to R155 and R156. Both were issued on August 23, 2024, and will be implemented on January 1, 2026, as mandatory standards in China.

Figure 4 Framework of the Standard System for Vehicular Network Cybersecurity and Data Security

Table 2 Detailed List of Standards Related to Vehicular Network Cybersecurity and Data Security

5.3 Summary of Important Issued Regulations and Standards

A summary of the important issued regulations and standards is presented in Table 2.

Table 2 Major Issued Regulations and Standards for Automotive Cybersecurity

6 Automotive Cybersecurity Protection Model and Common Risks

Automotive cybersecurity is a vast and lengthy system, encompassing a broader scope than traditional automotive software engineering.

To obtain an overall perspective, we can categorize the objects to be protected or potentially at risk in cybersecurity, which can be divided into in-vehicle systems, vehicle-to-external communications, and external systems, as shown in Figure 5. In this article, we focus on in-vehicle systems and vehicle-to-external communications, which are more closely related to automobiles.

Figure 5 Model of Objects to Be Protected in Cybersecurity

6.1 In-vehicle systems

In-vehicle systems are divided into software systems, electronic and electrical hardware, in-vehicle data, and in-vehicle communication (i.e., CAN, LIN, Ethernet communication between in-vehicle systems and components). Common information security threats are summarized as follows.

ECU tampering: disassembling binary files, changing program code, etc. Updating ECUs with software produced by non-manufacturers. Poisoning map databases. Using or installing malware. Abusing privileges to eavesdrop and inject new messages. Remote code execution. Password/key attacks. Bus-off attacks. Users accessing software systems through unauthorized means. Illegally accessing systems by exploiting inadequate user authentication or unmodified default account passwords. Using insecure remote access or controlling components for remote illegal access. Attacking systems using hidden services and ports. Manipulating software upgrade confirmation mechanisms. Replaying legitimate upgrade packages. Lack of source legitimacy and integrity checks during software upgrades. Lack of information security logs or other event recording systems. Lack of a trusted boot mechanism in software systems. Lack of anti-brute-force measures in access authentication mechanisms. Not verifying the format validity of received input commands. Illegally entering software systems through "backdoors". Lack of early warning and monitoring mechanisms. Chips lack independent information security storage space. Attacking the information security storage of chips. Attacking the trusted boot mechanism of chip-based software systems. Directly accessing the hardware JTAG debugging interface for illegal debugging. Attacking physical devices or exploiting physical leaks. In-vehicle systems lack effective protection measures for storing security-critical parameters. In-vehicle systems lack effective access control measures for stored data. In-vehicle software involves improper protection of security-critical parameters, leading to leaks. In-vehicle systems lack effective protection for configuration parameters. Vehicles sharing the same security-critical parameters lead to code injection attacks.

6.2 External vehicle communication

External vehicle communication refers to communication between the entire vehicle and external terminals, specifically divided into long-distance external vehicle communication (cellular mobile communication, satellite navigation, etc.) and short-distance external vehicle communication (Bluetooth, NFC, Wi-Fi, etc.). Common information security threats are summarized as follows.

(1) Long-distance communication

Eavesdropping on or modifying communication data between two nodes. Sniffing and taking over established sessions. Flooding communication channels with massive messages to exhaust resources. Resending previously unexpired signals. Message tampering, deleting or changing data content. Pretending to be a legitimate node to send false messages. Forging network identifiers and passing them to legitimate nodes. Non-repudiation attacks: denying communication behavior. Key/certificate duplication: using duplicate keys or certificates. Sending extreme routes to overflow routing tables. Forcing continuous ACKs and resynchronizing TCP connections. Modifying routing information or changing the number of forwarded route requests. Broadcasting spoofed packets containing malicious node routes. Creating fake route nodes to consume packets. Suppressing or modifying packets from certain nodes only. Exploiting vulnerabilities to confuse routing mechanisms. Creating routing loops to forward packets rather than the optimal route. Rapidly forwarding route requests to increase the probability of discovering attacker routes. Injecting arbitrary messages into the network or bus. Creating and sending false messages. Finding passwords, keys, etc., to grant access. Stealing personal data or network information. Using time differences to infer sensitive information. Implementing communication spoofing on vehicles: forging base stations, road-based communication facilities, etc. Performing DoS/DDoS attacks using communication channels. Setting up wireless jammers to interfere with signals. Communication encryption keys being stolen or communicated in plaintext. Communication channel integrity protection keys being stolen or not protected. Sending forged service denial response messages. Attacks on certificate issuance systems.

(2) Short-distance communication

Interference attacks on cameras, causing cameras to "go blind". Blinding attacks and spoofing attacks on LiDAR. Ultrasonic jammer interference. Radar interference attacks. GPS interference and spoofing. Ultrasonic and radar spoofing attacks. Camera spoofing attacks. Wi-Fi-related attacks: port attacks, weak password attacks, protocol stack attacks, intranet penetration, man-in-the-middle attacks, phishing attacks. Bluetooth-related attacks: data encryption attacks, critical business authentication flaws, protocol stack vulnerabilities, replay attacks. Radio signal interference and remote control key interference. Location tracking attacks and trajectory tracking attacks. In-vehicle networks do not use partitioned information security isolation methods. In-vehicle network connections lack authenticity and integrity verification mechanisms. In-vehicle network systems lack anti-DDoS or traffic control measures. Listening to the vehicle bus through the OBD interface or by implanting malware. Forging access control commands and car keys. Forging short-distance communication messages. Intruding into in-vehicle systems through contact communication interfaces. Attacks on in-vehicle wireless local area communication.

78 Information Security Design Principles

There are many technical means of information security, which are not expanded upon in this article. Instead, this article summarizes the principles from a design perspective.

Principle of Business Applicability: The information security design of a product should be tailored to the actual needs of the business or functional environment, considering the impact on the normal use of the business or function.

Principle of No Backdoors: Software systems should not have backdoors.

Principle of Minimal Functionality: More complex systems have more potential attack surfaces, so unused software components, protocol ports, and ECU hardware debugging interfaces should be disabled or removed; pin information of devices should not be exposed.

Principle of Minimal Authorization: Products' access and information processing activities should only be granted the minimum necessary permissions.

Principle of Separation of Privileges: Information processing activities for important protection objects should have two or more privileges, with each privilege being separate and granted individually.

Principle of Default Settings: Products should complete default information security settings that minimize and simplify user information security setting requirements, ensuring security under default settings as much as possible.

Principle of Fail-safe: Even if the system crashes, the information security mechanism remains effective.

Principle of Mistrust: Third-party software, hardware, and data must undergo legitimacy checks before use.

8 Six Vulnerable Product Categories in Vehicles

In daily work, we tend to focus more on products. This section summarizes vulnerable product categories and examples of attack methods.

8.1 Smart Cockpit System

Controlling smart cockpit-related systems: Attackers can control key vehicle functions through the IVI system, such as turning the microphone on and off, eavesdropping on driver conversations, obtaining call history and car contacts, posing a serious threat to the privacy and security of car owners.

Gaining IVI Control: By connecting to the in-car system via ADB (Android Debug Bridge), attackers can easily install malware, modify system settings, view sensitive information, and thus gain complete control over the vehicle.

Remote Attacks: Attackers can exploit vulnerabilities in cloud services or social media software to send malicious files or messages to car owners. Once clicked or downloaded, the malicious code executes in the IVI system, leading to remote control of the vehicle or data leakage.

8.2 Intelligent Connected Vehicle System (T-BOX)

Man-in-the-Middle Attack: Attackers can access various ECUs through the unisolated domain control gateway by entering the in-car network via the vehicle's Wi-Fi hotspot, thereby controlling the vehicle.

Firmware Attack: Attackers can extract, reverse engineer, and tamper with the firmware of the T-BOX to control it and even further control the vehicle.

CAN Bus Injection: By sending malicious data frames to the CAN bus, attackers can simulate the start command of the power domain to control the power system, allowing the vehicle to be illegally started or driven.

8.3 Central Gateway

OBD Attack: By injecting malicious data frames through the OBD interface, attackers can control the CAN bus and thus control the vehicle.

USB, Bluetooth, Wi-Fi Attacks: Using these external interfaces, attackers can gain access to the vehicle, conduct unauthorized access, and even implant malware.

OTA Upgrade Attack: By bypassing security mechanisms such as signature verification, attackers can tamper with vehicle firmware, control the vehicle, or implant backdoors.

8.4 Intelligent Driving System

Machine Learning Adversarial Attacks: Attackers can use adversarial machine learning techniques to attack the vehicle's perception system, such as confusing speed limit signs, causing the vehicle to make wrong decisions.

Blinding Attacks: Using bright light to interfere with the normal operation of sensors such as cameras and LiDAR, causing the vehicle's perception system to fail.

Spoofing Attacks: By sending false signals to deceive sensors, causing the vehicle to make wrong decisions, such as misjudging traffic lights.

Multi-sensor Fusion Attacks: Attackers can exploit vulnerabilities in multi-sensor fusion algorithms to deceive or control vehicles.

Wireless Communication Attacks: Through Bluetooth, Wi-Fi, GNSS, and other wireless communication methods, attackers can remotely control or steal data from vehicles.

8.5 Mobile APP

Data Leakage: Attackers can obtain important data information from car owners through mobile apps, such as vehicle location and driving routes.

Phishing Attacks: Attackers can forge mobile apps or send malicious links disguised as official notifications to trick car owners into entering sensitive information.

Malware: Attackers can implant malware in mobile apps to control vehicles or steal car owners' data.

Unauthorized Access: If there are vulnerabilities in cloud services, attackers can pose as car owners to control other vehicles, posing serious security risks.

8.6 Smart Key

Replay Attack: Attackers can record the unlocking signal of a wireless key and replay it at the appropriate time to unlock the vehicle.

Relay Attack: Using a relay device to extend the transmission distance of wireless signals, attackers can unlock the vehicle without the car owner's knowledge.

Bluetooth Key Attack: For smart keys that use Bluetooth communication, attackers can remotely control or steal data from vehicles through Bluetooth communication vulnerabilities.

9 Summary

This article first introduces the three major security aspects of automotive electronics and software. By comparing them with functional safety, it introduces the basic concepts of information security and the analysis method (TARA) in ISO/SAE 21434.

Obviously, standards are not limited to ISO/SAE 21434. Therefore, this article sorts out the framework of domestic and international regulatory standards and the current status of issued standards, defining our general work objectives and scope.

Furthermore, combined with the information security protection object model, the technical scope of automotive information security is defined. At the same time, common threats are summarized. Corresponding to these threats, eight principles of information security design and protection are explained.

Finally, from the perspective of vulnerable products, common attack methods are summarized to provide readers with a more intuitive understanding.

10 Conclusion

Automotive information security involves a deep level of engineering, a broad technology stack, a long supply chain, and comprehensive lifecycle coverage, which is rarely seen in other topics.

This indirectly reflects the characteristics of the drastic changes in the smart car ecosystem and the high integration and collision of new technologies.