An intelligent vehicle-oriented vehicle-mounted ECU communication method and system

Abstract

The application discloses a kind of vehicle-mounted ECU communication methods and systems for intelligent car, belong to vehicle communication field.The method includes building a vehicle cloud collaborative strategy center controlled by OEM, for each vehicle, the vehicle cloud collaborative strategy center generates and issues a digital vehicle-mounted equipment relationship voucher VDAC according to its factory configuration or authorized change;The VDAC is a structured list, for defining the authorized communication object of each ECU in the current vehicle;Each ECU obtains its own VDAC fragment and stores when starting or updating the voucher by the vehicle cloud collaborative strategy center;Communication is carried out between each ECU based on its own VDAC fragment.The application proposes a systematic solution that can uniformly manage the identity of vehicle-mounted ECU, dynamically define and execute the authorization strategy of ECU communication, and establish secure communication on the basis of verified trust relationship.

Description

Technical Field

[0001] This invention belongs to the field of vehicle communication. Specifically, this invention relates to an in-vehicle ECU communication method and system for intelligent vehicles. Background Technology

[0002] The existing communication between vehicle ECUs has the following problems: 1) Coarse-grained trust and lack of authorization strategy: Under the current technological framework, an ECU with a legitimate OEM certificate can, in principle, establish a connection with any other ECU in the vehicle that supports TLS. This cannot effectively prevent hardware kit porting attacks, such as a legitimate ECU removed from an accident vehicle being privately transplanted to another vehicle and establishing unauthorized communication with other ECUs in that vehicle.

[0003] 2) Fixed Trust Relationships and Disconnected Lifecycle Management: The trust topology within a vehicle tends to become static and fixed after it rolls off the production line. When an ECU is replaced, how to synchronously update the trust relationships between all relevant ECUs in the vehicle becomes a blind spot in current technology.

[0004] 3) Security mechanisms and communication efficiency are difficult to coordinate: The certificate-based TLS handshake process has a large computational and communication overhead, which is difficult to meet the needs of high-frequency service calls that are extremely sensitive to latency; while SecOC or pre-shared key-based schemes have advantages in communication efficiency, the initial secure distribution and dynamic synchronization update of their keys or ciphers themselves pose a major challenge, especially in scenarios where device relationships change dynamically. Summary of the Invention

[0005] This invention aims to overcome the shortcomings of existing technologies and proposes a vehicle ECU communication method and system for intelligent vehicles to achieve the following objectives: to provide a systematic solution that can uniformly manage the identity of vehicle ECUs, dynamically define and execute inter-ECU communication authorization policies, and establish secure communication on verified trust relationships.

[0006] To achieve the above objectives, the technical solution adopted by the present invention is as follows: This invention provides a vehicle ECU communication method for intelligent vehicles. The method includes: constructing a vehicle-cloud collaborative strategy center controlled by the OEM; for each vehicle, the vehicle-cloud collaborative strategy center generates and issues a digital vehicle device relationship certificate (VDAC) based on its factory configuration or authorization changes; the VDAC is a structured list that specifies all authorized communication objects for each ECU in the current vehicle; each ECU obtains and stores its own VDAC fragment through the vehicle-cloud collaborative strategy center when starting up or updating the certificate; and the ECUs communicate with each other based on their respective VDAC fragments.

[0007] Furthermore, communication between the various ECUs based on their respective VDAC slices includes: constructing a two-stage trusted communication protocol based on VDAC; wherein, the first stage is used for VDAC relationship verification between the communicating parties and for generating a communication root key; the second stage is used for establishing a business data channel between the communicating parties based on the communication root key generated in the first stage.

[0008] Furthermore, for the two communicating parties, namely ECU_A and ECU_B, the workflow of the first stage includes: Step S101: The application layer of ECU_A initiates a secure data transmission request with ECU_B; Step S102: The security stack of ECU_A checks whether there is a long-term communication root key with ECU_B locally. If there is, continue to the next step; otherwise, jump to the second stage. Step S103: Establish a boot link between ECU_A and ECU_B; Step S104: Based on the boot connection, ECU_B obtains the device certificate of ECU_A and performs device certificate verification; if the verification is successful, proceed to the next step; otherwise, record the DTC and terminate the boot connection. Step S105: ECU_B extracts its device serial number SN_A from the device certificate of ECU_A; Step S106: ECU_B performs VDAC authorization verification based on the locally stored VDAC fragment and ECU_A's device serial number SN_A. If the VDAC authorization verification is successful, proceed to the next step; otherwise, record the DTC and terminate the boot connection. Step S107: Swap the identities of ECU_A and ECU_B, and repeat steps S101 to S106. If the device certificate and VDAC authorization verification of ECU_B are both passed, continue to the next step; otherwise, record the DTC and terminate the boot connection. In step S108, ECU_A and ECU_B negotiate a long-term communication root key based on the secure channel constructed by the boot connection and store it in their respective hardware security modules. Step S109: Terminate the boot connection between ECU_A and ECU_B.

[0009] Furthermore, the bootstrap connection includes a TLS connection.

[0010] Furthermore, in step S104, the device certificate verification includes: verifying the certificate chain, validity period, and revocation status of the device certificate; the device certificate is considered to have passed verification only if the certificate chain verification is successful, the device certificate is within its validity period, and the certificate has not been revoked.

