01

The evolution of electronic and electrical architecture

In recent years, the automotive electronic and electrical architecture is accelerating with the development of the new four modernizations. Many institutions and head parts suppliers have summarized this. The figure is a summary of the evolution route of electronic and electrical architecture. There are six stages in total.

The first stage is a modular architecture, each function corresponds to a controller, which we can call the modularization stage.

The second stage is that multiple functions are integrated into one controller, but in essence, it is only a multi integration form of function. This stage is called integration stage.

The third stage is to divide the functions by domain, such as chassis domain, power domain and intelligent driving domain. At this time, the functions in some domains are realized by a domain controller in the center, such as domain controller. This stage is called centralization.

In the fourth stage, some functions will be integrated across domains. At this time, a function may be implemented across domains. For example, the OTA function of the whole vehicle is an obvious example, which is called domain integration stage.

The fifth stage is that when the domain is integrated to a certain extent, most of the functions of the controller are integrated into a central driving computer, and most of the calculation force of the whole vehicle is also concentrated in this controller, and only sensors and actuators are left outside. This stage can be called the stage of central trip computer.

The sixth stage is the architecture of the central driving computer, which is part of the cloud architecture, which is the stage of cloud computing.

From the market many open information, most of the models are in the third and fourth stages, a few of the new models in research have already moved to the fifth stage, and there are also the research models between the two stages. Therefore, it is not easy to think the electronic and electrical architecture of a certain model is completely in a certain stage. And from the functional level, even some functions have been mainly implemented by cloud computing, while the electronic and electrical architecture is still in the third stage.

02

The characteristics of the evolution of electronic and electrical architecture

So what are the characteristics of the evolution of the electronic and electrical architecture, we show it through this diagram. Recently, the topic of software definition of automobile is very hot, and some OEM have already used SOA architecture and development mode in the research of new models. On the one hand, the emergence of new technology and the change of requirements lead to the accelerated evolution of electronic and electrical architecture, on the other hand, the evolution of electronic and electrical architecture has brought great convenience to the deployment of SOA. So we can think that the first new thing that the electronic and electrical architecture brings is SOA.

At the same time, the demand for total calculation power is further increased by high-level automatic driving, intelligent cockpit and other popular functions. In the electronic and electrical architecture, it can be seen that in order to meet the needs of high computing power, the integration degree of each controller distributed in e/e architecture is further improved, which also brings the trend of integration. In addition, mature technology in the original it/ict field is also being transplanted into the automotive industry. For example, Ethernet and Android, as well as various protocols and applications above, the application of Ethernet has brought a very far-reaching impact on the electronic and electrical architecture and network topology. It is also a relatively large feature that technology can be transplanted to use.

Centralization brings about the concentration of computing power. After the concentration of computing power, it is necessary to effectively use the computing force to realize the business requirements of different scenarios. In this context, virtualization technology has also been applied, which makes multiple types of operating systems run on the same chip. In addition, although the distribution of computing power is continuing to concentrate, the diversification of business scenarios and computing capabilities continues. In the same controller, heterogeneous processors such as cpu/gpu/npu/mcu are integrated to handle complex tasks and scenarios. The last feature we recognize is that almost all new models are connected to the Internet, and there is near field communication. In addition, OTA refresh of the whole vehicle is being promoted. What we can see is that almost all controllers can be accessed directly or indirectly remotely and can be refreshed.

The above is what we have observed in the evolution of e/e architecture. What impact and challenges will these characteristics and changes have on information security?

03

The information security challenges brought by the evolution of electronic and electrical architecture

I have chosen a few points to do the analysis. This analysis is just an example. I hope it can play a role in the process of introducing the bricks and stones. Let's start by looking at the challenges of SOA. The function of SOA is decoupled from service. The function realization is abstract. In order to customize and iterate functions, services in SOA platform are often open and customized. This enables these existing services to be used at the communication level to implement attacks, such as DoS attacks, by forging identities.

At the same time, since the c/s connection of some/ip is a dynamic connection when the demand side needs it, it is very complex to analyze the security risk by traditional data flow method. This is some of the challenges that SOA brings.

So what will virtualization bring? Because the multi operating system runs on a chip, not only the vulnerability increases, the vulnerability management and repair will be more complex, which is a bit of a feeling of moving the whole body. At the same time, the virtual machine itself can bring additional vulnerabilities.

So what will heterogeneous computing bring? Because of the use of a variety of heterogeneous chips, a large number of inter chip data will be exchanged between chips, which may lead to the increase of the possibility of successful side channel attack or fault injection attack.

What challenges will the most obvious integration trend bring? As the controller is continuously integrated and the number of layers of network is decreasing, the result is that the attack path that needs to merge multiple vulnerability construction will be shorter. In the advanced architecture, only a small amount of vulnerability needs to be combined and utilized, spanning two controllers, and T-box and central driving computer may be used, About four chips can be accessed to the actuator for remote control.

