In-vehicle isolated communication method, system, device and vehicle based on key management

CN122802142APending Publication Date: 2026-09-22CHINA FAW CO LTD
View PDF 0 Cites 0 Cited by

Patent Information

Application Number
CN202610919734.2
Authority / Receiving Office
CN · China
Patent Type
Applications(China)
Current Assignee / Owner
Filing Date
2026-06-24
Publication Date
2026-09-22

AI Technical Summary

Technical Problem

[0002]相关技术中,车辆运行需要在车内总线传输大量数据,然而车内总线数据多以明文传输,不同控制域之间的报文通常只采用转发隔离,当错误转发至其它控制器时,存在被植入的监听程序监听的风险,即使在同域控制器间也可能由于误识别而被监听程序监听,存在通信安全隐患

Benefits of technology

[0015]本申请实施例至少包括以下有益效果:本申请提供一种基于密钥管理的车内隔离通信方法、系统、装置及车辆,该方案通过第一控制器获取目标报文,确定该目标报文的接收方,当接收方为与第一控制器不同域的第二控制器时,第一控制器作为发送方,与第二控制器和中央控制单元通过控制器密钥和控制域密钥进行非对称加密通信,使目标报文经中央控制单元发送至第二控制器;而当接收方为与第一控制器同域的第三控制器时,第一控制器作为发送方,与第三控制器通过对应控制域的通信密钥进行对称加密通信,使目标报文发送至第三控制器。与车内总线数据明文传输相比,本申请实施例针对同域控制器和非同域控制器两种场景,与同域控制器通信时,通过通信密钥进行对称加密通信,实现对同域非通信控制器的屏蔽;与非同域控制器通信时,通过控制器密钥和控制域密钥,经中央控制单元进行非对称加密通信,实现跨域隔离,从而防止总线数据的跨域窃听或同域窃听,提高车辆的数据安全性。

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure CN122802142A_ABST
    Figure CN122802142A_ABST
Patent Text Reader

Abstract

This application provides a method, system, device, and vehicle for in-vehicle isolated communication based on key management, belonging to the field of vehicle communication technology. The method includes: acquiring a target message through a first controller and determining the recipient of the target message, wherein the first controller is the sender of the target message; when the recipient is a second controller outside the same domain, the first controller, the second controller, and the central control unit perform asymmetric encrypted communication using a controller key and a control domain key to send the target message from the first controller to the central control unit, and then from the central control unit to the second controller; when the recipient is a third controller within the same domain, the first controller and the third controller perform symmetric encrypted communication using a communication key of the corresponding control domain to send the target message from the first controller to the third controller. This application aims to prevent cross-domain or same-domain eavesdropping of bus data, thereby improving vehicle data security.
Need to check novelty before this filing date? Find Prior Art

Description

Technical Field

[0001] This application relates to the field of vehicle communication technology, and in particular to an in-vehicle isolated communication method, system, device and vehicle based on key management. Background Technology

[0002] In related technologies, vehicle operation requires the transmission of a large amount of data on the in-vehicle bus. However, the in-vehicle bus data is mostly transmitted in plaintext. Messages between different control domains are usually isolated by forwarding. When they are mistakenly forwarded to other controllers, there is a risk of being monitored by an implanted eavesdropping program. Even between controllers in the same domain, they may be monitored by an eavesdropping program due to misidentification, which poses a communication security risk.

[0003] In summary, the technical problems existing in the relevant technologies need to be improved. Summary of the Invention

[0004] The main objective of this application is to propose an in-vehicle isolation communication method, system, device, and vehicle based on key management, which aims to prevent cross-domain or same-domain eavesdropping of bus data and improve vehicle data security.

[0005] To achieve the above objectives, one aspect of this application proposes an in-vehicle isolation communication method based on key management. The vehicle includes a first controller, a second controller, a third controller, and a central control unit, wherein the second controller is a non-local controller of the first controller, and the third controller is a local controller of the first controller. The method includes: The first controller acquires the target message and determines the recipient of the target message, wherein the first controller is the sender of the target message; When the receiver is the second controller, the first controller, the second controller, and the central control unit communicate asymmetrically encrypted using a controller key and a control domain key to send the target message from the first controller to the central control unit, and then through the central control unit to the second controller. When the receiver is the third controller, the first controller and the third controller communicate with each other using symmetric encryption via communication keys of the corresponding control domains to send the target message from the first controller to the third controller.

[0006] In some embodiments, before obtaining the target message through the first controller, the method further includes generating the control domain key through the central control unit, including: The central control unit uses the RSA algorithm to generate and store the control domain public key and control domain private key for each control domain. The control domain key includes the control domain public key and control domain private key. The central control unit broadcasts the public keys of each control domain to the corresponding control domain, so that each controller in the corresponding control domain receives and stores the public key of the control domain. The controller includes the first controller, the second controller and the third controller.