[0011] Furthermore, in step S106, ECU_B performs VDAC authorization verification based on the locally stored VDAC fragment and the device serial number SN_A of ECU_A, including: ECU_B reads locally stored VDAC fragments to obtain the list of authorized peers; ECU_B checks whether SN_A exists in the list of authorized peers; if it does, ECU_B considers ECU_A to be trustworthy and considers the VDAC authorization verification to be successful.

[0012] Furthermore, for the two communicating parties, namely ECU_A and ECU_B, the workflow of the second stage includes: In step S201, ECU_A and ECU_B directly use the long-term communication root key negotiated in the first phase to derive the session key; Step S202: Based on the session key, both parties establish a business data channel through a lightweight security protocol.

[0013] Furthermore, the lightweight security protocol includes PSK-based TLS or a custom symmetric encryption channel.

[0014] Furthermore, the method also constructs a full lifecycle trust dynamic update mechanism, namely, a trust update interface is preset on the vehicle central gateway, wherein the vehicle central gateway is communicatively connected to each vehicle ECU and to the vehicle-cloud collaborative strategy center through the TBOX; external devices trigger the trust dynamic update mechanism through the trust update interface; specifically including: Step 1: The vehicle central gateway collects trust data from each ECU, builds a trust tree, and generates a dynamic trust update request; Step 2: The trust tree and trust dynamic update request are uploaded to the vehicle-cloud collaboration strategy center via TBOX; Step 3: After verifying the legitimacy of the request, the vehicle-cloud collaboration strategy center constructs a trust policy based on the trust tree information, generates a VDAC_List, and signs it; Step 4: The vehicle-cloud collaborative strategy center transmits the signed VDAC to the vehicle-side TBOX; Step 5: After TBOX verifies the signature, it passes VDAC_List to the vehicle central gateway; Step 6: The vehicle central gateway stores and distributes VDAC fragments to the relevant ECUs according to the VDAC_List; Step 7: Each relevant ECU stores the VDAC fragments distributed to it.

[0015] This invention also provides an in-vehicle ECU communication system for intelligent vehicles, using the aforementioned in-vehicle ECU communication method for intelligent vehicles. The system includes: a vehicle-cloud collaborative strategy center, an in-vehicle central gateway, a TBOX, ECUs, and external devices. The in-vehicle central gateway is communicatively connected to each vehicle ECU and communicates with the vehicle-cloud collaborative strategy center via the TBOX. The external devices communicate with the in-vehicle central gateway through a preset trust update interface, and include production line electrical testing equipment and after-sales diagnostic equipment. The vehicle-cloud collaborative strategy center is constructed according to the aforementioned in-vehicle ECU communication method for intelligent vehicles. Each ECU communicates with the others according to the aforementioned in-vehicle ECU communication method for intelligent vehicles.

[0016] The technical effects of this invention are as follows: 1) A vehicle-level, strategy-based ECU mutual trust system has been established: Through VDAC, the OEM's assembly and maintenance strategies are transformed into in-vehicle executable and verifiable safety rules, realizing the leap from "link security" to "relationship security" and effectively resisting the network penetration risk caused by illegal ECU replacement.

[0017] 2) It realizes automated and dynamic management of trust relationships: The dynamic trust update mechanism throughout the entire life cycle enables the trust topology to be dynamically adjusted according to the vehicle status, perfectly supporting large-scale production and agile after-sales service, and significantly reducing operation and maintenance costs.

[0018] 3) It achieves the optimal balance between security and performance: The two-phase protocol limits the high-overhead trust establishment process (certificate + VDAC verification) to low-frequency events, thereby providing an extremely efficient security channel for high-frequency business data and meeting the requirements of high real-time services such as intelligent driving.

[0019] 4) Strong compatibility and scalability: This solution is decoupled from the underlying network type (Ethernet, CANFD) and upper-layer application protocols (SOME / IP, DDS). The VDAC mechanism can serve as an in-vehicle security middleware, providing a unified basic trust service for secure interaction between various in-vehicle components. Attached Figure Description

[0020] Figure 1 This invention provides an architecture diagram of an in-vehicle ECU communication system for intelligent vehicles. Detailed Implementation

[0021] The specific embodiments of the present invention will be further described in detail below with reference to the accompanying drawings. This is to help those skilled in the art to have a more complete, accurate, and in-depth understanding of the inventive concept and technical solutions of the present invention, and to facilitate its implementation. It should be noted that the terms "first," "second," etc., used in this application are only for the convenience of describing the technical solutions and to distinguish components; the corresponding component configurations may be the same or different, and are not intended to limit the scope of this application. To make the technical solutions of the present invention clearer, the following explanations are provided.

[0022] This invention provides a vehicle ECU communication method for intelligent vehicles, aiming to solve the following technical problems: 1. Address the communication risk between in-vehicle ECUs that are legally identified but have illegal relationships: that is, how to ensure that only ECUs authorized by the OEM and belonging to the specific configuration of the vehicle can establish a secure communication link, and prevent unauthorized ECUs (even if they have legal certificates) from accessing the in-vehicle security network.

[0023] 2. Achieve dynamic and automated lifecycle management of vehicle-level trust relationships: How to enable the trust relationships between ECUs in the vehicle to flexibly adapt to scenarios such as production line rollout, software OTA, and hardware replacement (especially after-sales maintenance), and achieve centralized policy distribution and automatic synchronous verification between ECUs, thereby significantly reducing the complexity of operation and maintenance.

