Author: Huang Huibin
Evolution of Automotive Electrical and Electronic Architecture
In recent years, with the advancement of new four modernizations, the automotive electrical and electronic architecture has been evolving rapidly. Many organizations and leading component suppliers have made summaries on this topic. The figure shows one of the summaries of the evolution of the electrical and electronic architecture. It is divided into six stages.
The first stage is the modular architecture, where each function corresponds to a controller, which we can call the modular stage.
The second stage is the integration of multiple functions into one controller, but essentially it is only a multi-functional integration form, which is called the integration stage.
The third stage is to divide the functions according to domain, such as chassis domain, power domain, and intelligent driving domain. At this time, the domain controller in the center controls most of the functions of some domains, such as domain controllers. This stage is called centralized stage.
In the fourth stage, some functions will be integrated across domains. At this time, some functions are likely to be implemented across domains. For example, the OTA function of the whole vehicle is a clear example. This stage is called domain fusion stage.
In the fifth stage, after the domains are integrated to a certain extent, most of the function of the controllers are integrated into a central on-board computer, and most of the computing power of the whole vehicle is also concentrated in this controller. Only sensors and actuators remain in the periphery. We can call this stage the central on-board computer stage.
The sixth stage is when the functions and computing tasks of the central on-board computer are partially implemented by the cloud. This stage is the stage of cloud computing.
From many publicly available information in the market, most car models are in the third or fourth stage, and a few new car models in development have already progressed to the fifth stage. And there are models in between the two stages. Therefore, we cannot simply regard the electrical and electronic architecture of a certain model as being completely in one stage. Moreover, from the perspective of function level, even some functions are mainly implemented by cloud computing, but the electrical and electronic architecture is still in the third stage.
Characteristics of the Evolution of Electrical and Electronic Architecture
What are the characteristics of the evolution of the electrical and electronic architecture? We demonstrate it through this figure. Recently, the topic of software-defined cars is very hot, and some OEMs have developed new models using SOA architecture and development models. On the one hand, the birth of new technologies and changes in demand have accelerated the evolution of the electrical and electronic architecture. On the other hand, the evolution of the electrical and electronic architecture has brought great convenience to the deployment of SOA. Therefore, we can regard the first new thing brought by the electrical and electronic architecture as SOA.## The information security challenges brought by the evolution of Electrical/Electronic architecture
Advanced autonomous driving and smart cockpits have further increased the demand for the total computing power, leading to a significant increase in the integration level of various controllers distributed in the E/E architecture to meet the high computing power requirements. This has also brought about a trend towards integration. In addition, mature IT/ICT technologies are being heavily transferred to the automotive industry, such as Ethernet and Android, and various protocols and applications based on them. The application of Ethernet has had a profound impact on the E/E architecture and network topology, and the technology can be directly applied, which is also a significant feature.
Centralization brings computing power centralization, and after computing power is centralized, it needs to be effectively used to meet the business requirements of different scenarios. Under this background, virtualization technology has also been applied, which allows multiple types of operating systems to run on the same chip. In addition, although the distribution of computing power is still continuing to centralize, the diversification of business scenarios and computing capabilities is continuing. It is becoming increasingly common to integrate CPU/GPU/NPU/MCU and other heterogeneous processors to handle complex tasks and scenarios within the same controller. The last feature we have identified is that almost all new models are now connected to the Internet, and with near-field communication and vehicle-wide OTA updates being promoted, we can see that almost all controllers can be accessed remotely and refreshed directly or indirectly.
These are the observations we have made during the evolution of the E/E architecture. What impacts and challenges will these features and changes have on information security?
Information Security Challenges posed by the Evolution of the Electrical/Electronic Architecture
[image]
I have picked a few points to analyze, and this is only an example. I hope that this analysis can serve as a starting point for further discussions. First, let’s take a look at the challenges brought about by SOA. SOA decouples functionality and services, and the implementation of functionalities is abstract. Moreover, in order to customize and iterate functionalities, services in the SOA platform are often open and customizable. Attackers can exploit these existing services and launch attacks by forging identities, such as DoS attacks, at the communication layer.
At the same time, the C/S connection of SOME/IP is established dynamically when needed by the demand side, which belongs to dynamic connections. Analyzing security risks using traditional data flow analysis methods is extremely complex. These are some of the challenges brought about by SOA.
So what about virtualization? Multiple operating systems running on one chip increase vulnerabilities, and managing and repairing vulnerabilities becomes more complex. It is like pulling a thread and unraveling the entire garment. Additionally, virtual machines themselves may bring additional vulnerabilities.
What about heterogeneous computing? Because multiple types of heterogeneous chips are used, a large amount of inter-chip data exchange may occur, which may increase the possibility of successfully performing side-channel attacks or fault injection attacks.Translate the following Markdown Chinese text to English Markdown text in a professional way, keeping the HTML tags inside the Markdown and outputting only the result:
What challenges will the most obvious trend towards integration bring? As the number of controllers decreases due to continuous integration, and the number of network hierarchy layers also decreases, the result is that the attack paths that previously needed to merge multiple vulnerability builds will become shorter. In advanced architectures, it may only need to merge a few vulnerabilities to cross two controllers, such as T-Box and central electronic computer, with approximately four chips to contact the actuator and achieve remote control.
The next feature is the transplantation of existing technology. Current controllers often use a large number of open-source components, and open-source components themselves have certain risks, with a much greater likelihood of discovering zero-day vulnerabilities. And most advanced architectures use Ethernet and mobile OS, and the analysis and attack tools used in previous attacks can also be used in vehicles. The final feature is not entirely brought about by the evolution of E/E architecture. It is the network connection and full-vehicle OTA. This change means that almost all controllers in the car may be attacked anytime, anywhere.
Here, only a small part of the new challenges are listed, and there are definitely more challenges than those listed here. So how should we deal with these challenges?
How to deal with new challenges
Regarding how to deal with these challenges, I propose two points of view:
The first point of view is that we need to have a full network space perspective. Here, when assessing risks, the cloud management end core and all sold and running vehicles of the same type should be considered as a whole. To achieve this, the requirements for human capabilities are actually very high.
The second point of view is that we can roughly divide the network space into four levels, and when exporting information security requirements, we will find that many requirements span multiple levels, and to implement corresponding design work, we need a top-level perspective to carry out top-level design and finally implement requirements at all levels.
I summarize the following 5 steps for dealing with the challenges brought by the evolution of E/E architecture:
The first step is to analyze and evaluate the entire network space as a whole, and the methodology used here is ISO21434.
The second step is to build a security architecture in the network space that covers all possible areas of risk.
The third step is to hierarchically arrange the exported security requirements, and cross-terminal requirements can be deployed in the cloud at the top level of design, while roadside requirements can be implemented at this level.
The fourth step is to break down the information security requirements of the dismantled whole vehicle to the entire vehicle, which will be viewed as a terminal at this point.## Optional Solution Examples
After so much discussion, do we have any practical solutions that can be implemented? Of course, we do, and there are many. If we want to design a solution that can address information security challenges in the entire network space, it may finally result in a very complex set of requirements. If we follow the ASPICE process requirements to do entry standardization, the requirements of all levels combined may add up to tens of thousands or even more. Let’s take a look at a few examples.
For the problem brought by the SOA architecture, one requirement is to distinguish the services into security-related services and non-security-related services, and to perform two-way identity authentication in the security-related services. For the problem brought by virtualization, one requirement is to use an automated vulnerability management system that covers multiple platforms. For the problem brought by heterogeneous computing, one requirement is to select chips that can resist side-channel attacks and fault-injection attacks as much as possible. Relevant tests can also be conducted if conditions permit.
For the central computer for integrated driving trend with remote connection function, control network, communication unit or domain controller with important roles in the entire vehicle architecture, the target can be set directly to the highest level, which is CAL4 according to ISO21434 reference. All feasible requirements and tests should be included. For the problem brought by technical migration, we can consider it this way. Since there are so many existing tools in the ICT field, why not transplant them over for testing? Designers can also learn penetration tools. For example, various tools on Kali Linux may have been used by many people in this way. Of course, this is only limited to testing purposes.
Deployment of Solutions at the Entire Vehicle Level
When we have generated a large number of requirements and integrated them into a comprehensive solution at the system level, how should we deploy this solution at the vehicle level? Firstly, we need to layer the requirements. From a top-level perspective, we will find that a large number of requirements are deployed in the cloud and management end, and most of the requirements deployed in the cloud are cross-level and cross-terminal, such as PKI, vulnerability management systems, IDPS, and security log analyzers in the cloud. The next step is to determine the communication protocols and security measures for remote communication, near-field communication, and in-vehicle communication, such as TLS and SecOC. Requirements for communication protocols also need to be considered from a holistic perspective. You will find that the establishment of trust chains and TEEs will extend from the HSM of the chip core to the cloud.
Implementation of the Solution at the Controller Level
The implementation of requirements at the controller level determines the final landing of the requirements. Here, we need to view the controller as a terminal and the entire vehicle as a network. Afterwards, in the system architecture, we further locate the requirements in the chip, using the ISO21434 development process as a guide.
Characteristics of the Evolution of Electrical and Electronic Architecture
When responding to the challenges brought about by the evolution of E/E architecture, we need to have a perspective across the entire network space, because the impact of the evolution of E/E architecture is not limited to the vehicle itself, but actually appears in the network space. Therefore, we should not only consider the vehicle, but should think from a holistic perspective to cover all the risks brought about by the evolution of E/E architecture.
In terms of how to solve problems, we need a top-level design to make cross-terminal solutions easier to implement. As many of the solutions are cross-terminal, in the actual vehicle development process, a lot of coordination and communication work is required, resulting in significant time and development costs. If we can have a comprehensive package of integrated solutions, it will save a lot of costs for specific component suppliers, integrators, and OEMs. We believe that this kind of all-in-one solution is a market trend today. Although network security issues are complex, even becoming more complex, suppliers who can provide all-in-one solutions can simplify the problem. China National Automotive Industry Corporation’s Intelligent Vehicle and Mobility Solutions is moving in this direction.
This article is a translation by ChatGPT of a Chinese report from 42HOW. If you have any questions about it, please email bd@42how.com.