[0007] In some embodiments, after each controller in the corresponding control domain receives and stores the control domain public key, the method further includes: The controller generates and stores a public key and a private key using the RSA algorithm, wherein the controller key includes the public key and the private key. The controller encrypts the controller public key using the received control domain public key and sends the encrypted controller public key to the central control unit, so that the central control unit receives and stores the controller public key corresponding to each controller.

[0008] In some embodiments, after each controller in the corresponding control domain receives and stores the control domain public key, the method further includes: The controller trims the received control domain public key to obtain a communication key that meets preset specifications, and then stores the communication key.

[0009] In some embodiments, the method further includes: When the vehicle rolls off the production line and the system is powered on, the 31 service control command is triggered through the EOL diagnostic port to execute the step of generating the control domain key through the central control unit.

[0010] In some embodiments, each controller stores a corresponding controller public key, a controller private key, and a control domain public key of its respective control domain. The central control unit stores the controller public key of each controller, the control domain public key of each control domain, and a control domain private key. The controller key includes the controller public key and the controller private key, and the control domain key includes the control domain public key and the control domain private key. The first controller, the second controller, and the central control unit perform asymmetric encrypted communication using the controller key and the control domain key, including: The first controller encrypts the target message using its private key to obtain a first encrypted message, and then encrypts the first encrypted message using its public key to obtain a second encrypted message. The second encrypted message is then sent to the central control unit. The control domain to which the first controller belongs is defined as the first control domain. The central control unit receives the second encrypted message, decrypts the second encrypted message using the private key of the first control domain to obtain the first encrypted message, decrypts the first encrypted message using the public key of the first controller to obtain the target message, confirms the second control domain to which the second controller belongs, encrypts the target message using the public key of the second controller to obtain the third encrypted message, encrypts the third encrypted message using the private key of the second control domain to obtain the fourth encrypted message, and sends the fourth encrypted message to the second controller. The second controller receives the fourth encrypted message, decrypts the fourth encrypted message using the second control domain public key to obtain the third encrypted message, and decrypts the third encrypted message using the second controller private key to obtain the target message.

[0011] In some embodiments, the first controller and the third controller perform symmetric encrypted communication using a communication key for a corresponding control domain, including: The first controller uses the communication key to encrypt the target message to obtain a fifth encrypted message, and then sends the fifth encrypted message to the third controller. The third controller receives the fifth encrypted message and decrypts it using the communication key to obtain the target message; wherein the first controller and the third controller store the same communication key.

[0012] To achieve the above objectives, another aspect of this application proposes an in-vehicle isolated communication system based on key management. The vehicle includes a first controller, a second controller, a third controller, and a central control unit, wherein the second controller is a non-local controller of the first controller, and the third controller is a local controller of the first controller. The system includes: The first processing module is used to acquire the target message through the first controller and determine the recipient of the target message, wherein the first controller is the sender of the target message; The second processing module, in response to the receiver being the second controller, controls the first controller, the second controller, and the central control unit to perform asymmetric encrypted communication through a controller key and a control domain key, so as to send the target message from the first controller to the central control unit, and then send it to the second controller through the central control unit; The third processing module, in response to the receiver being the third controller, controls the first controller and the third controller to perform symmetric encrypted communication using the communication key of the corresponding control domain, so as to send the target message from the first controller to the third controller.

[0013] To achieve the above objectives, another aspect of this application provides a vehicle control device, the device including a memory and a processor, the memory storing a computer program, and the processor executing the computer program to implement the method described above.

[0014] To achieve the above objectives, another aspect of this application provides a vehicle equipped with the vehicle control device described above and implementing the method described above.

[0015] The embodiments of this application include at least the following beneficial effects: This application provides an in-vehicle isolation communication method, system, device, and vehicle based on key management. This scheme obtains a target message through a first controller and determines the recipient of the target message. When the recipient is a second controller in a different domain than the first controller, the first controller acts as the sender, communicating with the second controller and the central control unit via asymmetric encryption using a controller key and a control domain key, so that the target message is sent to the second controller via the central control unit. When the recipient is a third controller in the same domain as the first controller, the first controller acts as the sender, communicating with the third controller via symmetric encryption using a communication key of the corresponding control domain, so that the target message is sent to the third controller. Compared with plaintext transmission of in-vehicle bus data, the embodiments of this application address both same-domain and non-same-domain controller scenarios. When communicating with a same-domain controller, symmetric encryption is used via a communication key to shield non-communicating controllers in the same domain. When communicating with a non-same-domain controller, asymmetric encryption is used via a controller key and a control domain key through the central control unit to achieve cross-domain isolation, thereby preventing cross-domain or same-domain eavesdropping of bus data and improving vehicle data security. Attached Figure Description

[0016] Figure 1 This is a flowchart of an in-vehicle isolation communication method based on key management, provided in an embodiment of this application; Figure 2 It is an application Figure 1 Example schematic diagram of the vehicle bus architecture of the method; Figure 3 yes Figure 1 A flowchart of an embodiment prior to step S101; Figure 4 yes Figure 3 A flowchart of an embodiment following step S302; Figure 5 yes Figure 1 Partial flowchart of step S102; Figure 6 yes Figure 1 Partial flowchart of step S103; Figure 7This is a schematic diagram of the structure of an in-vehicle isolation communication system based on key management, provided in an embodiment of this application. Figure 8 This is a schematic diagram of the vehicle control device provided in the embodiments of this application. Detailed Implementation