[0024] 3. Construct a secure communication paradigm of one-time authentication and multiple efficient communications: How to design a secure communication protocol that can not only complete strict identity and authorization verification, but also provide a low-overhead, low-latency secure channel for subsequent high-frequency business data interaction, fundamentally solving the contradiction between security and efficiency.

[0025] This invention provides a vehicle ECU communication method for intelligent vehicles, comprising: constructing a vehicle-cloud collaborative strategy center controlled by the OEM; for each vehicle, the vehicle-cloud collaborative strategy center generates and issues a digital vehicle device relationship certificate (VDAC) based on its factory configuration or authorization changes, the VDAC being signed by the private key of the vehicle-cloud collaborative strategy center; the VDAC is a structured list used to specify all authorized communication objects for each ECU in the current vehicle; each ECU obtains and stores its own VDAC fragment through the vehicle-cloud collaborative strategy center upon startup or certificate update; and the ECUs communicate with each other based on their respective VDAC fragments.

[0026] The communication between each ECU based on its own VDAC slice includes: constructing a two-stage trusted communication protocol based on VDAC; wherein, the first stage is used for VDAC relationship verification between the two communicating parties and for generating the communication root key; the second stage is used for the two communicating parties to establish a business data channel based on the communication root key generated in the first stage.

[0027] In addition, the method of the present invention also constructs a trust dynamic update mechanism throughout the entire life cycle, that is, a trust update interface is preset on the vehicle central gateway, wherein the vehicle central gateway is communicatively connected to each vehicle ECU and is communicatively connected to the vehicle-cloud collaborative strategy center through TBOX; external devices trigger the trust dynamic update mechanism through the trust update interface.

[0028] Based on the above, the core technical solution of this invention revolves around three main components: the vehicle-cloud collaborative strategy center and the VDAC credential system, the two-phase trusted communication protocol based on VDAC, and the dynamic trust update mechanism throughout the entire lifecycle. The following will describe in detail the design principles, implementation methods, and technical effects of each component, starting from the overall technical architecture.

[0029] First, this invention constructs a vehicle-cloud collaborative strategy center controlled by the OEM. This center does not participate in real-time in-vehicle communication but possesses control over the ECU configuration policies of all vehicles. As the core control node of the entire in-vehicle security communication system, it is responsible for centralized management and policy distribution of the relationships between all vehicle in-vehicle devices. Deployed in a cloud server cluster, this center boasts high availability and high security, employing multi-factor authentication, access control, and encrypted data storage to ensure its own security. As the vehicle manufacturer and the ultimate responsible party, the OEM has the highest management authority over the vehicle's security configuration; therefore, OEM control of this vehicle-cloud collaborative strategy center ensures the security of the root of trust and the consistency of policies.

[0030] For each vehicle, the Vehicle-Cloud Collaboration Strategy Center generates and issues a digital Vehicle Device Relationship Certificate (VDAC) based on its factory configuration or subsequent authorized changes (such as repairs). This VDAC serves as the strategic anchor for establishing mutual trust relationships between ECUs. This certificate is signed with the Vehicle-Cloud Collaboration Strategy Center's private key, ensuring immutability and verifiability. During the factory configuration phase, the Vehicle-Cloud Collaboration Strategy Center determines the types and quantities of all ECUs installed in the vehicle, as well as their pre-defined communication relationships, based on the vehicle's design specifications. For example, a typical intelligent vehicle may contain multiple ECUs, including a powertrain domain controller, chassis domain controller, body domain controller, infotainment domain controller, Advanced Driver Assistance System (ADAS) controller, Battery Management System (BMS), airbag controller, door controller, seat controller, air conditioning controller, instrument panel controller, central gateway, and TBOX. Based on functional safety and information security requirements, the Vehicle-Cloud Collaboration Strategy Center defines a list of authorized communication objects for each ECU.

[0031] The core of VDAC is a structured list that explicitly defines which other ECUs each ECU in the vehicle is authorized to communicate securely with—that is, all the communication partners authorized to each ECU currently in the vehicle. Each ECU securely acquires and stores its own VDAC fragment upon startup or credential update. A VDAC fragment refers to the portion of information extracted from the complete VDAC that is only relevant to that ECU, namely, the ECU's identification information and its list of authorized peers. The design considerations for adopting a fragmentation mechanism are: firstly, each ECU only needs to know its own communication authorization scope, without needing to know the complete communication topology of the entire vehicle, which conforms to the principle of least privilege and reduces the risk of global information exposure due to single-point leakage; secondly, the data volume of VDAC fragments is small, making it easy to store and transmit in environments with limited ECU resources. The ECU stores the acquired VDAC fragments in a local secure storage area, such as the secure storage area of ​​the Hardware Security Module (HSM) or a Trusted Execution Environment (TEE), to prevent unauthorized access and tampering.

[0032] This invention achieves refined authorization management of in-vehicle ECU communication relationships by introducing a VDAC credential system centrally managed by the OEM. Traditional in-vehicle network security solutions often rely on fixed network topologies and physically isolated domain controller architectures, lacking flexible communication authorization mechanisms. The VDAC credential system digitizes and credentializes communication authorization relationships, enabling OEMs to customize personalized communication strategies for each vehicle and each ECU based on specific vehicle configurations and security requirements. Simultaneously, the VDAC fragmentation mechanism, while ensuring functional implementation, minimizes the security-sensitive information held by each ECU, adhering to the principle of least knowledge in security design. Even if an ECU is compromised, attackers cannot obtain the complete communication topology information of the entire vehicle from the VDAC fragments of that ECU, effectively curbing the lateral spread of attacks.