The next feature is the transplantation of existing technologies. Nowadays, the controller often uses open source components, and the open source components have some risks. The possibility of zero day vulnerabilities is also very large. And most advanced architectures will use Ethernet and mobile OS. Many ideas of analysis and attack can be used in the vehicle. The last feature is not entirely brought about by the evolution of e/e architecture. It is the networking and OTA of the whole car. This change is that almost all controllers on the vehicle can be attacked at any time, anywhere.

There are only a few new challenges listed here, and in fact, they are certainly more than those listed here. So how should we deal with these challenges?

04

How to deal with new challenges

I have two points here on how to deal with these challenges:

The first point is that we should have a full network space perspective. Here is to consider the cloud tube end core, as well as all the vehicles of the same type sold in operation, as a whole in assessing the risk. And to do so, in fact, the ability of people is very high.

The second point is that we can roughly divide the network space into four levels of cloud tube end core. When exporting information security requirements, we will find that there are many requirements that span multiple levels. To achieve the corresponding design work, we need to have a top-level perspective to carry out top-level design, and finally implement the requirements layer by layer.

I summarize the challenges of e/e architecture evolution into the following five steps:

The first step is to analyze and eva1uate the whole network space as a whole, and the methodology here uses iso1434.

The second step is to build security architecture coverage in the network space to cover all aspects of risk.

Step 3: the security requirements derived are arranged in layers. The requirements of cross-layer and cross terminal are designed from the top level, and some of them are deployed in the cloud. The requirements of road end can be implemented at this level.

Step 4: decompose the information security requirements of the disassembled vehicle to the whole vehicle, and the whole vehicle will be regarded as a terminal.

Step 5 further decomposes the requirements to the controller level, and finally implements the implementation at the controller level. These are two key points and five steps that should be paid attention to in the response to new challenges.

05

Examples of alternative solutions

After all, do we have any practical solutions to the ground. Of course, and there are many. If we want to design a solution that can meet the information security challenge in the whole network space, it may eventually come out a very complex demand. If you do entry as required by the aspice process, there may be tens of thousands or more requirements at all levels. Let's take a look at these examples.

One of the requirements of SOA architecture is to divide the service area into security related services and non security related services, and perform two-way authentication in security related services. One of the problems brought by virtualization is to use an automated vulnerability management system covering multiple platforms. One of the problems of heterogeneous computing is to choose the chip which can resist side channel attack and fault injection attack as much as possible. The relevant tests can also be carried out if conditions permit.

For the central driving computer with the integrated trend, the control network or communication unit or domain controller with remote connection function can set the target to the highest level directly because of its important role in the vehicle architecture, that is, refer to the cal level of iso1434, and can be directly set to cal4. All the requirements that can be achieved are on, and the tests are all. For the problems brought by technology migration, we can consider this way. Since there are so many tools available in ICT, why not migrate to test. Designers can also learn infiltration tools. For example, there are many people who have done this for example, for example, the various tools on Kali Linux. Of course, it's only for test purposes.

06

Solution deployment at vehicle level

When we generate a lot of requirements, the integration layer is a large comprehensive solution. How to deploy at the vehicle level? First, we will layer requirements. From the top level perspective, we will find that there are a lot of requirements deployed in the cloud and the management side, and most of these requirements deployed in the cloud are cross-level and cross terminal requirements. For example, PKI, vulnerability management system, IDPs in the cloud security log analyzer, and so on. Then the next step is to determine the communication protocol and security measures of remote communication, near field communication, and in vehicle communication. For example TLS and secoc. The requirements of communication protocol are also considered as a whole. You will find that the trust chain and the establishment of tee will extend from HSM to the cloud in the chip core.

07

Implementation of solutions at the controller level

The implementation of the requirements at the controller level determines the final landing of the requirements. Here, the controller is regarded as a terminal and the whole vehicle is regarded as a network. Then, in the system architecture, the requirements are further positioned to the chip. Here, the development process of iso1434 can be used as guidance.

08

The characteristics of the evolution of electronic and electrical architecture

When we deal with the challenges brought by the change of e/e architecture, we need to have a full network space perspective, because the impact of e/e architecture evolution is not only reflected in the vehicle, but actually reflected in the network space. Therefore, we should not only consider the vehicle, but also consider the risks from the whole network space to cover all aspects of the risks caused by the evolution of e/e architecture.

In how to solve the problem, we need to have top-level design, so that cross terminal solutions can be easier to implement. But because many of the solutions are cross terminal, in the actual model development process, cross terminal solutions bring a lot of coordination and communication work, so the time cost and development cost are also very huge. If there is a comprehensive solution packaged as a whole, it is not only for specific parts suppliers, integrators or OEM, but also a lot of costs will be saved, We believe that such all in one solutions are market trends. Although the network security problem is complex and even more complex, the supplier who can provide such all in one solution can make it simple. And China Auto innovation is moving in this direction.

Source: https://new.qq.com/rain/a/20210603A004FQ00