[0017] To make the objectives, technical solutions, and advantages of this application clearer, the following detailed description is provided in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative of this application and are not intended to limit it. In the following description, when referring to the accompanying drawings, unless otherwise indicated, the same numbers in different drawings represent the same or similar elements. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with those of this application; they are merely examples of apparatuses and methods consistent with some aspects of the embodiments of this application as detailed in the appended claims.

[0018] It is understood that the terms “first,” “second,” etc., used in this application may be used herein to describe various concepts, but unless otherwise stated, these concepts are not limited by these terms. These terms are only used to distinguish one concept from another. For example, without departing from the scope of the embodiments of this application, first information may also be referred to as second information, and similarly, second information may also be referred to as first information. Depending on the context, the words “if,” “when,” or “in response to a determination” as used herein may be interpreted as “when…” or “when…” or “in response to a determination.”

[0019] As used in this application, the terms "at least one", "multiple", "each", "any", etc., "at least one" includes one, two or more, "multiple" includes two or more, "each" refers to each of the corresponding multiples, and "any" refers to any one of the multiples.

[0020] Unless otherwise defined, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this application belongs. The terminology used herein is for the purpose of describing embodiments of this application only and is not intended to limit this application.

[0021] In related technologies, vehicle operation requires the transmission of a large amount of data on the in-vehicle bus. However, the in-vehicle bus data is mostly transmitted in plaintext. Messages between different control domains are usually isolated by forwarding. When they are mistakenly forwarded to other controllers, there is a risk of being monitored by an implanted eavesdropping program. Even between controllers in the same domain, they may be monitored by an eavesdropping program due to misidentification, which poses a communication security risk.

[0022] In view of this, this application provides a method, system, device, and vehicle for in-vehicle isolated communication based on key management. This scheme obtains a target message through a first controller and determines the recipient of the target message. When the recipient is a second controller in a different domain than the first controller, the first controller acts as the sender, communicating with the second controller and the central control unit via asymmetric encryption using a controller key and a control domain key, so that the target message is sent to the second controller via the central control unit. When the recipient is a third controller in the same domain as the first controller, the first controller acts as the sender, communicating with the third controller via symmetric encryption using a communication key of the corresponding control domain, so that the target message is sent to the third controller. Compared to plaintext transmission of in-vehicle bus data, this application addresses both same-domain and non-same-domain controller scenarios. When communicating with a same-domain controller, symmetric encryption is used via a communication key to shield non-communicating controllers in the same domain. When communicating with a non-same-domain controller, asymmetric encryption is used via a controller key and a control domain key through the central control unit to achieve cross-domain isolation, thereby preventing cross-domain or same-domain eavesdropping of bus data and improving vehicle data security.

[0023] Figure 1 This is an optional flowchart of the in-vehicle isolation communication method based on key management provided in the embodiments of this application. Figure 1 The method may include, but is not limited to, steps S101 to S103, wherein steps S102 and S103 are parallel steps.

[0024] Figure 1 The method described above is applied to vehicle bus communication. (Refer to...) Figure 2 , Figure 2 This is a schematic diagram illustrating an example of a vehicle bus architecture. It can be understood that a vehicle is equipped with multiple control domains to implement different control functions, and each control domain contains multiple controllers. Some of these controllers are communication controllers, and message transmission occurs between different communication controllers to meet the needs of normal vehicle operation. Furthermore, the vehicle has a central control unit for unified management of the various control domains and their controllers. In this embodiment, a first controller, a second controller, and a third controller are defined, all of which are communication controllers. The first and third controllers are co-domain controllers belonging to the same control domain, while the second controller and the first controller (and the third controller) are non-co-domain controllers belonging to different control domains. Combined with the central control unit, they form a... Figure 2 The architecture shown. Figure 1 The methods described above can be applied to more control domains or controller scenarios, referencing the architecture mentioned above.

[0025] In implementation Figure 1 Before proceeding with the method, please refer to... Figure 3In some embodiments, the method further includes generating a control domain key via a central control unit, including: Step S301: The central control unit uses the RSA algorithm to generate and store the control domain public key and control domain private key for each control domain. The control domain key includes the control domain public key and control domain private key. Step S302: The central control unit broadcasts the public keys of each control domain to the corresponding control domain, so that each controller in the corresponding control domain receives and stores the control domain public key. The controllers include the first controller, the second controller, and the third controller.

[0026] To achieve cross-domain isolated communication, it is first necessary to generate corresponding control domain keys based on the control domain. All control domain keys are generated and managed by a central control unit; specifically, the RSA algorithm is used to generate the control domain public key and control domain private key for each control domain. Figure 2 Taking the architecture shown as an example, the control domain to which the first controller and the third controller belong is defined as the first control domain, and the control domain to which the second controller belongs is defined as the second control domain. The first control domain public key and the first control domain private key are generated, as well as the second control domain public key and the second control domain private key are generated, and all control domain keys are stored and managed according to different control domains.