[0033] Then, based on the aforementioned VDAC credential system, the various ECUs of the vehicle communicate with each other based on their respective VDAC fragments. This embodiment constructs a two-stage trusted communication protocol based on VDAC for this purpose. This protocol divides the secure communication process between ECUs into two logical stages: the first stage is used for VDAC relationship verification and communication root key generation between the communicating parties; the second stage is used for establishing a business data channel between the communicating parties based on the communication root key generated in the first stage. The core idea of ​​this two-stage design is to decouple the trust establishment process from the business data transmission process, so that frequent business data exchanges do not require repeated execution of complex authentication and key negotiation processes, thereby improving communication efficiency while ensuring security.

[0034] Specifically, the first phase of the workflow involves two-way authentication and key negotiation between the communicating parties, ECU_A and ECU_B. For the two communicating parties, namely ECU_A and ECU_B, the workflow of the first phase is as follows: steps S101 to S109.

[0035] Step S101: The application layer of ECU_A initiates a secure data transmission request with ECU_B; this request is passed to the security stack of ECU_A for processing; Step S102: ECU_A's security stack checks if it has a long-term communication root key with ECU_B. The long-term communication root key is a key negotiated and persistently stored after the successful completion of the first phase protocol, used for key derivation in all subsequent communication sessions with the peer ECU. If the key already exists locally, it indicates that the two parties have successfully established a trust relationship, and the security stack can directly jump to the second phase, using the long-term communication root key to quickly establish a business data channel, thereby avoiding repeated execution of complex authentication processes and significantly reducing communication latency and computational overhead. If the key does not exist locally, proceed to the next step of the first phase.

[0036] Step S103: Establish a bootstrap connection between ECU_A and ECU_B. The bootstrap connection serves as a temporary secure channel for initial authentication and key negotiation between the two parties. It requires high security but has a short duration. In a preferred implementation, the bootstrap connection uses a TLS connection. The TLS protocol provides mature encryption, authentication, and integrity protection mechanisms, effectively resisting common network attacks such as man-in-the-middle attacks and replay attacks. The two parties establish an encrypted channel through a TLS handshake process, ensuring that sensitive information exchanged subsequently (such as device certificates, VDAC verification information, etc.) is not eavesdropped on or tampered with during transmission.

[0037] Step S104: Based on the boot connection, ECU_B obtains the device certificate of ECU_A and performs device certificate verification. If the verification is successful, proceed to the next step; otherwise, record the DTC and terminate the boot connection. The device certificate is a digital certificate issued by the OEM or its authorized Certificate Authority (CA) for each ECU, containing key information such as the ECU's public key, device serial number, issuing authority information, and validity period. Device certificate verification is a multi-layered security check process, including certificate chain verification, validity period verification, and revocation status verification. Certificate chain verification ensures that the certificate is issued by a trusted CA and that each certificate in the certificate chain is valid; validity period verification ensures that the certificate remains valid within the current date and time range; revocation status verification confirms whether the certificate has been revoked by the issuing authority by querying the certificate revocation list or online certificate status protocol. Device certificate verification is considered successful only if the certificate chain verification is successful, the device certificate is within its validity period, and the certificate has not been revoked. This rigorous certificate verification mechanism ensures the authenticity of the communication peer's identity and the validity of the certificate, preventing unauthorized communication using forged, expired, or revoked certificates.

[0038] Step S105: After the device certificate verification is successful, ECU_B extracts its device serial number SN_A from the device certificate of ECU_A. The device serial number, as the unique hardware identifier of the ECU, is globally unique and immutable, and is a key basis for VDAC authorization verification. Step S106: ECU_B performs VDAC authorization verification based on the locally stored VDAC fragment and ECU_A's device serial number SN_A. If the VDAC authorization verification passes, proceed to the next step; otherwise, record a DTC and terminate the boot connection. Specifically, ECU_B reads the locally stored VDAC fragment to obtain an authorized peer list, which records the device serial numbers of all peer ECUs authorized to communicate with this ECU. ECU_B checks whether SN_A exists in the authorized peer list. If SN_A exists in the authorized peer list, ECU_B considers ECU_A to be a trusted communication object authorized by the OEM, and the VDAC authorization verification passes; if SN_A is not in the authorized peer list, it means that ECU_A is not within ECU_B's authorized communication range, and there may be unauthorized access or configuration errors. In this case, record a DTC and terminate the boot connection.

[0039] Step S107: Swap the identities of ECU_A and ECU_B, and repeat steps S101 to S106. If the device certificate and VDAC authorization verification of ECU_B are both passed, continue to the next step; otherwise, record the DTC and terminate the boot connection.

[0040] After the one-way verification in steps S101 to S106 is completed, the identities of ECU_A and ECU_B are swapped, and the same verification process is repeated. Specifically, ECU_A obtains ECU_B's device certificate and verifies it, extracts ECU_B's device serial number SN_B from the certificate, and then checks whether SN_B exists in its authorized peer list based on the locally stored VDAC fragment. Only when both the two-way device certificate verification and VDAC authorization verification pass are both parties confirmed to be OEM-authorized and trustworthy communication objects. This two-way authentication mechanism ensures peer-to-peer security for both communicating parties and prevents security risks that may arise from one-way authentication, such as verifying only one party's identity while the other party may be a malicious node. In step S108, ECU_A and ECU_B, based on the secure channel constructed by the bootstrap connection, negotiate a long-term communication root key dedicated to the AB communication pair and store it in their respective hardware security modules. Specifically, ECU_A and ECU_B each generate a temporary key pair, exchange temporary public keys through the bootstrap connection, and calculate the shared long-term communication root key by combining their respective long-term private keys (usually stored in their respective hardware security modules HSM). This key has high strength and randomness, effectively resisting brute-force and mathematical analysis attacks. The negotiated long-term communication root key is stored in their respective hardware security modules, utilizing the anti-tampering and anti-extraction features of the hardware security modules to ensure secure key storage.

[0041] Step S109: Finally, terminate the boot connection between ECU_A and ECU_B and release the relevant resources.

[0042] The first phase establishes a strong two-way trust relationship by combining device certificate verification and VDAC authorization verification. Device certificate verification solves the problem of identity authenticity, ensuring that the communication peer is a legitimate OEM-issued device; VDAC authorization verification solves the problem of communication authorization, ensuring that the communication peer is within the scope of the OEM's policy authorization. Together, they form a complete trust chain from identity to authorization. Simultaneously, the negotiation and verification process of the long-term communication root key is bound to the process, ensuring that key generation is only a prerequisite for successful two-way authentication. This guarantees that the key is only generated when there is a legitimate communication need, avoiding key abuse and waste. Furthermore, the persistent storage of the long-term communication root key eliminates the need to repeat the complex process of the first phase in subsequent communications, significantly improving communication efficiency, making it particularly suitable for frequent data exchange scenarios in vehicular networks.

[0043] The second-stage workflow is relatively simple and efficient. For the two communicating parties, namely ECU_A and ECU_B, the second-stage workflow includes: In step S201, ECU_A and ECU_B directly use the long-term communication root key negotiated in the first phase to derive the session key; Step S202: Based on the session key, both parties establish a business data channel through a lightweight security protocol.

[0044] ECU_A and ECU_B directly use the long-term communication root key negotiated in the first phase to derive a session key through a key derivation function (KDF). The session key is a temporary symmetric key used in each communication session, with a time limit; even if one session key is leaked, it will not affect the security of other sessions. The key derivation process can incorporate parameters such as session identifiers, timestamps, and random numbers to ensure that each derived session key is unique and unpredictable. Subsequently, based on the session key, ECU_A and ECU_B establish a business data channel through a lightweight security protocol. In a preferred implementation, the lightweight security protocol includes TLS based on a pre-shared key (PSK) or a custom symmetric encryption channel. PSK-based TLS simplifies the handshake process, reduces the overhead of certificate exchange and verification, while retaining the encryption and integrity protection capabilities of TLS; a custom symmetric encryption channel can be deeply optimized according to the specific needs of the vehicular network, further reducing protocol overhead and computational resource consumption. After the business data channel is established, both parties can conduct normal business data transmission. All transmitted data is encrypted and protected for integrity using the session key, ensuring data confidentiality and integrity. The second phase, without certificate access, achieved real-time performance with extremely low latency and CPU overhead.

[0045] The second phase fully leverages the long-term trust relationship established in the first phase, achieving efficient and secure transmission of business data through lightweight key derivation and protocol handshake. Separating the complex trust establishment process from the frequent business data transmission process is a key design feature in vehicular network environments that balances security and real-time performance. Many applications in vehicular networks, such as powertrain control, chassis collaborative control, and ADAS sensor data fusion, have strict requirements for communication latency. Performing complete two-way authentication and key negotiation for every communication would fail to meet real-time demands. The two-phase protocol design allows for lightweight session key derivation and channel establishment in routine communication after trust is established, significantly reducing communication latency and computational load. Simultaneously, the temporary and one-time use nature of session keys adheres to the minimum usage period principle in key management; even if a session is compromised, attackers cannot use the same session key to decrypt data in other sessions, effectively controlling the scope of security incidents.

[0046] Finally, this invention also constructs a full lifecycle dynamic trust update mechanism to address trust initialization after the vehicle's first production run, as well as scenarios such as ECU replacement, software upgrades, and communication relationship adjustments that may occur during vehicle use. This full lifecycle dynamic trust update mechanism relies on a pre-set trust update interface on the vehicle's central gateway. The central gateway communicates with each vehicle's ECU and with the vehicle-cloud collaborative strategy center via a TBOX. In practice, external devices can trigger the dynamic trust update mechanism through this trust update interface.

[0047] The specific execution process of the trust dynamic update mechanism includes seven steps, as shown below.

[0048] Step 1: After an external device sends diagnostic commands to the vehicle's central gateway via the trust update interface, the dynamic trust update mechanism is triggered. At this time, the vehicle's central gateway collects trust data from each ECU, constructs a trust tree, and generates a dynamic trust update request. The trust data includes the current status information, device serial number, software version number, and security status of each ECU. Based on the collected data, the vehicle's central gateway constructs a trust tree reflecting the current ECU topology and trust relationships within the vehicle and generates a formatted dynamic trust update request.

[0049] Step 2: The trust tree and trust dynamic update request are uploaded to the vehicle-cloud collaborative strategy center via TBOX. TBOX supports data encryption and integrity protection during transmission to prevent information leakage and tampering.