[0027] To generate a key using the RSA algorithm, two sufficiently large and distinct prime numbers must first be selected, and their common modulus must be calculated. In this embodiment, 512 bits or 256 bits can be used. Then, the Euler's totient function of both numbers is calculated, the public key exponent is selected, and the private key exponent is calculated. Finally, the key pair is output, which is a public key and a private key pair.

[0028] The central control unit then broadcasts the public keys of each control domain to the corresponding control domain, enabling the controllers in that domain to receive and store the public keys, thus allowing each controller to know the public key of its respective control domain. Figure 2 Taking the architecture shown as an example, the central control unit sends the first control domain public key to the first controller and the third controller for storage, and then sends the second control domain public key to the second controller for storage.

[0029] By generating control domain keys for different control domains and broadcasting the control domain public keys to the corresponding control domains, encrypted communication between the controller and the central control unit, as well as communication between controllers in different control domains, is supported, thereby improving data security.

[0030] refer to Figure 4 In some embodiments, after step S302, the method further includes: Step S401: Generate and store the controller public key and controller private key using the RSA algorithm through the controller. The controller key includes the controller public key and controller private key. In step S402, the controller uses the received control domain public key to encrypt the controller public key, and sends the encrypted controller public key to the central control unit, so that the central control unit receives and stores the controller public key corresponding to each controller.

[0031] After generating the control domain key, a controller key also needs to be generated to further improve cross-domain isolated communication. Specifically, after each controller receives the broadcast control domain public key, it begins to generate its own corresponding controller key, also using the RSA algorithm. The process of generating the RSA key will not be elaborated here. Each controller generates its corresponding controller public key and controller private key and stores them locally. Figure 2 Taking the architecture shown as an example, the first controller stores the first controller public key and the first controller private key, the second controller stores the second controller public key and the second controller private key, the third controller stores the third controller public key and the third controller private key, and each also stores the control domain public key of its respective control domain.

[0032] On the other hand, each controller also needs to send its generated controller public key back to the central control unit, enabling encrypted communication between the central control unit and the controllers using the controller key. Specifically, to improve data security, the controller public key is encrypted using the control domain public key before being sent to the central control unit. The central control unit can then decrypt the public key of the controller by selecting the control domain private key of the corresponding control domain. When each controller has executed the steps of this embodiment, the central control unit obtains the controller public key of each controller. Taking the first controller as an example, the first controller encrypts its own public key using the first control domain public key, forming a format such as "first control domain public key (first controller public key)," and then sends it to the central control unit. The central control unit then decrypts the public key using the first control domain private key to obtain the first controller public key.

[0033] By further generating a controller key and sending the controller public key to the central control unit, encrypted communication using the controller key and control domain key can be supported between the controller and the central control unit, as well as between different domain controllers, thereby improving data security.

[0034] In some embodiments, after step S302, the method further includes: In step S403, the controller trims the received control domain public key to obtain a communication key that meets the preset specifications and stores the communication key.

[0035] Step S403 is parallel to steps S401 to S402.

[0036] While generating the controller key, the same communication key can be used for symmetric encrypted communication within the same control domain. Optionally, it can be generated based on the control domain public key. Since controllers within the same control domain all store the same control domain public key, the same communication key can be obtained by using the same generation method, such as pre-setting a fixed clipping position to clip segments of the same length from the control domain public key; the preset specification is set to, for example, 64 bits or 32 bits. Figure 2 Taking the architecture shown as an example, the first controller and the third controller store the same communication key, and the second controller also stores the communication key corresponding to the public key of the second control domain.

[0037] By generating and storing communication keys, controllers within the same control domain can communicate encrypted using these keys, thereby shielding non-communication controllers within the same domain and improving data security.

[0038] Based on the above embodiments, such as Figure 2 The keys managed by the central control unit shown below can be found in Table 1:

[0039] Table 1 Central Control Unit Management Key Secondly, such as Figure 2 The keys managed by the first, second, and third controllers shown below can be found in Table 2:

[0040] Table 2 Controller Management Key In Table 2 above, for ease of distinction, the communication key of each controller in the first control domain is defined as the first communication key, and the communication key of the second control domain is defined as the second communication key.

[0041] Based on the above embodiments, in some embodiments, the method further includes: Step S300: When the vehicle is off the production line and the system is powered on, the 31 service control command is triggered through the EOL diagnostic port to execute the step of generating a control domain key through the central control unit.

[0042] For the key generation in the above embodiments, it can be set to be triggered by the 31 service control command through the EOL diagnostic port when the system is powered on during the initial stage after the vehicle rolls off the production line. When the vehicle rolls off the production line and the system is powered on, the vehicle is undergoing quality inspection and initializing all controllers, and communication diagnostics are performed through the EOL diagnostic port; this EOL diagnostic port is the vehicle's preset diagnostic communication physical interface. On the other hand, the triggered 31 service control command is service 0x31 in the UDS unified diagnostic service, used to trigger a preset program. By setting the steps in the above embodiments to this preset program, the generation process of the control domain key and controller key can be executed by triggering this command.