[0050] Step 3: The vehicle-cloud collaborative strategy center verifies the legitimacy of the request. Request legitimacy verification includes verifying the legitimacy of the request source (e.g., checking the digital signature, verifying device identity) and the reasonableness of the request content (e.g., checking if the trust tree structure is complete and if there are any abnormal nodes). After successful verification, a trust policy is constructed based on the trust tree information, the authorized peer list for each ECU is recalculated, a complete VDAC_List is generated, and the VDAC_List is signed using the OEM's private key to ensure the authenticity and integrity of the VDAC_List.

[0051] Step 4: The vehicle-cloud collaborative strategy center transmits the signed VDAC to the vehicle-side TBOX.

[0052] Step 5: After verifying the signature, TBOX passes the VDAC_List to the vehicle central gateway; TBOX uses the OEM's public key to verify the validity of the signature, confirming that the VDAC_List has not been tampered with and does indeed come from a legitimate vehicle-cloud collaboration strategy center.

[0053] Step 6: The vehicle central gateway stores and distributes VDAC fragments to the relevant ECUs according to the VDAC_List. That is, the vehicle central gateway distributes the VDAC fragments corresponding to each ECU to the corresponding ECU through the in-vehicle security channel according to the contents of the VDAC_List.

[0054] Step 7: Each relevant ECU stores the distributed VDAC fragments, replaces the old VDAC fragments, and completes the trust relationship update.

[0055] The dynamic trust update mechanism throughout the entire lifecycle endows the in-vehicle secure communication system with scalability and maintainability. The lifecycle of intelligent vehicles typically lasts over ten years, during which the vehicle's hardware and software configurations may change multiple times. Traditional static security configuration methods cannot adapt to such dynamic changes; once an update is needed, it often requires factory return or insecure local update methods. The dynamic update mechanism proposed in this application achieves remote, secure, and automated updates of VDAC credentials through vehicle-cloud collaboration. OEMs can centrally manage the trust policies of all vehicles and update vehicle communication authorization relationships in a timely manner based on security threat intelligence, software vulnerability patching, and feature upgrade needs. Simultaneously, multiple verification mechanisms during the update process (request legitimacy verification, signature verification, distribution verification, etc.) ensure the security of the update process itself, preventing malicious updates or man-in-the-middle attacks from disrupting trust relationships. Furthermore, the introduction of a trust tree allows OEMs to intuitively grasp the ECU topology and security status of each vehicle, facilitating unified security monitoring and management.

[0056] This invention also provides an in-vehicle ECU communication system for intelligent vehicles, using the in-vehicle ECU communication method for intelligent vehicles described above, such as... Figure 1 As shown, the system includes: a vehicle-cloud collaborative strategy center, an in-vehicle central gateway, a TBOX, ECUs, and external devices; wherein, the in-vehicle central gateway is communicatively connected to each vehicle ECU and is communicatively connected to the vehicle-cloud collaborative strategy center through the TBOX; the external devices are communicatively connected to the in-vehicle central gateway through a preset trust update interface, and the external devices include production line electrical inspection equipment and after-sales diagnostic equipment; the vehicle-cloud collaborative strategy center is constructed according to the above-mentioned in-vehicle ECU communication method for intelligent vehicles to establish a VDAC credential system; the various ECUs communicate with each other according to the above-mentioned in-vehicle ECU communication method for intelligent vehicles, that is, they communicate using a two-stage trusted communication protocol based on VDAC.

[0057] The invention will be further described in detail below with reference to the following embodiments.

[0058] Example 1: Trust Initialization and VDAC Filling: Before the vehicle rolls off the assembly line, each ECU is pre-loaded with a unique equipment certificate issued by the OEM PKI.

[0059] S11: Trigger: The production line terminal sends a trust network initialization command to the vehicle central gateway (as the coordination node in the vehicle) through the diagnostic interface.

[0060] S12: Information Reporting: The central gateway collects the device identifiers (read from certificates or dedicated storage areas) and vehicle VINs of all target ECUs in the vehicle, and uploads the information to the vehicle-cloud collaborative strategy center through the workshop network or the vehicle T-Box.

[0061] S13: Policy Issuance: Based on the vehicle configuration sheet corresponding to the VIN, the Vehicle-Cloud Collaborative Policy Center generates policy logic: "ECU_A (SN:A) of this vehicle (VIN:XXX) can communicate with ECU_B (SN:B); ECU_B can communicate with ECU_A and ECU_C...". Based on this, the VDAC master credential for the vehicle is generated and signed using the private key of the Vehicle-Cloud Collaborative Policy Center.

[0062] S14: Credential Issuance and Storage: The signed VDAC is issued to the central gateway via the original route. After verification, the gateway fragments the authorized peer list associated with each ECU in the VDAC and securely sends it to the corresponding ECU (e.g., sending the list containing ECU_B_SN_B to ECU_A). Each ECU persistently stores its own VDAC fragment in a secure storage area.

[0063] Example 2: Establishment of trusted communication based on VDAC and subsequent efficient and secure business communication: While the vehicle is in motion, ECU_A needs to send real-time perception data to ECU_B for HUD display.

[0064] S21: Business Request: The application layer of ECU_A initiates a secure data transmission request with ECU_B.

[0065] S22: Trigger the first phase: The security stack of ECU_A checks whether there is a long-term communication root key with ECU_B locally, and then starts the first phase protocol.

[0066] S23: Establish boot connection: ECU_A initiates a TLS 1.3 connection based on the device certificate to the fixed security port of ECU_B.

[0067] S24: Two-factor authentication: During the TLS handshake, ECU_B receives the device certificate from ECU_A. ECU_B first performs standard certificate verification (verifying the certificate chain, validity period, and whether it has been revoked). After successful certificate verification, ECU_B extracts the device serial number (SN_A) from ECU_A's certificate. ECU_B queries the locally stored VDAC fragments to check if SN_A exists in the authorized peer list. Only if the certificate verification is successful and SN_A is in the VDAC authorized list does ECU_B consider ECU_A trustworthy and continue the TLS handshake. Otherwise, it terminates the connection and reports a security event.

[0068] At the same time, ECU_A verifies ECU_B's certificate and VDAC authorization using a fully symmetrical process.

[0069] S25: Generate root key: After the bootstrap connection (TLS) is established, both parties use this secure channel to negotiate a long-term communication root key (Root Key_ECU_A&ECU_B) through the TLS key derivation function and store it in the hardware security module (HSM).

[0070] S26: Connection Transition: After this, the TLS bootstrap connection can be torn down, its mission accomplished.

[0071] S27: Initiate business communication: When ECU_A needs to send data to ECU_B again.

[0072] S28: Quickly establish a business channel: ECU_A and ECU_B directly use the previously stored long-term communication root key, i.e., Root Key_ECU_A&ECU_B.

[0073] Both parties can use a PSK-based TLS mode, using the Root Key_ECU_A & ECU_B as PSK input to quickly complete the handshake. Alternatively, a lighter-weight custom protocol can be used: deriving the encryption and MAC keys for this session from the Root Key_ECU_A & ECU_B to directly encrypt and encapsulate business data (such as SOME / IP packets) for integrity.

[0074] S293: Secure and efficient transmission: Sensing data is transmitted at high speed and in encryption over this lightweight secure channel. This process requires no certificate operations, and the extremely low latency and CPU overhead meet real-time requirements.

[0075] Example 3: After-sales ECU replacement: Suppose that ECU_B was replaced at the 4S store due to a fault (the SN of the new ECU_B is B_new).

[0076] After-sales diagnostic tools initiate a trust relationship update request to the policy center through the central gateway, attaching the new ECU_B's SN_B_new and the repair work order number.

[0077] After the strategy center verifies the validity of the work order, it generates a new VDAC for the VIN, in which the authorized peer list of ECU_A is updated to include SN_B_new.

[0078] The new VDAC fragment is securely distributed to ECU_A and the new ECU_B via a diagnostic session.

[0079] Subsequently, when ECU_A and the new ECU_B communicate for the first time, they execute steps S23-S25 of Embodiment 2, establish a trust relationship based on the new VDAC and negotiate a new Root Key_ECU_A&ECU_B_new, and the original root key with the old ECU_B immediately becomes invalid.

[0080] In summary, this invention constructs an ECU mutual trust network for intelligent vehicles that spans the entire vehicle lifecycle, is policy-driven, and automatically executes, fundamentally solving the systemic challenges of establishing trust, dynamic management, and efficiency optimization for secure communication between devices in in-vehicle distributed systems. Specifically: This invention establishes a vehicle-cloud collaborative strategy center based on the VDAC credential system. OEMs can precisely specify the authorized communication objects for each ECU, with communication authorization granularity reaching the ECU level, which is far superior to traditional coarse-grained control based on domain or network. This fine-grained authorization effectively prevents unauthorized access and illegal communication. Even if an attacker enters the in-vehicle network, they will not be able to establish communication with unauthorized ECUs, greatly improving the security boundary of the in-vehicle network. The two-stage trusted communication protocol of this invention separates the complex trust establishment process from the frequent business data transmission. Daily communication only requires lightweight session key derivation and channel establishment, which significantly reduces communication latency and computational overhead. The persistent storage of the long-term communication root key avoids the need to repeatedly perform the full two-way authentication, minimizing the additional overhead of secure communication and meeting the strict real-time requirements of vehicle networks. The present invention's full lifecycle trust dynamic update mechanism enables VDAC credentials to be securely updated as vehicle configurations change, without requiring return to the factory or manual intervention. OEMs can centrally manage the trust policies of all vehicles, responding promptly to changes in security threats and functional requirements, and maintaining the timeliness and accuracy of security policies. Multiple verification mechanisms during the update process ensure the security of the update itself.

[0081] The present invention has been described above by way of example with reference to the accompanying drawings. Obviously, the specific implementation of the present invention is not limited to the above-described manner. Any non-substantial improvements made using the inventive concept and technical solution; or the direct application of the inventive concept and technical solution to other situations without modification, are all within the protection scope of the present invention.

Claims

1. A vehicle ECU communication method for intelligent vehicles, characterized in that: The method includes: constructing a vehicle-cloud collaborative strategy center; for each vehicle, the vehicle-cloud collaborative strategy center generates and issues a digital vehicle device relationship certificate (VDAC) based on its factory configuration or authorization changes; the VDAC is a structured list that specifies all authorized communication objects for each ECU in the current vehicle; each ECU obtains and stores its own VDAC fragment through the vehicle-cloud collaborative strategy center when starting up or updating the certificate; and the ECUs communicate with each other based on their respective VDAC fragments.