[0043] By setting the trigger conditions for the control domain key and controller key generation process, the vehicle can intelligently generate control domain keys and controller keys at the factory, supporting the provision of security functions to prevent cross-domain or same-domain eavesdropping of bus data, thereby improving the vehicle's data security experience.

[0044] Based on the above embodiments and the control domain key and controller key generated in Tables 1 and 2, execution can be performed. Figure 1 The method shown enables intra-domain or cross-domain communication between controllers: Step S101: Obtain the target message through the first controller and determine the recipient of the target message. The first controller is the sender of the target message. In this embodiment, the first controller acts as the sender of the message, and the message to be sent is defined as the target message. After the first controller obtains the target message, it can further determine the recipient of the message, thereby determining whether the communication is intra-domain communication or cross-domain communication.

[0045] Step S102: When the receiver is the second controller, the first controller, the second controller, and the central control unit communicate asymmetrically encrypted using the controller key and the control domain key to send the target message from the first controller to the central control unit, and then send it to the second controller through the central control unit. When the receiver is the second controller, it indicates that cross-domain communication is required. The target message to be transmitted is encrypted using the control domain key and controller key generated in the above embodiment, and then forwarded by the central control unit to the second controller in the second control domain. The target message is encrypted or decrypted by the keys of the first control domain and the second control domain, two different control domains, and the first controller and the second controller, two different controllers. The central control unit acts as an intermediary to realize two symmetrical communications, so that the target message is finally transmitted to the second controller.

[0046] refer to Figure 5In some embodiments, the first controller, the second controller, and the central control unit communicate asymmetrically encrypted via a controller key and a control domain key, including: Steps S501 to S503 are executed by the first controller: Step S501: Encrypt the target message using the private key of the first controller to obtain the first encrypted message; Step S502: Encrypt the first encrypted message using the first control domain public key to obtain the second encrypted message; Step S503: Send the second encrypted message to the central control unit; Steps S504 to S510 are executed by the central control unit: Step S504: Receive the second encrypted message; Step S505: Decrypt the second encrypted message using the first control domain private key to obtain the first encrypted message; Step S506: Decrypt the first encrypted message using the first controller public key to obtain the target message; Step S507: Confirm the second control domain to which the second controller belongs; Step S508: Encrypt the target message using the second controller public key to obtain the third encrypted message; Step S509: Encrypt the third encrypted message using the second control domain private key to obtain the fourth encrypted message; Step S510: Send the fourth encrypted message to the second controller; Steps S511 to S513 are executed via the second controller: Step S511: Receive the fourth encrypted message; Step S512: Use the second control domain public key to decrypt the fourth encrypted message to obtain the third encrypted message; Step S513: Use the private key of the second controller to decrypt the third encrypted message to obtain the target message.

[0047] Specifically, based on the key management information in Tables 1 and 2 above, the first controller first uses its private key to encrypt the target message, forming a first encrypted message in the format of the first controller's private key (target message). Then, it uses the first control domain's public key to encrypt the first encrypted message, forming a second encrypted message in the format of the first control domain's public key (first controller's private key (target message)). Finally, the second encrypted message is sent to the central control unit.