2. The in-vehicle ECU communication method for intelligent vehicles according to claim 1, characterized in that: Communication between ECUs based on their respective VDAC slices includes: constructing a two-stage trusted communication protocol based on VDAC; wherein, the first stage is used for VDAC relationship verification between the communicating parties and for generating a communication root key; the second stage is used for establishing a business data channel between the communicating parties based on the communication root key generated in the first stage.

3. The in-vehicle ECU communication method for intelligent vehicles according to claim 2, characterized in that: For the two communicating parties, namely ECU_A and ECU_B, the workflow of the first stage includes: Step S101: The application layer of ECU_A initiates a secure data transmission request with ECU_B; Step S102: The security stack of ECU_A checks whether there is a long-term communication root key with ECU_B locally. If there is, continue to the next step; otherwise, jump to the second stage. Step S103: Establish a boot link between ECU_A and ECU_B; Step S104: Based on the boot connection, ECU_B obtains the device certificate of ECU_A and performs device certificate verification; if the verification is successful, proceed to the next step; otherwise, record the DTC and terminate the boot connection. Step S105: ECU_B extracts its device serial number SN_A from the device certificate of ECU_A; Step S106: ECU_B performs VDAC authorization verification based on the locally stored VDAC fragment and ECU_A's device serial number SN_A. If the VDAC authorization verification is successful, proceed to the next step; otherwise, record the DTC and terminate the boot connection. Step S107: Swap the identities of ECU_A and ECU_B, and repeat steps S101 to S106. If the device certificate and VDAC authorization verification of ECU_B are both passed, continue to the next step; otherwise, record the DTC and terminate the boot connection. In step S108, ECU_A and ECU_B negotiate a long-term communication root key based on the secure channel constructed by the boot connection and store it in their respective hardware security modules. Step S109: Terminate the boot connection between ECU_A and ECU_B.

4. The in-vehicle ECU communication method for intelligent vehicles according to claim 3, characterized in that: The bootstrapping connection includes a TLS connection.

5. A vehicle ECU communication method for intelligent vehicles according to claim 3, characterized in that: In step S104, the device certificate verification includes: verifying the certificate chain, validity period, and revocation status of the device certificate; the device certificate is considered to have passed verification only if the certificate chain verification is successful, the device certificate is within its validity period, and the certificate has not been revoked.

6. The in-vehicle ECU communication method for intelligent vehicles according to claim 3, characterized in that: In step S106, ECU_B performs VDAC authorization verification based on the locally stored VDAC fragment and the device serial number SN_A of ECU_A, including: ECU_B reads locally stored VDAC fragments to obtain the list of authorized peers; ECU_B checks whether SN_A exists in the list of authorized peers; if it does, ECU_B considers ECU_A to be trustworthy and considers the VDAC authorization verification to be successful.

7. A vehicle ECU communication method for intelligent vehicles according to any one of claims 2-6, characterized in that: For the two communicating parties, namely ECU_A and ECU_B, the workflow of the second stage includes: In step S201, ECU_A and ECU_B directly use the long-term communication root key negotiated in the first phase to derive the session key; Step S202: Based on the session key, both parties establish a business data channel through a lightweight security protocol.

8. A vehicle ECU communication method for intelligent vehicles according to claim 7, characterized in that: The lightweight security protocol includes PSK-based TLS or a custom symmetric encryption channel.

9. A vehicle ECU communication method for intelligent vehicles according to claim 1, characterized in that: The method also constructs a full lifecycle dynamic trust update mechanism, namely, a trust update interface is preset on the vehicle central gateway, wherein the vehicle central gateway is communicatively connected to each vehicle ECU and to the vehicle-cloud collaborative strategy center through the TBOX; external devices trigger the dynamic trust update mechanism through the trust update interface; specifically including: Step 1: The vehicle central gateway collects trust data from each ECU, builds a trust tree, and generates a dynamic trust update request; Step 2: The trust tree and trust dynamic update request are uploaded to the vehicle-cloud collaboration strategy center via TBOX; Step 3: After verifying the legitimacy of the request, the vehicle-cloud collaboration strategy center constructs a trust policy based on the trust tree information, generates a VDAC_List, and signs it; Step 4: The vehicle-cloud collaborative strategy center transmits the signed VDAC to the vehicle-side TBOX; Step 5: After TBOX verifies the signature, it passes VDAC_List to the vehicle central gateway; Step 6: The vehicle central gateway stores and distributes VDAC fragments to the relevant ECUs according to the VDAC_List; Step 7: Each relevant ECU stores the VDAC fragments distributed to it.

10. An in-vehicle ECU communication system for intelligent vehicles, using an in-vehicle ECU communication method for intelligent vehicles according to any one of claims 1-9, characterized in that: The system includes: a vehicle-cloud collaborative strategy center, an in-vehicle central gateway, a TBOX, ECUs, and external devices; wherein, the in-vehicle central gateway is communicatively connected to each vehicle ECU and is communicatively connected to the vehicle-cloud collaborative strategy center through the TBOX; the external devices are communicatively connected to the in-vehicle central gateway through a preset trust update interface, and the external devices include production line electrical inspection equipment and after-sales diagnostic equipment; the vehicle-cloud collaborative strategy center is constructed according to any one of claims 1-9 of the in-vehicle ECU communication method for intelligent vehicles; and the various ECUs communicate with each other according to any one of claims 1-9 of the in-vehicle ECU communication method for intelligent vehicles.

Images