[0048] After receiving the second encrypted message, the central control unit confirms which control domain the first controller belongs to and which controller it is. It then decrypts the message according to the encryption order: first, it matches the private key of the first control domain to decrypt the message, obtaining the first encrypted message; then, it matches the public key of the first controller to decrypt the message, obtaining the target message. Thus, the target message is successfully and securely transmitted from the first controller to the central control unit. Next, it confirms which control domain the second controller, as the receiver, belongs to and which controller it is. To continue secure transmission to the second controller, it first matches the public key of the second controller to encrypt the target message, forming a third encrypted message in the format of the second controller's public key (target message). Then, it uses the private key of the second control domain to encrypt the third encrypted message, forming a fourth encrypted message in the format of the second control domain's private key (second controller's public key (target message)). Finally, it sends the fourth encrypted message to the second controller in the second control domain.

[0049] After receiving the fourth encrypted message, the second controller decrypts it according to the encryption order. First, it decrypts it using the public key of the second control domain to obtain the third encrypted message. Then, it decrypts it using its own private key to obtain the target message. In this way, the target message is successfully transmitted securely from the central control unit to the second controller, thus completing the cross-domain communication from the first controller to the second controller.

[0050] By specifically applying the keys related to the first controller, the first control domain, the second control domain, and the second controller, as well as the two asymmetric encrypted communications between the first controller and the central control unit, and between the central control unit and the second controller, cross-domain isolation is achieved, preventing cross-domain eavesdropping of bus data and improving data security.

[0051] In step S103, when the receiver is the third controller, the first controller and the third controller communicate symmetrically encrypted using the communication key of the corresponding control domain to send the target message from the first controller to the third controller.

[0052] When the receiver is a third controller, it means that same-domain communication is required. Since cross-domain isolation is not required, communication keys can achieve better communication efficiency than controller keys and control domain keys. Therefore, same-domain communication is completed through symmetric encrypted communication based on communication keys.

[0053] refer to Figure 6 In some embodiments, the first controller and the third controller perform symmetric encrypted communication using communication keys corresponding to their respective control domains, including: Step S601: The target message is encrypted using the communication key by the first controller to obtain the fifth encrypted message, and the fifth encrypted message is sent to the third controller. Step S602: Receive the fifth encrypted message through the third controller, and decrypt the fifth encrypted message using the communication key to obtain the target message.

[0054] Referring to the controller key management situation in Table 2 above, the first controller and the third controller in the same domain both store the same first communication key. Based on this, the first controller uses the first communication key to encrypt the target message and obtain a fifth encrypted message in the format of the first communication key (target message), and then sends the fifth encrypted message to the third controller.

[0055] After receiving the fifth encrypted message, the third controller also uses the first communication key to decrypt it, thereby obtaining the target message and completing the symmetric encrypted communication within the same domain.

[0056] By enabling symmetric encryption communication between communication controllers within the domain using communication keys, other non-communication controllers within the domain cannot decrypt the encrypted messages even if they mistakenly receive them. This prevents eavesdropping programs on these controllers from engaging in eavesdropping activities, effectively shielding non-communication controllers within the same domain and thus improving data security.

[0057] Steps S101 to S103 as illustrated in this application embodiment address two scenarios: when communicating with a controller in the same domain, symmetric encryption is performed using a communication key to shield the non-communicating controller in the same domain; when communicating with a controller in a different domain, asymmetric encryption is performed via a central control unit using a controller key and a control domain key to achieve cross-domain isolation, thereby preventing cross-domain or same-domain eavesdropping of bus data and improving vehicle data security.

[0058] The following is a detailed description and explanation of the solutions in the embodiments of the present invention, using specific application examples: In this embodiment of the application, an in-vehicle isolation communication method based on key management is provided. This method can be applied to a vehicle including a first controller, a second controller, a third controller and a central control unit, wherein the second controller is a non-same-domain controller of the first controller and the third controller is a same-domain controller of the first controller.

[0059] Before implementing encrypted communication, control domain keys and controller keys must first be generated. When the vehicle rolls off the production line and the system is powered on, the 31 service control command is triggered via the EOL diagnostic port to generate control domain keys. The central control unit uses the RSA algorithm to generate and store the control domain public key and control domain private key for each control domain. The control domain key includes both the public and private keys. Then, each control domain public key is broadcast to its corresponding control domain, enabling each controller in that domain to receive and store the public key.

[0060] After each controller in each control domain receives and stores the control domain public key, each controller generates and stores its own controller public key and controller private key using the RSA algorithm. The controller key includes the controller public key and controller private key. Then, the controller public key is encrypted using the received control domain public key, and the encrypted controller public key is sent to the central control unit, so that the central control unit receives and stores the controller public key corresponding to each controller. On the other hand, the controller also trims the received control domain public key to obtain a communication key that meets the preset specifications, and stores the communication key.

[0061] Through the above steps, each controller stores its corresponding controller public key, controller private key, and control domain public key of its respective control domain. The central control unit stores the controller public key of each controller, the control domain public key and control domain private key of each control domain, and each controller also stores the communication key of its corresponding control domain.

[0062] The target message is obtained through a first controller, which is the sender of the target message and determines the receiver of the target message.

[0063] When the receiver is a second controller outside the same domain, the first controller encrypts the target message using its private key to obtain a first encrypted message, then encrypts the first encrypted message using its public key to obtain a second encrypted message, and sends the second encrypted message to the central control unit. The control domain to which the first controller belongs is defined as the first control domain. The central control unit receives the second encrypted message, decrypts it using its private key to obtain the first encrypted message, then decrypts it using its public key to obtain the target message. It then confirms the second control domain to which the second controller belongs, encrypts the target message using its public key to obtain a third encrypted message, then encrypts it using its private key to obtain a fourth encrypted message, and sends the fourth encrypted message to the second controller. The second controller receives the fourth encrypted message, decrypts it using its public key to obtain the third encrypted message, and then decrypts it using its private key to obtain the target message.

[0064] When the receiver is the third controller, the first controller uses the communication key to encrypt the target message to obtain the fifth encrypted message, and sends the fifth encrypted message to the third controller; the third controller receives the fifth encrypted message and uses the communication key to decrypt the fifth encrypted message to obtain the target message; wherein, the first controller and the third controller store the same communication key.

[0065] This application embodiment addresses two scenarios: co-domain controllers and non-co-domain controllers. When communicating with a co-domain controller, symmetric encryption is used via a communication key to shield non-co-domain controllers. When communicating with a non-co-domain controller, asymmetric encryption is used via a controller key and a control domain key through the central control unit to achieve cross-domain isolation, thereby preventing cross-domain or co-domain eavesdropping of bus data and improving vehicle data security.

[0066] Please see Figure 7 This application also provides an in-vehicle isolation communication system based on key management, which can implement the above-described method. The vehicle includes a first controller, a second controller, a third controller, and a central control unit, wherein the second controller is a non-local controller of the first controller, and the third controller is a local controller of the first controller. The system includes: The first processing module is used to obtain the target message through the first controller and determine the recipient of the target message, wherein the first controller is the sender of the target message; The second processing module, in response to the receiver being the second controller, controls the first controller, the second controller, and the central control unit to perform asymmetric encrypted communication through the controller key and the control domain key, so as to send the target message from the first controller to the central control unit, and then send it to the second controller through the central control unit; The third processing module, in response to the receiver being the third controller, controls the first controller and the third controller to perform symmetric encrypted communication using the communication key of the corresponding control domain, so as to send the target message from the first controller to the third controller.

[0067] It is understood that the content of the above method embodiments is applicable to this system embodiment. The specific functions implemented in this system embodiment are the same as those in the above method embodiments, and the beneficial effects achieved are also the same as those achieved in the above method embodiments.

[0068] Reference Figure 8 The present invention also provides a vehicle control device, including a memory, a processor, and a program stored in the memory and executable on the processor. When the program is executed by the processor, it implements the method described in the above embodiments.

[0069] Taking the example of a processor and memory in a vehicle controller being connected via a bus, the memory, as a non-transitory computer-readable storage medium, can be used to store non-transitory software programs and non-transitory computer-executable programs. Furthermore, the memory may include high-speed random access memory, and may also include non-transitory memory, such as at least one disk storage device, flash memory device, or other non-transitory solid-state storage device. In some embodiments, the memory may optionally include memory remotely located relative to the control processor, and these remote memories can be connected to the control device via a network.

[0070] The non-transient software program and instructions required to implement the control method of the above embodiments are stored in memory. When executed by a processor, the method in the above embodiments is performed. For example, executing... Figure 1 The method steps S101 to S103 are described above. It is understood that the content of the above method embodiments is applicable to this device, and the specific functions implemented in this device embodiment are the same as those in the above method embodiments, and the beneficial effects achieved are also the same as those achieved in the above method embodiments.

[0071] Memory, as a non-transitory computer-readable storage medium, can be used to store non-transitory software programs and non-transitory computer-executable programs. Furthermore, memory may include high-speed random access memory, and may also include non-transitory memory, such as at least one disk storage device, flash memory device, or other non-transitory solid-state storage device. In some embodiments, memory may optionally include memory remotely located relative to the processor, and these remote memories can be connected to the processor via a network. Examples of such networks include, but are not limited to, the Internet, intranets, local area networks, mobile communication networks, and combinations thereof.

[0072] This invention also provides a vehicle, including the vehicle control device described in the above embodiments.

[0073] The vehicle can be a private car, such as a sedan, SUV, MPV, or pickup truck. It can also be a commercial vehicle, such as a van, bus, small truck, or large semi-trailer. The vehicle must have an electric motor capable of outputting power or acting as a generator to store mechanical energy. When the vehicle is a new energy vehicle, it can be a hybrid or a pure electric vehicle.

[0074] Since the vehicle applies all the technical solutions of the above-described system or vehicle control device, it has at least all the beneficial effects brought about by the technical solutions of the above embodiments, which will not be repeated here.

[0075] The embodiments described in this application are for the purpose of more clearly illustrating the technical solutions of the embodiments of this application, and do not constitute a limitation on the technical solutions provided by the embodiments of this application. As those skilled in the art will know, with the evolution of technology and the emergence of new application scenarios, the technical solutions provided by the embodiments of this application are also applicable to similar technical problems.

[0076] Those skilled in the art will understand that the technical solutions shown in the figures do not constitute a limitation on the embodiments of this application, and may include more or fewer steps than shown, or combine certain steps, or different steps.

[0077] The device embodiments described above are merely illustrative. The units described as separate components may or may not be physically separate; that is, they may be located in one place or distributed across multiple network units. Some or all of the modules can be selected to achieve the purpose of this embodiment according to actual needs.

[0078] Those skilled in the art will understand that all or some of the steps in the methods disclosed above, as well as the functional modules / units in the systems and devices, can be implemented as software, firmware, hardware, or suitable combinations thereof.

[0079] In the several embodiments provided in this application, it should be understood that the disclosed apparatus and methods can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative; for instance, the division of the units described above is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be through some interfaces; the indirect coupling or communication connection between apparatuses or units may be electrical, mechanical, or other forms.

[0080] The units described above as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0081] Furthermore, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit.

[0082] If the integrated unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or all or part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes multiple instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods of the various embodiments of this application. The aforementioned storage medium includes various media capable of storing programs, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0083] The preferred embodiments of the present application have been described above with reference to the accompanying drawings, but this does not limit the scope of the claims of the present application. Any modifications, equivalent substitutions, and improvements made by those skilled in the art without departing from the scope and substance of the embodiments of the present application shall be within the scope of the claims of the present application.

Claims

1. A vehicle-to-everything (V2X) isolation communication method based on key management, characterized in that, The vehicle includes a first controller, a second controller, a third controller, and a central control unit, wherein the second controller is a non-local controller of the first controller, and the third controller is a local controller of the first controller. The method includes the following steps: The first controller acquires the target message and determines the recipient of the target message, wherein the first controller is the sender of the target message; When the receiver is the second controller, the first controller, the second controller, and the central control unit communicate asymmetrically encrypted using a controller key and a control domain key to send the target message from the first controller to the central control unit, and then through the central control unit to the second controller. When the receiver is the third controller, the first controller and the third controller communicate with each other using symmetric encryption via communication keys of the corresponding control domains to send the target message from the first controller to the third controller.

2. The method according to claim 1, characterized in that, Before obtaining the target message through the first controller, the method further includes generating the control domain key through the central control unit, including: The central control unit uses the RSA algorithm to generate and store the control domain public key and control domain private key for each control domain. The control domain key includes the control domain public key and control domain private key. The central control unit broadcasts the public keys of each control domain to the corresponding control domain, so that each controller in the corresponding control domain receives and stores the public key of the control domain. The controller includes the first controller, the second controller and the third controller.

3. The method according to claim 2, characterized in that, After each controller in the corresponding control domain receives and stores the control domain public key, the method further includes: The controller generates and stores a public key and a private key using the RSA algorithm, wherein the controller key includes the public key and the private key. The controller encrypts the controller public key using the received control domain public key and sends the encrypted controller public key to the central control unit, so that the central control unit receives and stores the controller public key corresponding to each controller.

4. The method according to claim 2, characterized in that, After each controller in the corresponding control domain receives and stores the control domain public key, the method further includes: The controller trims the received control domain public key to obtain a communication key that meets preset specifications, and then stores the communication key.

5. The method according to claim 2, characterized in that, The method further includes: When the vehicle rolls off the production line and the system is powered on, the 31 service control command is triggered through the EOL diagnostic port to execute the step of generating the control domain key through the central control unit.

6. The method according to any one of claims 1 to 5, characterized in that, Each controller stores a corresponding controller public key, controller private key, and control domain public key of its respective control domain. The central control unit stores the controller public key of each controller, the control domain public key of each control domain, and the control domain private key. The controller key includes the controller public key and controller private key, and the control domain key includes the control domain public key and control domain private key. The first controller, the second controller, and the central control unit perform asymmetric encrypted communication using the controller key and the control domain key, including: The first controller encrypts the target message using its private key to obtain a first encrypted message, and then encrypts the first encrypted message using its public key to obtain a second encrypted message. The second encrypted message is then sent to the central control unit. The control domain to which the first controller belongs is defined as the first control domain. The central control unit receives the second encrypted message, decrypts the second encrypted message using the private key of the first control domain to obtain the first encrypted message, decrypts the first encrypted message using the public key of the first controller to obtain the target message, confirms the second control domain to which the second controller belongs, encrypts the target message using the public key of the second controller to obtain the third encrypted message, encrypts the third encrypted message using the private key of the second control domain to obtain the fourth encrypted message, and sends the fourth encrypted message to the second controller. The second controller receives the fourth encrypted message, decrypts the fourth encrypted message using the second control domain public key to obtain the third encrypted message, and decrypts the third encrypted message using the second controller private key to obtain the target message.

7. The method according to any one of claims 1 to 5, characterized in that, The first controller and the third controller communicate using symmetric encrypted communication keys corresponding to their respective control domains, including: The first controller uses the communication key to encrypt the target message to obtain a fifth encrypted message, and then sends the fifth encrypted message to the third controller. The third controller receives the fifth encrypted message and decrypts it using the communication key to obtain the target message; wherein the first controller and the third controller store the same communication key.

8. A vehicle-to-everything (V2X) communication system based on key management, characterized in that, The vehicle includes a first controller, a second controller, a third controller, and a central control unit, wherein the second controller is a non-local controller of the first controller, and the third controller is a local controller of the first controller. The system includes: The first processing module is used to acquire the target message through the first controller and determine the recipient of the target message, wherein the first controller is the sender of the target message; The second processing module, in response to the receiver being the second controller, controls the first controller, the second controller, and the central control unit to perform asymmetric encrypted communication through a controller key and a control domain key, so as to send the target message from the first controller to the central control unit, and then send it to the second controller through the central control unit; The third processing module, in response to the receiver being the third controller, controls the first controller and the third controller to perform symmetric encrypted communication using the communication key of the corresponding control domain, so as to send the target message from the first controller to the third controller.

9. A vehicle control device, characterized in that, The apparatus includes a memory and a processor, the memory storing a computer program, and the processor executing the computer program to implement the method of any one of claims 1 to 7.

10. A vehicle, characterized in that, The vehicle is equipped with the vehicle control device as described in claim 9.