Controller anti-tampering system

Abstract

The present application relates to the technical field of vehicles, in particular to a controller anti-replacement system. The controller anti-replacement system comprises a target vehicle, and the target vehicle comprises a controller. For each controller, the corresponding last controller hardware feature information and last controller signature information of the corresponding last controller in a preset arrangement sequence of the controller are periodically acquired. The last controller signature information is decoded to obtain the corresponding decoded controller hardware feature information of the last controller. Verification is performed based on the decoded controller hardware feature information and the last controller hardware feature information. The controller anti-replacement system can effectively identify scenarios such as overall controller replacement and hardware modification, overcome the defects of the prior art that cannot cope with full controller replacement, and eliminate problems such as using old controllers as new ones. The problem of how to prevent the controller in the vehicle from being replaced is solved.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of vehicles, in particular to a controller anti-replacement system. BACKGROUND

[0002] In recent years, the intelligent and networked vehicle industry has developed rapidly. Vehicle core controllers (such as power control ECUs and automatic driving domain controllers) are the core carriers of vehicle intelligent functions, and their stability and reliability directly determine the safety of vehicle driving and user experience. In order to protect product quality and improve brand competitiveness, vehicle manufacturers generally use high-reliability and high-safety controller and chip solutions, but the cost of such high-end hardware is significantly higher than that of ordinary components.

[0003] Current irregular replacement behaviors mainly manifest in two categories: one is to replace high-cost core components of vehicles with low-cost and low-performance controllers or chips to make a profit; the other is that maintenance service agencies use second-hand controllers or old parts with degraded performance from old vehicles for maintenance and replacement of new vehicles or normal vehicles to make a profit. Such behaviors not only lead to reduced vehicle performance and increased risk of failure, seriously affecting user experience and brand reputation, but also directly threaten the health and safety of vehicle owners due to potential safety hazards (such as signal delay and control failure) in components, becoming an important risk point in the field of automotive safety.

[0004] Therefore, how to prevent the controller in the vehicle from being replaced has become a problem to be solved. SUMMARY

[0005] Therefore, the present application provides a controller anti-replacement system to solve the problem of how to prevent the controller in the vehicle from being replaced.

[0006] In a first aspect, the present application provides a controller anti-replacement system, which includes a target vehicle, and the target vehicle includes a controller, wherein:

[0007] For each controller, the first controller hardware feature information and the first controller signature information corresponding to the previous controller in the preset arrangement order of the controller are periodically acquired; the first controller signature information is decoded to obtain the decoded controller hardware feature information corresponding to the previous controller; and the decoded controller hardware feature information is verified based on the first controller hardware feature information.

[0008] The controller anti-replacement system provided by the embodiments of the present application can effectively identify the overall controller replacement, hardware change and other scenarios, make up for the defects that the prior art cannot cope with controller replacement, and prevent problems such as using old parts to replace new ones. In addition, a closed-loop verification chain is formed according to the preset arrangement order, and each controller is verified by the next controller, thereby avoiding the problem that self-verification is easily bypassed, covering all key controllers without a dead angle of protection. The verification process is completed locally on the vehicle, without the need to rely on the cloud, and can still be normally executed when the network is interrupted, and does not affect the daily functions of the controller, and is suitable for the actual use scenario of the vehicle. The verification logic is associated with the vehicle-controller binding relationship, preventing the abuse of regular parts across vehicles, while providing a credible verification basis for subsequent regular part replacement, balancing safety and maintenance needs.

[0009] In an optional implementation, the controller includes a master controller and a slave controller, and for each controller, before periodically acquiring the last controller hardware feature information and the last controller signature information corresponding to the last controller in the preset arrangement order corresponding to the controller, the master controller is configured to initialize the master controller to generate master controller signature information corresponding to the master controller.

[0010] The master controller is further configured to initialize the slave controller to generate slave controller signature information corresponding to the slave controller.

[0011] The master controller signature information generated by the initialization of the master controller of the controller anti-replacement system provided by the embodiments of the present application is the core credential for the server and the part replacement authentication device to verify the regularity of the master controller, and the slave controller signature information generated by the initialization of the slave controller provides a credible basis for the periodic chain verification, avoiding the problem of verification failure caused by no credential. The master controller signature information and the slave controller signature information generated by the initialization are the key basis for the periodic verification of the last controller by each controller. Without the credible signature generated by the initialization link, the closed-loop verification chain cannot be established, and the whole controller cannot be protected without a dead angle.

[0012] In an optional implementation, the controller anti-replacement system further includes a server, wherein:

[0013] The main controller is used for generating a main controller public-private key pair corresponding to the main controller, securely storing a main controller private key, reading main controller hardware information, generating main controller hardware feature information corresponding to the main controller hardware information based on a preset encryption algorithm, and storing the main controller hardware feature information; generating a main controller certificate signature request based on the main controller public key, vehicle identification information corresponding to a target vehicle, and the main controller hardware information; and sending the main controller certificate signature request to a server;

[0014] The server is used for verifying the vehicle identification information corresponding to the main controller and the main controller hardware information, and after successful verification, encrypting the main controller hardware information based on a server private key, generating main controller signature information, and sending the main controller signature information to the main controller.

[0015] The main controller is used for receiving the main controller signature information sent by the server and saving the main controller signature information.

[0016] The controller anti-replacement system provided by the embodiments of the present application is used for the main controller to generate a unique main controller public-private key pair and securely store a main controller private key. The private key is prevented from being leaked or irregularly changed, a secure key basis is provided for subsequent digital signature and identity authentication, and identity forgery caused by private key risks is avoided. The main controller hardware information is read, main controller hardware feature information corresponding to the main controller hardware information is generated based on a preset encryption algorithm, and the main controller hardware feature information is stored, so that the main controller hardware identity is ensured to be unique and unchangeable, a trusted benchmark is provided for subsequent verification of hardware regularity, and regular identity forgery through changing hardware information is eliminated. Then, the main controller certificate signature request is generated based on the main controller public key, vehicle identification information corresponding to a target vehicle, and the main controller hardware information. The information association of “controller-vehicle” is realized, complete data is provided for the server to establish an exclusive binding relationship, and subsequent irregular use of the main controller by a cross-vehicle is avoided. The main controller sends the certificate signature request to the server, ensures that the request information is not changed in transmission, guarantees that the information received by the server is real and effective, and provides a premise for the regularity of subsequent signature generation. Next, the vehicle identification information corresponding to the main controller and the main controller hardware information are verified. The vehicle identification regularity and the main controller hardware compliance are checked, authentication requests of irregular vehicles and counterfeit hardware are excluded, regular main controllers are filtered from the source, and irregular devices are prevented from being mixed into the system. The main controller signature information is generated by encrypting with a server private key, the main controller is given a regular identity certificate, and the main controller signature information is fed back in a secure manner, so that the main controller signature information cannot be forged, and an authoritative basis is provided for subsequent main controller identity verification (such as part replacement). The main controller stores the signature information in an unchangeable medium, ensures that the main controller signature information is not irregularly modified or deleted, and enables the main controller to provide regular identity proof at any time in subsequent verification and part replacement scenarios, thereby supporting the operation of the overall anti-replacement system.

[0017] In an optional implementation, the number of slave controllers is at least one; wherein:

[0018] The slave controller is configured to read slave controller hardware information, generate slave hardware feature information corresponding to the slave controller hardware information based on a preset encryption algorithm, store the slave hardware feature information, and transmit the slave hardware feature information to the master controller.

[0019] The master controller is configured to receive the slave hardware feature information sent by the slave controller, verify the slave hardware feature information corresponding to the slave controller, encrypt the slave hardware feature information based on a master controller private key to obtain slave controller signature information corresponding to the slave controller after the slave hardware feature information is verified successfully, return the slave controller signature information and a master controller public key to the slave controller, and return the slave controller signature information and the master controller public key to a next slave controller corresponding to the slave controller in a preset arrangement order.

[0020] The controller anti-replacement system provided by the embodiments of the present application reads slave controller hardware information from the slave controller, generates slave hardware feature information corresponding to the slave controller hardware information based on a preset encryption algorithm, ensures that the slave controller hardware identity is unique and unchangeable, provides a trusted hardware reference for subsequent normality verification, and avoids identity forgery caused by changed hardware information. The slave hardware feature information is stored and transmitted to the master controller. The slave hardware feature information is ensured not to be intercepted or changed during transmission, and the slave hardware feature information received by the master controller is ensured to be real and effective, thereby laying a reliable data foundation for subsequent verification and signature generation. The master controller receives the slave hardware feature information sent by the slave controller, and verifies the slave hardware feature information corresponding to the slave controller. The master controller verifies the normality of the slave hardware feature information (such as matching the hardware specifications of the vehicle model and excluding repeated binding), filters out normal slave controllers, prevents non-normal and model-mismatched slave controllers from accessing the system, and ensures the security of the slave controller level from the source. After the slave hardware feature information is verified successfully, the master controller encrypts the slave hardware feature information based on the master controller private key to obtain slave controller signature information corresponding to the slave controller. The slave controller is given a normal identity credential, the slave controller signature information cannot be forged (needs to be generated by the master controller private key), the slave controller identity is ensured to be traceable and verifiable, and non-normal slave controllers are prevented from forging normal identities. The slave controller signature information and the master controller public key are returned to the slave controller. The slave controller can provide a normal identity certificate when it is verified subsequently, and the master controller public key provides a tool for the verification party to decode the signature information, thereby ensuring that the slave controller can be effectively verified in the chain verification. The slave controller signature information and the master controller public key are returned to the next slave controller corresponding to the slave controller in the preset arrangement order. The next slave controller provides a core basis for periodically verifying the normality of the current slave controller (the next slave controller needs to decode the current slave controller signature information using the master controller public key), supports the establishment of a “chain closed loop verification” system, and avoids the situation that a single slave controller cannot be identified after being replaced.

[0021] In an optional embodiment, the controller includes a master controller and a slave controller, and each controller has a master controller public key corresponding to the master controller; and each controller is configured to decode signature information of a previous controller based on the master controller public key to obtain decoded controller hardware feature information corresponding to the previous controller.

[0022] The controller anti-replacement system provided by the embodiment of the application has a main controller public key corresponding to a main controller in each controller. A unified and trusted decryption tool is provided for decoding the signature information of the previous controller, so that decoding failure caused by the lack of the corresponding public key is avoided, the universality and continuity of the chain verification are ensured, and the closed-loop verification system is supported to operate. Each controller decodes the signature information of the previous controller based on the main controller public key to obtain the decoding controller hardware feature information corresponding to the previous controller. Only the regular signature issued by the main controller private key can be successfully decoded, so that the signature verification security is improved, and the verification of whether the previous controller is replaced is provided with a core reference, so that the hardware regularity cannot be judged due to the lack of reference information, and the verification logic can be implemented.

[0023] In an optional embodiment, the controller is configured to determine that the previous controller is regular if the decoding controller hardware feature information is consistent with the previous controller hardware feature information, and determine that the previous controller is irregular if the decoding controller hardware feature information is inconsistent with the previous controller hardware feature information.

[0024] The controller anti-replacement system provided by the embodiment of the application determines that the previous controller is regular if the decoding controller hardware feature information is consistent with the previous controller hardware feature information. The previous controller hardware is accurately confirmed to be not replaced and the hardware information is not changed, so that the regular identity is ensured, a trusted result is provided for the chain verification, and the normal operation safety of the vehicle controller level is ensured. The previous controller is determined to be irregular if the decoding controller hardware feature information is inconsistent with the previous controller hardware feature information. Therefore, the irregular replacement behavior can be found in time, the risk of failure caused by the long-term hiding of the irregular controller in the system is avoided, and a judgment basis is provided for the subsequent reporting of irregular information and the blocking of risks. The above method not only simplifies the verification process and reduces the consumption of controller computing resources, but also eliminates the possibility of bypassing the verification by an attacker by imitating the hardware information, and balances the verification efficiency and security.

[0025] In an optional embodiment, the server is configured to periodically send, to the main controller, an acquisition current main control device information request corresponding to the vehicle identification information.

[0026] The main controller is configured to read the current main controller hardware information, generate current main hardware feature information corresponding to the current main controller hardware information based on a preset encryption algorithm, and encrypt the current main hardware feature information based on a main controller private key to generate a main controller self-signature information.

[0027] The server is configured to receive the main controller signature information corresponding to the main controller and the main controller self-signature information, decrypt the main controller signature information based on a server public key corresponding to a server private key to obtain first decrypted main controller hardware information corresponding to the main controller, and send the first decrypted main controller hardware information to the main controller.

[0028] comparing the first decrypted main controller hardware information with the main controller hardware information stored in the server;

[0029] if the first decrypted main controller hardware information is consistent with the main controller hardware information stored in the server, the verification is successful;

[0030] if the verification is successful, the main controller self-signed information is decrypted based on the main controller public key to obtain current main hardware feature information;

[0031] comparing the current main hardware feature information with the main controller hardware information stored in the server;

[0032] if the current main hardware feature information is consistent with the main controller hardware information stored in the server, it is determined that the main controller is regular.

[0033] The controller anti-replacement system provided by the embodiments of the present application can periodically send a current master control device information acquisition request corresponding to vehicle identification information to the master controller. The master controller state can be monitored in real time, the master controller can be prevented from being replaced irregularly and then not found for a long time, the continuous safety of the vehicle core control node can be ensured, and the limitation of single verification can be compensated. The master controller reads current master controller hardware information, and generates current master hardware feature information corresponding to the current master controller hardware information based on a preset encryption algorithm. The latest hardware state of the master controller is ensured, real and real-time hardware identity basis is provided for subsequent comparison, and misjudgment caused by using outdated information is avoided. The current master hardware feature information is encrypted based on a master controller private key to generate master controller self-signature information. The current hardware information is ensured not to be changed during transmission, encryption security is provided for the server to verify the authenticity of the current hardware, and the current hardware information is prevented from being imitated by an attacker. The server receives the master controller signature information and the master controller self-signature information corresponding to the master controller, provides complete data for double verification, avoids the vulnerability of single information verification, and improves the comprehensiveness of verification. The master controller signature information is decrypted based on a server public key corresponding to a server private key to obtain first decrypted master controller hardware information corresponding to the master controller. The first decrypted master controller hardware information is compared with the master controller hardware information stored in the server. The master controller signature information is verified not to be changed, and the initial identity of the master controller is verified to be regular, so that the master controller with an irregular signature is filtered from the source. If the first decrypted master controller hardware information is consistent with the master controller hardware information stored in the server, the verification is successful. The master controller signature information is excluded from being imitated, a credible basis is laid for subsequent verification of the current hardware state, and subsequent operations based on the irregular signature are avoided. If the verification is successful, the master controller self-signature information is decrypted based on a master controller public key to obtain current master hardware feature information; the current hardware information is ensured to come from a regular master controller, and the master controller self-signature information is prevented from being imitated by an attacker to impersonate a regular master controller. The current master hardware feature information is compared with the master controller hardware information stored in the server. If the current master hardware feature information is consistent with the master controller hardware information stored in the server, the master controller is determined to be regular. Whether the master controller is replaced or the hardware is changed can be accurately judged, the regularity of the master controller is finally determined, double protection of "signature regularity + hardware authenticity" is formed, and the risk of irregular replacement of the master controller is completely eliminated.

[0034] In an optional implementation, the controller anti-replacement system further includes a replacement authentication device, wherein:

[0035] The master controller is further configured to send the master controller signature information to the replacement authentication device after receiving the replacement instruction for the slave controller.

[0036] The replacement authentication device is configured to verify the main controller signature information based on the replacement authentication device signature information corresponding to the replacement authentication device, and send verification success information to the main controller after verification is successful.

[0037] The main controller is configured to initialize the replaced update slave controller after receiving the verification success information sent by the replacement authentication device, and generate update slave controller signature information corresponding to the update slave controller.

[0038] The controller anti-replacement system provided by the embodiment of the application is characterized in that: after the main controller receives the replacement instruction for the slave controller, the main controller sends main controller signature information to the replacement authentication device. The main controller signature information provides a basis for the replacement authentication device to verify the identity of the main controller, avoids the replacement operation initiated by an irregular main controller, and controls the normality of the replacement behavior from the source. The replacement authentication device verifies the main controller signature information based on the replacement authentication device signature information corresponding to the replacement authentication device, and sends verification success information to the main controller after verification is successful. Only a regular main controller and a regular replacement authentication device can start the replacement, attacks by attackers through the imitation of the replacement instruction or the malicious replacement of irregular devices are eliminated, and the safety of the replacement scene is ensured. After the main controller receives the verification success information sent by the replacement authentication device, the main controller initializes the replaced update slave controller, and generates update slave controller signature information corresponding to the update slave controller. Only a regular main controller and a regular replacement authentication device can start the replacement, attacks by attackers through the imitation of the replacement instruction or the malicious replacement of irregular devices are eliminated, and the safety of the replacement scene is ensured.

[0039] In an optional embodiment, the replacement authentication device is configured to generate a replacement authentication device public-private key pair in a secure environment, and store the replacement authentication device private key.

[0040] Based on the replacement authentication device public key and the device hardware information corresponding to the replacement authentication device, a certificate signature request is generated.

[0041] The certificate signature request is sent to a server.

[0042] The server is configured to encrypt the device hardware information based on a server private key, generate replacement authentication device signature information, and send the replacement authentication device signature information to the replacement authentication device.

[0043] The replacement authentication device is configured to receive the replacement authentication device signature information sent by the server.

[0044] The controller anti-replacement system provided by the embodiments of the present application, the replacement authentication device generates a replacement authentication device public-private key pair in a secure environment, and stores the replacement authentication device private key. The key is prevented from being leaked or stolen, a secure key basis is provided for subsequent identity authentication of the replacement authentication device, and device identity forgery caused by key risks is avoided. Based on the replacement authentication device public key and the device hardware information corresponding to the replacement authentication device, a certificate signing request is generated. It is ensured that the certificate signing request contains a unique device identity, provides complete data for the server to identify and verify the normality of the replacement authentication device, and avoids non-normal devices impersonating normal replacement tools. The certificate signing request is sent to the server. It is ensured that the certificate signing request is not intercepted or changed during transmission, and it is ensured that the device information received by the server is real and effective, and provides a prerequisite for the normality of subsequent signature generation. The server encrypts the device hardware information based on the server private key to generate replacement authentication device signature information; and sends the replacement authentication device signature information to the replacement authentication device. The replacement authentication device is given a normal identity certificate, the replacement authentication device signature information cannot be impersonated, and an authoritative basis is provided for device identity verification during replacement, so that non-normal replacement authentication devices are prevented from participating in the replacement process. The replacement authentication device is used to receive the replacement authentication device signature information sent by the server. It can provide a normal identity certificate when it is subsequently verified with the main controller, ensures that the replacement authentication device can only be used in an authorized scenario, and supports the start verification of the normal replacement process.

[0045] In an optional implementation, the replacement authentication device is configured to verify the main controller signature information and the replacement authentication device signature information through a certificate verification manner. If it is determined that the main controller signature information and the replacement authentication device signature information are both encrypted based on the server private key corresponding to the server, the verification is successful.

[0046] The controller anti-replacement system provided by the embodiments of the present application, the replacement authentication device is configured to verify the main controller signature information and the replacement authentication device signature information through a certificate verification manner. It can be proved that the main controller is a normal device authorized by the server, and the non-normal main controller is excluded from initiating the replacement request, so that the normality of the replacement initiator is controlled from the source. If it is determined that the main controller signature information and the replacement authentication device signature information are both encrypted based on the server private key corresponding to the server, the verification is successful. A “two-way normal verification” mechanism is formed, and the non-normal replacement risk caused by single-party impersonation of the signature is completely eliminated, and a safe pre-protection is provided for the subsequent normal replacement process.

[0047] In a second aspect, the present application provides a controller anti-replacement method applied to the controller of the controller anti-replacement system in the first aspect and any of the corresponding embodiments. The method comprises the following steps.

[0048] periodically acquire the last controller hardware feature information corresponding to a last controller in a preset arrangement sequence of the controller and last controller signature information corresponding to the last controller;

[0049] decode the last controller signature information to obtain decoded controller hardware feature information corresponding to the last controller;

[0050] verify the decoded controller hardware feature information and the last controller hardware feature information.

[0051] The controller anti-replacement method provided by the embodiments of the present application periodically acquires last controller hardware feature information corresponding to a last controller in a preset arrangement sequence of the controller and last controller signature information corresponding to the last controller, decodes the last controller signature information to obtain decoded controller hardware feature information corresponding to the last controller, and verifies the decoded controller hardware feature information and the last controller hardware feature information. The method can effectively identify scenarios such as overall controller replacement and hardware change, make up for the defects that the prior art cannot cope with full controller replacement, and eliminate problems such as using old parts to replace new ones. In addition, a closed-loop verification chain is formed according to the preset arrangement sequence, each controller is verified by a next controller, the problem that self-verification is easily bypassed is avoided, all key controllers are covered, and there is no protection dead angle. The verification process is completed locally on the vehicle, does not need to rely on the cloud, can still be normally executed when the network is interrupted, and does not affect the daily functions of the controller, and is suitable for actual use scenarios of the vehicle. The verification logic is associated with the vehicle-controller binding relationship, prevents regular parts from being misused across vehicles, provides a credible verification basis for subsequent regular part replacement, and balances safety and maintenance needs.

[0052] In an optional implementation, the controller includes a master controller and a slave controller, and the method is applied to the master controller. Before the step of periodically acquiring the last controller hardware feature information corresponding to a last controller in a preset arrangement sequence of the controller and last controller signature information corresponding to the last controller, the method further includes: initializing the master controller to generate master controller signature information corresponding to the master controller; and initializing the slave controller to generate slave controller signature information corresponding to the slave controller.

[0053] In a third aspect, the present application provides a target vehicle, which includes a vehicle body and the controller anti-replacement system of the first aspect and any of the corresponding implementation forms. BRIEF DESCRIPTION OF DRAWINGS

[0054] In order to more clearly illustrate the technical solutions in the specific embodiments of the present application or the prior art, the accompanying drawings needed to be used in the description of the specific embodiments or the prior art will be briefly introduced. Obviously, the accompanying drawings in the following description are some embodiments of the present application, and other drawings can be obtained by those skilled in the art without creative effort on the basis of these drawings.

[0055] Figure 1 is a structural schematic diagram of a controller anti-replacement system according to an embodiment of the present application;

[0056] Figure 2 is a structural schematic diagram of another controller anti-replacement system according to an embodiment of the present application;

[0057] Figure 3 is a flowchart of a first controller anti-replacement method according to an embodiment of the present application;

[0058] Figure 4 is a flowchart of a second controller anti-replacement method according to an embodiment of the present application;

[0059] Figure 5 is a flowchart of a third controller anti-replacement method according to an embodiment of the present application;

[0060] Figure 6 is a flowchart of a fourth controller anti-replacement method according to an embodiment of the present application;

[0061] Figure 7 is a flowchart of a fifth controller anti-replacement method according to an embodiment of the present application. DETAILED DESCRIPTION

[0062] In order to make the objects, technical solutions and advantages of the embodiments of the present application clearer, the technical solutions in the embodiments of the present application will be described clearly and completely below with reference to the accompanying drawings of the embodiments of the present application. Obviously, the described embodiments are some of the embodiments of the present application, rather than all the embodiments. Based on the embodiments in the present application, all other embodiments obtained by those skilled in the art without creative effort belong to the scope of protection of the present application.

[0063] The embodiments of the present application provide a controller anti-replacement system, as shown in Figure 1 The controller anti-replacement system includes a target vehicle, and the target vehicle includes a controller, wherein:

[0064] For each controller, the controller can periodically obtain the last controller hardware feature information and the last controller signature information corresponding to the last controller in the preset arrangement sequence corresponding to the controller.

[0065] Specifically, the controller anti-replacement system sets a chain verification relationship for all controllers of the target vehicle, i.e., controller 1→controller 2→…→controller N→master controller, forming a closed loop. Wherein:

[0066] For any controller X, the last controller thereof is the controller directly in front of it in the sequence (e.g., the last controller of controller 3 is controller 2). Wherein, all controllers in the target vehicle include a master controller and at least one slave controller. The last controller of the master controller is slave controller N, and the last controller of controller 1 is the master controller, finally realizing a verification closed loop and avoiding the loophole of self-verification.

[0067] For each controller, the controller can periodically obtain the last controller hardware feature information and the last controller signature information corresponding to the last controller in the preset arrangement sequence corresponding to the controller. Then, the last controller signature information is decoded to obtain the decoded controller hardware feature information corresponding to the last controller.

[0068] Then, the controller verifies the decoded controller hardware feature information obtained by decoding and the received last controller hardware feature information, so that the replacement of each controller can be prevented according to the verification result.

[0069] For example, the verification unit of controller N-1 automatically triggers the verification task according to the system preset period (e.g., every 10 minutes, every time the power is turned on). According to the preset arrangement sequence, controller N-1 determines that the last controller to be verified is controller N-2, and the verification target is to confirm that controller N-2 has not been replaced irregularly. The verification unit of controller N-1 sends an information acquisition request to controller N-2 through the internal secure communication bus of the vehicle (e.g., encrypted CAN / LIN bus, to avoid interception and modification of information), and specifically acquires two types of information, last controller hardware feature information and last controller signature information.

[0070] Specifically, the hardware identity extraction unit of the controller N-2 reads the hardware feature information generated in real time by itself from the non-changeable medium and feeds back to the controller N-1 through the authorized unit. The verification unit of the controller N-2 reads the controller signature information (denoted as Sign1) of itself from the secure storage area (such as an encrypted FLASH). The Sign1 is a digital signature of the hardware feature information of the controller N-2 by the master controller at the initialization of the controller N-2, and is fed back to the controller N-1.

[0071] The verification unit of the controller N-1 calls a preset decryption algorithm (matching the signature algorithm, such as RSA2048 or SM2) to perform decoding (signature verification) on the obtained Sign1 to obtain the decoded controller hardware feature information corresponding to the previous controller.

[0072] The controller anti-replacement system provided by the embodiments of the present application can periodically obtain the previous controller hardware feature information and the previous controller signature information of the previous controller corresponding to the preset arrangement order of the controller; perform decoding operation on the previous controller signature information to obtain the decoded controller hardware feature information corresponding to the previous controller; and verify based on the decoded controller hardware feature information and the previous controller hardware feature information. The whole controller replacement, hardware change and other scenarios can be effectively identified, the defects that the prior art cannot cope with the whole controller replacement are made up, and problems such as using old to replace good are eliminated. In addition, a closed-loop verification chain is formed according to the preset arrangement order, each controller is verified by the next controller, the problem that self-verification is easily bypassed is avoided, all key controllers are covered, and there is no protection dead angle. The verification process is completed locally on the vehicle, does not need to rely on the cloud, and can still be normally executed when the network is interrupted, and does not affect the daily functions of the controller, and is suitable for the actual use scenario of the vehicle. The verification logic is associated with the vehicle-controller binding relationship, prevents regular components from being misused across vehicles, provides a trusted verification basis for subsequent regular replacement, and balances safety and maintenance needs.

[0073] In an optional embodiment of the present application, the controller includes a master controller and a slave controller. For each controller, before periodically obtaining the previous controller hardware feature information and the previous controller signature information of the previous controller corresponding to the preset arrangement order of the controller, the master controller is used to initialize the master controller to generate master controller signature information corresponding to the master controller.

[0074] The master controller is also used to initialize the slave controller to generate slave controller signature information corresponding to the slave controller.

[0075] Specifically, for each controller, before obtaining the last controller hardware feature information and the last controller signature information corresponding to the last controller in the preset arrangement sequence corresponding to the controller, the master controller can initialize the master controller to generate the master controller signature information corresponding to the master controller. The master controller can also initialize the slave controller to generate the slave controller signature information corresponding to the slave controller, so as to obtain the controller signature information corresponding to each controller, so that each controller can obtain the controller signature information corresponding to the last controller when verifying the last controller.

[0076] The controller anti-replacement system provided by the embodiments of the present application, the master controller signature information generated by the initialization of the master controller, is the core credential for the subsequent server and the replacement authentication device to verify the normality thereof, and the slave controller signature information generated by the initialization of the slave controller provides a credible basis for periodic chain verification, avoiding the verification failure problem caused by the lack of credentials. The master controller signature information and the slave controller signature information generated by the initialization are the key basis for each controller to periodically verify the last controller. Without the credible signature generated by the initialization link, the closed-loop verification chain cannot be established, and the full-controller dead-angle protection cannot be achieved.

[0077] In an optional embodiment of the present application, as shown in Figure 2 The controller anti-replacement system further includes a server. As shown in Figure 3 The initialization of the master controller to generate the master controller signature information corresponding to the master controller can include the following processes:

[0078] In step S101, the master controller generates a master controller public-private key pair corresponding to the master controller, and securely stores the master controller private key.

[0079] As shown in Figure 2 The master controller includes an identity authentication unit, an authentication unit, an authorization unit, an authorized unit, a verification unit, a hardware identity extraction unit, and a reporting unit. The identity authentication unit is used to obtain the normal identity of the master controller from the device authentication center during the initialization process of the master controller. The authentication unit is used to perform identity authentication with the replacement authentication device during the replacement process to confirm the normal identity of the replacement authentication device. The authorization unit is used to authorize the normal identity of other controllers. The authorized unit provides the controller hardware feature information for the identity verification of the authorization unit. The hardware identity extraction unit is used to extract the hardware information of the controller to generate the hardware feature information. When the verification unit verifies that the hardware identity extraction unit information of the verified controller is a non-normal controller, the non-normal controller information is reported to the cloud through the reporting unit.

[0080] Specifically, the identity authentication unit in the master controller generates a unique master controller public-private key pair based on a preset asymmetric encryption algorithm (such as SM2, RSA2048). The master controller stores the generated master controller private key in a tamper-proof trusted medium, such as an EFUSE (one-time programmable fuse) or an encrypted FLASH built into a chip, to prevent the private key from being intercepted and counterfeited after signing.

[0081] In step S102, the master controller reads the master controller hardware information, generates master hardware feature information corresponding to the master controller hardware information based on a preset encryption algorithm, and stores the master hardware feature information.

[0082] Specifically, the hardware identity extraction unit in the master controller reads its own core hardware information, i.e., the master controller hardware information, including but not limited to: chip serial number (unique identification of factory information of the chip), EFUSE fuse configuration information (chip hardware configuration parameters), and controller hardware version number (differentiation of hardware identification of different batches / models).

[0083] The master controller performs hash calculation on the read master controller hardware information through a preset encryption algorithm, i.e., a preset secure hash algorithm (such as SM3, SHA-256), to generate unique master hardware feature information, which can be a hash value. The irreversibility of the hash algorithm ensures that if the hardware information is changed, the generated hash value will be completely different, and whether the hardware is replaced can be quickly identified.

[0084] The master controller stores the generated master hardware feature information (hash value) in a secure medium (consistent with the private key storage medium, such as EFUSE), providing a trusted original hardware identification for subsequent verification.

[0085] In step S103, the master controller generates a master controller certificate signature request based on the master controller public key, vehicle identification information corresponding to the target vehicle, and master controller hardware information.

[0086] The vehicle identification information (VIN code) is preloaded into the master controller by the vehicle production line through a secure communication method (such as offline writing or encrypted bus transmission), ensuring that the VIN code is the true and unique identification of the target vehicle.

[0087] Specifically, the master controller follows the certificate signature request format (compatible with the X.509 certificate request format), encapsulates the master controller public key + vehicle VIN code + original hardware information into a structured master controller certificate signature request, and ensures information integrity (no missing fields) and format standardization (compliance with server parsing requirements).

[0088] In step S104, the master controller sends the master controller certificate signature request to the server.

[0089] Optionally, the main controller connects to the server (device authentication center) via an in-vehicle secure communication module (such as an in-vehicle T-BOX) and transmits certificate signing requests using an encrypted communication protocol (such as TLS 1.3) to prevent the requests from being intercepted, altered, or forged. The requests are then sent to the server (device authentication center), where the server's certificate processing module receives and prepares for subsequent verification.

[0090] Optionally, in a controllable and secure environment such as a vehicle production line, the certificate signature request in the main controller can be read via a dedicated offline device (such as an encrypted USB flash drive or a dedicated production line terminal), and then imported into the server to avoid network transmission risks. This request is then sent to the server (device authentication center), where the server's certificate processing module receives it and prepares it for subsequent verification.

[0091] In step S105, the server verifies the vehicle identification information and main controller hardware information corresponding to the main controller.

[0092] Among them, such as Figure 2 As shown, the server consists of a server public key, a server private key, a whitelist of master control devices, and a whitelist of replacement devices. It is used to issue legitimate authentication certificates for the entire vehicle model and the vehicle's master controller and replacement device authentication equipment. These certificates can be X.509 certificates or other digital certificates of equivalent security strength. It is also used to verify the identity information of the master controller and replacement device authentication equipment, and to receive alarm information from illegitimate devices fed back by the master controller. The server private key is stored in a trusted environment such as a cryptographic machine and cannot be exported. The server private key is used to provide legitimate signatures for the vehicle's master controller and replacement device authentication equipment, confirming their legitimate identities. The master control device whitelist stores the binding relationship between the vehicle and the master control device, used to verify and rebind the vehicle and device relationship during replacement. The replacement device whitelist stores legitimate replacement device authentication information, used to verify the legitimate identity of the replacement device authentication equipment.

[0093] Specifically, the server queries its own stored vehicle identification information database to confirm that the vehicle corresponding to the vehicle identification information is a registered and legitimate model (not a counterfeit VIN code), and that the vehicle is in the initialization state of waiting to be bound to the main controller (to avoid duplicate binding).

[0094] The server verifies the original hardware information in the main controller certificate signing request, including: confirming that the main controller hardware information (such as the chip serial number) conforms to the hardware specifications of the main controller for this vehicle model (such as the chip model and batch range). The server queries its built-in database of legitimate hardware information (such as the range of legitimate serial numbers provided by the chip manufacturer) to confirm that the main controller corresponding to the hardware information is an original genuine product purchased by the car manufacturer, and not a refurbished or counterfeit device. However, the main controller whitelist must be established based on legitimate hardware information; this is the implicit logic of the verification.

[0095] If any information verification fails (such as vehicle identification forgery, main controller hardware information is not regular), the server directly rejects the subsequent signature process, and records the irregular main controller request. If both types of information are verified, step S106 is entered.

[0096] In step S106, the server encrypts the main controller hardware information based on the server private key after verification is successful, generates main controller signature information, and sends the main controller signature information to the main controller.

[0097] Specifically, the server calls the root private key in the cryptographic machine, i.e., the server private key, based on the verified main controller hardware information, uses a preset asymmetric encryption algorithm (such as SM2, RSA2048), digitally signs the main controller hardware information (or hash value), and generates main controller signature information (wherein the main controller signature information is essentially an X.509 certificate or a digital certificate of the same security level, containing the main controller public key, the VIN code, the hardware feature information, and the server private key).

[0098] Then, the server writes the binding relationship of the vehicle identification information, the main controller hardware information, and the main controller signature information into the main control device whitelist for subsequent replacement binding, forming a unique binding record of the vehicle-main controller.

[0099] Then, the server returns the main controller signature information to the main controller through an encrypted communication protocol. Alternatively, the server imports the main controller signature information into a special offline device and then writes it into the main controller.

[0100] In step S107, the main controller receives the main controller signature information sent by the server and saves the main controller signature information.

[0101] Specifically, the main controller receives the main controller signature information sent by the server, and after receiving, first verifies the signature information format (such as whether the certificate is complete and whether there are obvious alteration traces) through a verification unit to ensure that the received information is valid.

[0102] Then, the main controller stores the main controller signature information that has passed verification in a non-changeable secure medium (such as EFUSE, encrypted FLASH), which is consistent with the storage location of the server private key and the main hardware feature information corresponding to the main controller, forming a trusted storage combination of private key-hardware feature-signature information. The main controller signature information is the regular identity certificate of the main controller - in subsequent replacement, the main controller needs to present the signature information to the replacement authentication device to prove its regularity; at the same time, the server also needs to verify the main controller through the signature information when it is periodically verified.

[0103] The controller anti-replacement system provided by the embodiments of the present application includes the following steps: a master controller generates a unique master controller public-private key pair and securely stores the master controller private key. The master controller private key is prevented from being leaked or irregularly changed, a secure key base is provided for subsequent digital signature and identity authentication, and identity forgery caused by private key risks is avoided. The master controller hardware information is read, master hardware feature information corresponding to the master controller hardware information is generated based on a preset encryption algorithm, and the master hardware feature information is stored, so that the master controller hardware identity is ensured to be unique and unchangeable, a trusted benchmark is provided for subsequent verification of hardware regularity, and the regular identity is prevented from being forged by changing the hardware information. Then, a master controller certificate signature request is generated based on the master controller public key, vehicle identification information corresponding to a target vehicle, and the master controller hardware information. The information association between the controller and the vehicle is realized, complete data is provided for the server to establish an exclusive binding relationship, and the subsequent irregular use of the master controller by a cross-vehicle is avoided. The master controller sends the certificate signature request to the server, ensures that the request information is not changed during transmission, guarantees that the information received by the server is real and effective, and provides a prerequisite for the regularity of subsequent signature generation. Next, the vehicle identification information corresponding to the master controller and the master controller hardware information are verified. The vehicle identification regularity and the master controller hardware compliance are checked, the authentication request of an irregular vehicle or a fake hardware is excluded, a regular master controller is filtered from the source, and irregular devices are prevented from being mixed into the system. The master controller signature information is generated by encrypting the server private key, the master controller is given a regular identity certificate, and the master controller signature information is fed back in a secure manner, so that the master controller signature information cannot be forged, and an authoritative basis is provided for subsequent master controller identity verification (such as part replacement). The master controller stores the signature information in an unchangeable medium, ensures that the master controller signature information is not irregularly modified or deleted, and enables the master controller to provide regular identity proof at any time in subsequent verification and part replacement scenarios, thereby supporting the operation of the overall anti-replacement system.

[0104] In an optional embodiment of the present application, the number of slave controllers is at least one; as shown in the figure, the slave controller is initialized, and the generation of the slave controller signature information corresponding to the slave controller can include the following processes: Figure 4

[0105] In step S201, the slave controller reads the slave controller hardware information, generates slave hardware feature information corresponding to the slave controller hardware information based on a preset encryption algorithm, stores the slave hardware feature information, and transmits the slave hardware feature information to the master controller.

[0106] ​The from controller includes an authorized unit, a hardware identity extraction unit, a verification unit and a reporting unit. The authorized unit of the from controller provides the controller hardware feature information for the authorization unit of the main controller to verify the identity of other controllers. The hardware identity extraction unit is used to extract the hardware information of other controllers to generate hardware feature information. When the verification unit verifies that the hardware identity extraction unit information of the controller to be verified is not a regular controller, the reporting unit reports the irregular controller information to the main controller, which is reported to the cloud by the main controller.

[0107] Specifically, the hardware identity extraction unit of the from controller reads the from controller hardware information, including the chip serial number (unique factory identification), EFUSE fuse configuration (hardware fixed parameter), hardware version number (batch / model distinction) and the like, which is consistent with the hardware information type of the main controller. Then, the from controller performs hash calculation on the read from controller hardware information through a preset secure hash algorithm (such as SM3) to generate unique from hardware feature information (such as hash value), which has the characteristics of hardware uniqueness, irreversibility and unchangeability. If the from controller is replaced, the hash value generated by the new hardware will be completely different, and the irregular replacement can be quickly identified.

[0108] The from controller stores the generated from hardware feature information in a non-changeable secure medium (such as EFUSE, encrypted FLASH) to avoid being bypassed by counterfeit hardware information.

[0109] The authorized unit of the from controller sends the from hardware feature information (hash value) to the main controller through the vehicle internal secure communication bus (such as encrypted CAN / LIN bus, which prevents information from being intercepted and changed), and requests the main controller to complete the identity authorization.

[0110] In step S202, the main controller receives the from hardware feature information sent by the from controller; and verifies the from hardware feature information corresponding to the from controller.

[0111] Specifically, the authentication unit of the main controller receives the from hardware feature information (hash value) sent by the from controller through the secure communication bus, and first verifies the information transmission integrity (such as checksum verification) to ensure that the information is not irregular due to transmission loss or change.

[0112] Then, the verification unit of the main controller verifies the regularity of the from hardware feature information based on a preset rule. The main controller queries the vehicle model regular from controller hardware specification library (vehicle manufacturer pre-stored hardware parameter range of all from controllers of the vehicle model) built in the main controller, confirms that the hardware specification (such as chip model, version) corresponding to the from hardware feature information meets the vehicle model requirements, and excludes irregular controllers with unmatched models.

[0113] The master controller can also check the slave controller binding record stored in the master controller to confirm that the slave controller (associated by hardware feature information) is not bound to other vehicle master controllers, thereby avoiding the regular slave controller being used irregularly across vehicles.

[0114] In step S203, after the master controller verifies the slave hardware feature information successfully, the master controller encrypts the slave hardware feature information based on the master controller private key to obtain the slave controller signature information corresponding to the slave controller.

[0115] Specifically, the authorization unit of the master controller reads the master controller private key stored in step S101 from the non-changeable medium (such as EFUSE), which is only used to issue a signature for the slave controller and cannot be derived or changed. Then, the slave hardware feature information (hash value) is digitally signed by the master controller private key through a preset asymmetric encryption algorithm (such as SM2, RSA2048) to generate the slave controller signature information. The slave controller signature information is essentially an identity certificate issued by the master controller for the slave controller, which includes the slave hardware feature information and the master controller signature identifier, and can prove the regularity of the slave controller.

[0116] After the master controller generates the signature information, the master controller stores the association of the slave controller hardware feature information, the slave controller signature information, and the corresponding vehicle identifier information in the local security module to form a binding chain of vehicle-master controller-slave controller, thereby preventing the slave controller from being reused across vehicles.

[0117] In step S204, the master controller returns the slave controller signature information and the master controller public key to the slave controller.

[0118] Specifically, the master controller returns the generated slave controller signature information and the master controller public key (the public key can be public and used to decrypt the signature information in subsequent verification) to the slave controller through a secure communication bus (encrypted transmission), ensuring that the transmission process is not intercepted or changed.

[0119] After the authorized unit of the slave controller receives the slave controller signature information and the master controller public key, the slave controller signature information and the master controller public key are stored in the non-changeable medium (such as EFUSE) of the slave controller as the core credentials for subsequent verification of the slave controller.

[0120] In step S205, the master controller returns the slave controller signature information and the master controller public key to the next slave controller corresponding to the slave controller in the preset arrangement order.

[0121] Specifically, the master controller locates the next slave controller (such as slave controller 3) of the current slave controller (such as slave controller 2) according to the preset arrangement order (such as master controller→slave controller 1→slave controller 2→slave controller 3→master controller).

[0122] Then, the signature information of the current slave controller and the public key of the master controller are sent to the next slave controller through the secure communication bus, wherein: the signature information of the current slave controller is used to decrypt the original slave hardware feature information when the next slave controller checks the current slave controller; and the public key of the master controller is used to decrypt the signature information of the current slave controller (in asymmetric encryption, the public key decrypts the private key signature) and is a key tool for checking.

[0123] After the checking unit of the next slave controller receives the signature information of the current slave controller and the public key of the master controller, the signature information of the current slave controller and the public key of the master controller are stored in a secure medium and are called when the current slave controller is periodically checked in the subsequent period, so that chain closed loop checking is finally realized, and the whole replacement of a single or multiple slave controllers is avoided.

[0124] The controller anti-replacement system provided by the embodiment of the application reads the slave controller hardware information from the slave controller, generates the slave hardware feature information corresponding to the slave controller hardware information based on a preset encryption algorithm, ensures that the slave controller hardware identity is unique and unchangeable, provides a trusted hardware benchmark for subsequent normality checking, and avoids identity forgery caused by changed hardware information. The slave hardware feature information is stored and transmitted to the master controller. The slave hardware feature information is ensured not to be intercepted or changed in the transmission process, and the slave hardware feature information received by the master controller is ensured to be real and effective, thereby laying a reliable data foundation for subsequent verification and signature generation. The master controller receives the slave hardware feature information sent by the slave controller, verifies the slave hardware feature information corresponding to the slave controller, checks the normality of the slave hardware feature information (such as matching the hardware specifications of the vehicle model and excluding repeated binding), filters out the normal slave controller, prevents non-normal and non-model-matching slave controllers from accessing the system, and ensures the security of the slave controller level from the source. After the slave hardware feature information is verified successfully, the master controller encrypts the slave hardware feature information based on the private key of the master controller to obtain the slave controller signature information corresponding to the slave controller. The slave controller signature information is given a normal identity credential, the slave controller signature information cannot be forged (the private key of the master controller is needed to generate the slave controller signature information), the identity of the slave controller is ensured to be traceable and verifiable, and non-normal slave controllers are prevented from forging normal identities. The slave controller signature information and the public key of the master controller are returned to the next slave controller corresponding to the slave controller in a preset arrangement order. The next slave controller provides a core basis for periodically checking the normality of the current slave controller (the next slave controller needs to decode the signature information of the current slave controller by using the public key of the master controller), supports the establishment of a chain closed loop checking system, and avoids the situation that a single slave controller cannot be identified after being replaced.

[0125] In an alternative embodiment of the present application, the controller comprises a master controller and a slave controller. Each controller has a master controller corresponding to the master controller public key; as Figure 5 The controller anti-replacement method corresponding to the controller anti-replacement system can include the following steps:

[0126] Step S301, for each controller, the controller periodically acquires the last controller hardware feature information and the last controller signature information corresponding to the last controller in the preset arrangement order of the controller.

[0127] Specifically, each controller triggers a verification task automatically by a verification unit according to a system preset period (such as every 10 minutes or every time it is powered on).

[0128] According to the preset arrangement order (chain closed loop order), the controller determines the last controller that needs to be verified, for example, the last controller of the slave controller N-1 is the slave controller N-2; the last controller of the master controller is the slave controller N; the last controller of the slave controller 1 is the master controller, ensuring that there is no omission in the closed loop.

[0129] The verification unit of the controller sends an information acquisition request to the last controller through a secure communication bus, and specifically acquires: the last controller hardware feature information: the hardware identity extraction unit of the last controller reads the real-time generated Hash value from the non-changeable medium, and feeds back through the authorized unit; the last controller signature information: the verification unit of the last controller reads its own signature information (master controller signature or device authentication center signature) from the secure storage area (such as encrypted FLASH), and feeds back to the current controller.

[0130] The transmission process adopts an encrypted communication protocol (such as TLS1.3), which prevents information from being intercepted, changed or counterfeited, and ensures that the two types of information obtained are real and effective.

[0131] Step S302, each controller decodes the last controller signature information based on the master controller public key to obtain the decoding controller hardware feature information corresponding to the last controller.

[0132] Specifically, the verification unit of the controller reads the preset master controller public key from the secure storage medium of the controller. If the last controller is the master controller, its signature information is signed by the server private key, at which time the server public key (synchronized and preset during initialization of the master controller) needs to be called.

[0133] Then, the controller controls the checking unit of the controller to perform a decoding (signature verification) operation on the signature information of the previous controller using the public key of the main controller according to the encryption algorithm (such as SM2, RSA2048) of the signature information of the previous controller. In the asymmetric encryption logic, the private key signs and the public key decrypts, and the decoded information can restore the original hardware feature information corresponding to the signature, that is, the decoded controller hardware feature information.

[0134] If the decoding fails (such as the public key does not match or the signature information is changed to cause the restoration to fail), it is directly determined that the previous controller is irregular (step S304 is entered); if the decoding is successful, the complete decoded controller hardware feature information is obtained, and step S303 is entered.

[0135] In step S303, if the decoded controller hardware feature information is consistent with the hardware feature information of the previous controller, the controller determines that the previous controller is regular.

[0136] Specifically, the checking unit of the controller compares the hardware feature information (the current Hash value) of the previous controller obtained in step S301 with the decoded controller hardware feature information (the original Hash value) obtained in step S302 at the byte level.

[0137] If they are completely consistent, it indicates that the real-time hardware information of the previous controller completely matches the original hardware information recorded when the main controller (or the server) is authorized, and is not replaced or changed irregularly; the checking unit of the controller records the current checking result as regular, updates the checking log (for subsequent troubleshooting), and waits for the next periodical checking.

[0138] If the current controller is a slave controller, it will be checked by the next controller according to the same logic, and finally a closed-loop verification of the main controller→slave controller 1→slave controller 2→…→the main controller is formed, thereby completely avoiding the vulnerability of replacing the whole controller.

[0139] In step S304, if the decoded controller hardware feature information is inconsistent with the hardware feature information of the previous controller, the controller determines that the previous controller is irregular.

[0140] Specifically, if the decoded controller hardware feature information is inconsistent with the hardware feature information of the previous controller, the controller determines that the previous controller is irregular.

[0141] The inconsistency between the decoded controller hardware feature information and the hardware feature information of the previous controller usually corresponds to two types of irregular scenarios:

[0142] The previous controller is replaced as a whole: the hardware information of the new controller is different from the original hardware information, resulting in inconsistency between the real-time Hash value and the decoded Hash value;

[0143] The last controller hardware is changed: the original hardware information (such as the chip serial number) is irregularly modified, causing the real-time Hash value to change.

[0144] Next, the verification unit of the controller records irregular information, including: the device ID of the last controller, the verification failure time, the real-time Hash value, and the decoded Hash value (for subsequent tracing).

[0145] If the current controller is a slave controller: the reporting unit thereof reports the irregular information to the master controller through the secure communication bus.

[0146] If the current controller is a master controller: the reporting unit thereof directly reports the irregular information to the device authentication center (cloud) through the vehicle-mounted T-BOX (remote communication module).

[0147] After the server receives the irregular information, the last controller is recorded in the irregular device blacklist, and vehicle-side management and control (such as limiting the functions related to the irregular controller, lighting the instrument panel fault light) can be triggered, and the vehicle manufacturer or 4S store is notified to investigate, thereby completely blocking the use of irregular replacement parts.

[0148] The controller anti-replacement system provided by the embodiments of the present application has a master controller public key corresponding to the master controller in each controller. A unified and trusted decryption tool is provided for decoding the signature information of the last controller, avoiding decoding failure due to the lack of a corresponding public key, ensuring the universality and continuity of chain verification, and supporting the operation of a closed-loop verification system. Each controller decodes the signature information of the last controller based on the master controller public key to obtain the decoded controller hardware feature information corresponding to the last controller. Only a regular signature issued by the master controller private key can be successfully decoded, preventing counterfeit signature information from bypassing verification and improving signature verification security. The core reference is provided for subsequent verification of whether the last controller is replaced, avoiding the inability to determine the regularity of the hardware due to the lack of reference information, and ensuring that the verification logic can be implemented. If the decoded controller hardware feature information is consistent with the hardware feature information of the last controller, it is determined that the last controller is regular. The hardware of the last controller can be accurately confirmed to be unaltered, ensuring its regular identity, providing a trusted result for chain verification, and ensuring the safe operation of the vehicle controller level. If the decoded controller hardware feature information is inconsistent with the hardware feature information of the last controller, it is determined that the last controller is irregular. Therefore, irregular replacement behavior can be discovered in a timely manner, avoiding the risk of failure caused by long-term hiding of irregular controllers in the system, and providing a basis for determining whether to report irregular information and block risks. The above method not only simplifies the verification process and reduces the consumption of controller computing resources, but also eliminates the possibility of attackers bypassing verification by counterfeiting hardware information, balancing verification efficiency and security.

[0149] In an alternative embodiment of the present application, the above-mentioned controller anti-replacement system further comprises a server, as shown in Figure 6 The controller anti-replacement method corresponding to the above-mentioned controller anti-replacement system can comprise the following steps:

[0150] Step S401: The server periodically sends a request for obtaining current master control device information corresponding to vehicle identification information to the master controller.

[0151] Specifically, the server automatically triggers the verification task according to a preset period (such as once a day, every 24 hours), and the period can be configured according to safety requirements.

[0152] The server retrieves the master controller basic information (such as master controller device ID, historical hardware feature information) bound to the vehicle identification information (VIN code) from the master control device whitelist, ensures that the request is accurately sent to the master controller of the target vehicle, and

[0153] The server sends a request for obtaining current master control device information to the master controller of the target vehicle through a vehicle remote safety communication channel (such as an encrypted Internet of Vehicles cloud platform), and the request contains vehicle identification information and server identity (such as server signature fragment) to avoid request forgery.

[0154] Step S402: The master controller reads the current master controller hardware information and generates current master hardware feature information corresponding to the current master controller hardware information based on a preset encryption algorithm.

[0155] Specifically, after receiving the server request, the hardware identity extraction unit of the master controller reads the current master controller hardware information in real time, including chip serial number, EFUSE fuse configuration, hardware version number, etc., which is completely consistent with the hardware information type read at initialization, ensuring that the information dimension is unified and can be used for subsequent comparison.

[0156] Then, the current hardware information is hashed by a preset security hash algorithm (such as SM3, SHA-256) consistent with that at initialization, to generate a unique current master hardware feature information (current Hash value). The current master hardware feature information is stored in the temporary security buffer area of the master controller for subsequent generation of self-signed information.

[0157] Step S403: The master controller encrypts the current master hardware feature information based on the master controller private key to generate master controller self-signed information.

[0158] Specifically, the master controller authentication unit reads its private key from an unchangeable medium, ensuring that the private key is not derived or changed irregularly. The security of the private key is the core guarantee for the effectiveness of the self-signed information.

[0159] The current master hardware feature information (current Hash value) generated in step S402 is digitally signed by the master controller private key through a preset asymmetric encryption algorithm (such as SM2, RSA2048) to generate master controller self-signed information.

[0160] Then, the master controller sorts two types of core information to be fed back to the server: (1) the master controller self-signed information generated in step S403; and (2) the master controller signature information issued by the server in the initialization stage (X.509 certificate stored in the master controller security medium or the same security level signature).

[0161] In step S404, the server receives the master controller signature information corresponding to the master controller and the master controller self-signed information.

[0162] Specifically, the server receives the master controller signature information and the master controller self-signed information sent by the master controller, and first performs format checking (such as certificate integrity, signature information field integrity) to exclude obviously irregular information (such as missing fields, irregular formats).

[0163] Next, the server retrieves the historical master controller hardware feature information and the master controller public key (stored during initialization) corresponding to the vehicle from the master control device whitelist according to the vehicle identification information in the received information, to prepare reference data for subsequent decryption and comparison.

[0164] In step S405, the server decrypts the master controller signature information based on the server public key corresponding to the server private key to obtain the first decrypted master controller hardware information corresponding to the master controller.

[0165] Specifically, the server reads the server private key from a trusted environment (such as a cryptographic machine) to avoid irregular changes to the server private key.

[0166] Then, the server performs a decryption operation on the master controller signature information using the server public key corresponding to the server private key through the same asymmetric encryption algorithm (such as SM2) as that used when generating the master controller signature information, to restore the corresponding master controller hardware feature information during signing, i.e., the first decrypted master controller hardware information (historical Hash value), which is the reference value stored by the server in the master control device whitelist during initialization of the master controller.

[0167] In step S406, the server compares the first decrypted master controller hardware information with the master controller hardware information stored in the server.

[0168] Specifically, the server reads the master controller hardware feature information (historical reference Hash value) corresponding to the current vehicle VIN code from the master control device whitelist.

[0169] Then, the first decrypted main controller hardware information (history Hash value) obtained by step S405 is compared with the history reference Hash value at byte level.

[0170] If the two are inconsistent, it indicates that the main controller signature information is irregularly changed (such as counterfeit signature), and the main controller is directly determined to be irregular, and the subsequent verification is terminated; if the two are consistent, step S407 is entered to perform a second round of more stringent current hardware regularity verification.

[0171] In step S407, if the first decrypted main controller hardware information is consistent with the main controller hardware information stored in the server, the server determines that the verification is successful.

[0172] Specifically, if the first decrypted main controller hardware information is consistent with the main controller hardware information stored in the server, the server determines that the verification is successful.

[0173] In step S408, if the verification is successful, the server decrypts the main controller self-signature information based on the main controller public key to obtain the current main hardware feature information.

[0174] Specifically, the server retrieves the main controller public key corresponding to the current main controller from the main control device whitelist. Then, the main controller self-signature information is decrypted by the asymmetric encryption algorithm (such as SM2) consistent with the generation of the main controller self-signature information to restore the current main hardware feature information (current Hash value) corresponding to the current main hardware.

[0175] In step S409, the server compares the current main hardware feature information with the main controller hardware information stored in the server.

[0176] Specifically, the server compares the current main hardware feature information with the main controller hardware information stored in the server.

[0177] In step S410, if the current main hardware feature information is consistent with the main controller hardware information stored in the server, the server determines that the main controller is regular.

[0178] Specifically, if the current main hardware feature information is consistent with the main controller hardware information stored in the server, the server determines that the main controller is normal. The server stores the current verification result (normal), verification time, main controller current Hash value and other information into the main controller verification log for subsequent tracing and auditing; updates the latest verification time of the main controller in the main control device whitelist and marks it as a normal operation state; if there is no subsequent abnormal trigger, the next verification period is waited for; if the comparison is inconsistent (step S408 comparison fails), the server determines that the main controller is not normal, and immediately starts an alarm process (such as sending an alarm to the vehicle operation and maintenance platform, recording the information of the abnormal device, limiting the related functions of the vehicle), and completely blocks the use of the abnormal main controller.

[0179] The controller anti-replacement system provided by the embodiments of the present application can periodically send a current master control device information acquisition request corresponding to vehicle identification information to the master controller. The master controller state can be monitored in real time, the master controller can be prevented from being replaced irregularly and then not found for a long time, the continuous safety of the vehicle core control node can be ensured, and the limitation of single verification can be compensated. The master controller reads current master controller hardware information, and generates current master hardware feature information corresponding to the current master controller hardware information based on a preset encryption algorithm. The latest hardware state of the master controller is ensured, real and real-time hardware identity basis is provided for subsequent comparison, and misjudgment caused by the use of outdated information is avoided. The current master hardware feature information is encrypted based on a master controller private key to generate master controller self-signature information. The current hardware information is ensured not to be changed during transmission, encryption protection is provided for the server to verify the authenticity of the current hardware, and the current hardware information is prevented from being imitated by an attacker. The server receives the master controller signature information corresponding to the master controller and the master controller self-signature information, provides complete data for double verification, avoids the vulnerability of single information verification, and improves the comprehensiveness of verification. The master controller signature information is decrypted based on a server public key corresponding to a server private key to obtain first decrypted master controller hardware information corresponding to the master controller. The first decrypted master controller hardware information is compared with the master controller hardware information stored in the server. The master controller signature information is verified not to be changed, and the master controller with an irregular initial identity is screened from the source. If the first decrypted master controller hardware information is consistent with the master controller hardware information stored in the server, the verification is successful. The master controller signature information is excluded from being imitated, a credible basis is laid for subsequent verification of the current hardware state, and subsequent operations based on irregular signatures are avoided. If the verification is successful, the master controller self-signature information is decrypted based on a master controller public key to obtain current master hardware feature information; the current hardware information is ensured to come from a regular master controller, and the master controller self-signature information is prevented from being imitated by an attacker to impersonate a regular master controller. The current master hardware feature information is compared with the master controller hardware information stored in the server. If the current master hardware feature information is consistent with the master controller hardware information stored in the server, it is determined that the master controller is regular. Whether the master controller is replaced or the hardware is changed can be accurately judged, the regularity of the master controller is finally determined, double protection of “signature regularity + hardware authenticity” is formed, and the risk of irregular replacement of the master controller is completely eliminated.

[0180] In an optional embodiment of the present application, as shown in Figure 2 The controller anti-replacement system further includes a replacement authentication device, as shown in Figure 7 The controller anti-replacement method corresponding to the controller anti-replacement system can further include the following steps:

[0181] In step S501, the replacement authentication device generates a replacement authentication device public-private key pair in a secure environment, and stores the replacement authentication device private key.

[0182] As shown in Figure 2 The identity authentication unit is used to obtain the formal identity of the replacement authentication device from the device authentication center during the initialization process of the replacement authentication device, and the authentication unit is used to perform identity authentication with the main controller during the replacement process and provide authentication information.

[0183] Specifically, the replacement authentication device needs to be in an offline and controllable physical and network security environment (such as being disconnected from external networks and only connected to internal secure terminals of the vehicle manufacturer). Then, the identity authentication unit in the replacement authentication device generates a unique public-private key pair of the replacement authentication device based on a preset asymmetric encryption algorithm (such as an industry security algorithm such as SM2, RSA2048, etc.). Then, the generated private key of the replacement authentication device is stored in an internal unchangeable medium of the device (such as an EFUSE fuse or an encrypted FLASH).

[0184] Step S502, the replacement authentication device generates a certificate signing request based on the replacement authentication device public key and the device hardware information corresponding to the replacement authentication device.

[0185] Specifically, the replacement authentication device reads its own hardware information (through a built-in hardware information reading module), integrates the hardware information with the replacement authentication device public key into structured data, and ensures that the information is not missing (such as the public key format and the hardware information field conform to the server parsing requirements). Then, according to the certificate request format (compatible with the X.509 certificate request format, as the server can issue X.509 certificates), the integrated information is packaged as a certificate signing request, which is essentially an application material for the replacement authentication device to apply for a formal identity from the server.

[0186] Step S503, the replacement authentication device sends the certificate signing request to the server.

[0187] Optionally, the replacement authentication device sends the certificate signing request to the server through an encrypted communication protocol (such as TLS1.3) in a secure environment (such as an internal secure network of the vehicle manufacturer), preventing interception and alteration during transmission.

[0188] Optionally, the replacement authentication device can also store the certificate signing request in a special secure storage medium (such as an encrypted U disk or a hardware dongle) and manually transfer it to the server by a staff member, avoiding network transmission risks.

[0189] Step S504, the server encrypts the device hardware information based on the server private key to generate replacement authentication device signature information.

[0190] Specifically, the server first checks whether the hardware information of the replacement authentication device in the request conforms to the regular device specifications purchased by the vehicle enterprise (such as whether the hardware model is in the access list), to exclude requests of non-regular devices.

[0191] After verification, the server reads the root private key (i.e., the server private key) from the trusted environment such as the password machine, and generates replacement authentication device signature information by digitally signing the device hardware information of the replacement authentication device through a preset asymmetric encryption algorithm (such as SM2, RSA2048). The replacement authentication device signature information is essentially a regular identity certificate issued by the server for the replacement authentication device, which can prove that the device is an authorized replacement tool of the vehicle enterprise.

[0192] The server binds and stores the hardware information of the replacement authentication device and the replacement authentication device signature information to the replacement device whitelist, which is used to call the reference information when verifying the identity of the replacement authentication device later.

[0193] Step S505, the server sends the replacement authentication device signature information to the replacement authentication device.

[0194] Specifically, the replacement authentication device signature information sent by the server needs to be accompanied by the server public key of the server (used for subsequent verification of the regularity of the signature information by the replacement authentication device) and the device unique identifier (such as the device ID) in the replacement device whitelist for associated storage.

[0195] Step S506, the replacement authentication device receives the replacement authentication device signature information sent by the server.

[0196] Specifically, after receiving the replacement authentication device signature information, the replacement authentication device first verifies the regularity of the replacement authentication device signature information using the server public key attached by the server (such as decrypting the signature information to confirm that the hardware information can be restored), to exclude counterfeit signatures.

[0197] After verification, the replacement authentication device signature information is stored in the non-changeable medium (consistent with the private key storage location, such as EFUSE) of the replacement authentication device, as the core credential for subsequent mutual authentication with the main controller.

[0198] Step S507, after the main controller receives the replacement instruction for the slave controller, the main controller sends the main controller signature information to the replacement authentication device.

[0199] Specifically, the main controller reads the main controller signature information (signature issued by the server using the root private key in the initialization stage, containing the main controller hardware feature information and the vehicle VIN code) from the secure medium of the main controller;

[0200] The main controller signature information is sent to the replacement authentication device through a vehicle internal secure communication bus (such as an encrypted CAN bus), and the transmission process needs to be encrypted (such as temporarily encrypted with the public key of the replacement authentication device) to prevent the information from being intercepted.

[0201] In step S508, the replacement authentication device verifies the main controller signature information and the replacement authentication device signature information through a certificate verification method. If it is determined that the main controller signature information and the replacement authentication device signature information are both encrypted based on the server private key of the server, the verification is successful.

[0202] Specifically, the replacement authentication device calls the server public key to perform a decoding (signature verification) operation on the main controller signature information sent by the main controller. If the main controller hardware feature information and the vehicle identification information can be restored after decoding, and match the current hardware information of the main controller, it is proved that the main controller is a regular device authorized by the server.

[0203] The replacement authentication device also calls the replacement authentication device signature information stored by itself to verify the regularity of the signature again (confirm that it has not been replaced by a non-regular device) using the server public key.

[0204] Only when the main controller signature information and the replacement authentication device signature information are both verified (i.e. both are encrypted by the server root private key), the replacement authentication device determines that the verification is successful. The core logic is two-way verification to ensure that the main controller and the replacement tool are regular, and to avoid single-side forgery.

[0205] In step S509, after the verification is successful, the replacement authentication device sends verification success information to the main controller.

[0206] Specifically, the verification success information needs to be temporarily signed by the private key of the replacement authentication device, and the main controller needs to verify the signature using the public key of the replacement authentication device after receiving it to confirm that the information source is regular.

[0207] In step S510, after receiving the verification success information sent by the replacement authentication device, the main controller initializes the replaced update slave controller and generates update slave controller signature information corresponding to the update slave controller.

[0208] Specifically, the main controller reads the hardware information (such as chip serial number, EFUSE configuration) of the replaced update slave controller through the secure bus, calls a secure hash algorithm (such as SM3) to calculate the Hash value of the update slave controller hardware information, and obtains the update slave controller hardware feature information. The main controller calls its private key to digitally sign the update slave controller hardware feature information to generate the update slave controller signature information.

[0209] The master controller sends the updated slave controller's signature information and the master controller's public key to the updated slave controller (for storage as valid credentials) and the next slave controller in the preset order of the updated slave controller (for subsequent chain verification), thus completing the formal initialization of the updated slave controller.

[0210] The controller anti-substitution system provided in this application embodiment generates a public-private key pair for the replacement authentication device in a secure environment and stores the private key. This prevents key leakage or theft, provides a secure key foundation for subsequent identity authentication of the replacement authentication device, and avoids device identity impersonation due to key risks. Based on the public key and the corresponding device hardware information, a certificate signing request is generated. The certificate signing request ensures that it contains a unique device identifier, providing complete data for the server to identify and verify the legitimacy of the replacement authentication device, preventing illegitimate devices from impersonating legitimate replacement tools. The certificate signing request is sent to the server. The system ensures that the certificate signing request is not intercepted or altered during transmission, ensuring the authenticity and validity of the device information received by the server, providing a prerequisite for the legitimacy of subsequent signature generation. The server encrypts the device hardware information based on its private key, generates replacement authentication device signature information, and sends this signature information to the replacement authentication device. This assigns the replacement authentication device a legitimate identity credential. This signature information is unforgeable, providing authoritative evidence for device identity verification during replacement and preventing illegitimate replacement authentication devices from participating in the replacement process. The component replacement authentication device receives the device signature information sent by the server. This enables it to provide legitimate identity verification during subsequent mutual authentication with the main controller, ensuring that the component replacement authentication device can only be used in authorized scenarios and supporting the initiation verification of the formal component replacement process.

[0211] After the main controller receives the replacement instruction of the slave controller, the main controller sends the main controller signature information to the replacement authentication device. The main controller signature information provides a basis for verifying the identity of the replacement authentication device, avoids the non-standard main controller initiating the replacement operation, and controls the standardization of the replacement behavior from the source. The replacement authentication device verifies the main controller signature information and the replacement authentication device signature information through a certificate verification method, which can prove that the main controller is a standard device authorized by the server, and excludes the non-standard main controller initiating the replacement request, thereby controlling the standardization of the replacement initiator from the source. If it is determined that the main controller signature information and the replacement authentication device signature information are both encrypted based on the server private key of the server, the verification is successful. A “two-way standard verification” mechanism is formed to completely eliminate the risk of non-standard replacement caused by single counterfeit signature, and to provide a safe pre-protection for the subsequent standard replacement process. After the verification is successful, the main controller sends the verification success information to the main controller. Only the standard main controller and the standard replacement authentication device can start the replacement, which eliminates the malicious replacement of attackers through counterfeit replacement instructions or non-standard devices, and ensures the safety of the replacement scene. After the main controller receives the verification success information sent by the replacement authentication device, the main controller initializes the updated slave controller after replacement, and generates the updated slave controller signature information corresponding to the updated slave controller. Only the standard main controller and the standard replacement authentication device can start the replacement, which eliminates the malicious replacement of attackers through counterfeit replacement instructions or non-standard devices, and ensures the safety of the replacement scene.

[0212] The application provides a controller anti-replacement method applied to a controller in the controller anti-replacement system.

[0213] Periodically acquire the last controller hardware feature information and the last controller signature information of the last controller in the preset arrangement sequence corresponding to the controller.

[0214] Decode the last controller signature information to obtain the decoded controller hardware feature information corresponding to the last controller.

[0215] Verify the decoded controller hardware feature information and the last controller hardware feature information.

[0216] In an optional embodiment, the controller includes a main controller and a slave controller, and the method is applied to the main controller. Before the step of periodically acquiring the last controller hardware feature information and the last controller signature information of the last controller in the preset arrangement sequence corresponding to the controller, the method further includes: initializing the main controller to generate the main controller signature information corresponding to the main controller; and initializing the slave controller to generate the slave controller signature information corresponding to the slave controller.

[0217] For details of the method of preventing replacement of the controller, please refer to the description of the system of preventing replacement of the controller above, which will not be repeated here.

[0218] The present application provides a target vehicle including a vehicle body and the system of preventing replacement of the controller of any of the above embodiments.

[0219] Although embodiments of the present application have been described in conjunction with the drawings, various modifications and changes can be made by those skilled in the art without departing from the spirit and scope of the present application, and such modifications and changes fall within the scope defined by the appended claims.

Claims

1. A controller anti- substitution system, characterized in that, The controller anti-replacement system comprises a target vehicle, and the target vehicle comprises a controller, wherein: For each controller, the last controller hardware feature information and the last controller signature information of the last controller in the preset arrangement sequence corresponding to the controller are periodically acquired; the last controller signature information is decoded to obtain decoded last controller hardware feature information corresponding to the last controller; and the decoded last controller hardware feature information is verified based on the last controller hardware feature information. The controller comprises a master controller and a slave controller, and before the step of periodically acquiring the last controller hardware feature information and the last controller signature information of the last controller in the preset arrangement sequence corresponding to the controller, the master controller is used to initialize the master controller to generate master controller signature information corresponding to the master controller. The master controller is also used to initialize the slave controller to generate slave controller signature information corresponding to the slave controller. The number of the slave controllers is at least one; the slave controller is used to read slave controller hardware information, generate slave hardware feature information corresponding to the slave controller hardware information based on a preset encryption algorithm, store the slave hardware feature information, and transmit the slave hardware feature information to the master controller; the slave controller comprises an authorized unit, a hardware identity extraction unit, a verification unit, and a reporting unit; the slave controller hardware information comprises a chip serial number, an EFUSE fuse configuration, and a hardware version number. The master controller is used to receive the slave hardware feature information transmitted by the slave controller, verify the slave hardware feature information corresponding to the slave controller, encrypt the slave hardware feature information based on a master controller private key to obtain the slave controller signature information corresponding to the slave controller after the slave hardware feature information is verified successfully, and the master controller private key is used to issue a signature for the slave controller and cannot be derived or changed; the slave controller signature information is essentially an identity certificate issued by the master controller for the slave controller, contains the slave hardware feature information and a master controller signature identifier, and can prove the legitimacy of the slave controller. The slave controller signature information and the master controller public key are returned to the slave controller, and the slave controller signature information and the master controller public key are returned to the next slave controller corresponding to the slave controller in the preset arrangement sequence. The verification of the slave hardware feature information corresponding to the slave controller comprises: Confirming that the hardware specification corresponding to the slave hardware feature information meets the vehicle model requirements; Checking the slave controller binding record stored by the master controller to confirm that the slave controller is not bound with other vehicle master controllers.

2. The system of claim 1, wherein, The controller anti-replacement system further comprises a server, wherein: The main controller is configured to generate a main controller public-private key pair corresponding to the main controller, securely store a main controller private key, read main controller hardware information, generate main hardware feature information corresponding to the main controller hardware information based on a preset encryption algorithm, and store the main hardware feature information; generate a main controller certificate signature request based on a main controller public key, vehicle identification information corresponding to the target vehicle, and the main controller hardware information; and send the main controller certificate signature request to a server. The server is configured to verify the vehicle identification information corresponding to the main controller and the main controller hardware information, and, after successful verification, encrypt the main controller hardware information based on a server private key, generate main controller signature information, and send the main controller signature information to the main controller. The main controller is configured to receive the main controller signature information sent by the server and save the main controller signature information.

3. The system of claim 1, wherein, The controllers include a main controller and a slave controller, and each of the controllers has a main controller public key corresponding to the main controller; each of the controllers is configured to decode the last controller signature information based on the main controller public key to obtain decoded controller hardware feature information corresponding to the last controller.

4. The system of claim 1, wherein, The controller is configured to determine that the last controller is normal if the decoded controller hardware feature information is consistent with the last controller hardware feature information, and determine that the last controller is abnormal if the decoded controller hardware feature information is inconsistent with the last controller hardware feature information.

5. The system of claim 2, wherein, The server is configured to periodically send a current main control device information acquisition request corresponding to the vehicle identification information to the main controller. The main controller is configured to read current main controller hardware information, generate current main hardware feature information corresponding to the current main controller hardware information based on a preset encryption algorithm, encrypt the current main hardware feature information based on the main controller private key, and generate main controller self-signature information. The server is configured to receive the main controller signature information and the main controller self-signature information corresponding to the main controller, decrypt the main controller signature information based on a server public key corresponding to the server private key, and obtain first decrypted main controller hardware information corresponding to the main controller. The first decrypted main controller hardware information is compared with the main controller hardware information stored in the server. If the first decrypted main controller hardware information is consistent with the main controller hardware information stored in the server, the verification is successful. If the verification is successful, the main controller self-signature information is decrypted based on the main controller public key to obtain the current main hardware feature information. The current main hardware feature information is compared with the main controller hardware information stored in the server. If the current main hardware feature information is consistent with the main controller hardware information stored in the server, the main controller is determined to be normal.

6. The system of claim 2, wherein, The controller anti-replacement system further comprises a replacement authentication device, wherein: The master controller is further configured to, after receiving the replacement instruction for the slave controller, send the master controller signature information to the replacement authentication device; The replacement authentication device is configured to verify the master controller signature information based on replacement authentication device signature information corresponding to the replacement authentication device, and send verification success information to the master controller after verification is successful; The master controller is configured to, after receiving the verification success information sent by the replacement authentication device, initialize the replaced updated slave controller, and generate updated slave controller signature information corresponding to the updated slave controller.

7. The system of claim 6, wherein, The replacement authentication device is configured to generate a replacement authentication device public-private key pair in a secure environment, and store the replacement authentication device private key; Based on the replacement authentication device public key and device hardware information corresponding to the replacement authentication device, a certificate signature request is generated; The certificate signature request is sent to a server; The server is configured to encrypt the device hardware information based on a server private key, and generate replacement authentication device signature information; And the replacement authentication device signature information is sent to the replacement authentication device; The replacement authentication device is configured to receive the replacement authentication device signature information sent by the server.

8. The system of claim 7, wherein, The replacement authentication device is configured to verify the master controller signature information and the replacement authentication device signature information through a certificate verification method, and if it is determined that the master controller signature information and the replacement authentication device signature information are both encrypted based on the server private key corresponding to the server, the verification is successful.

9. A controller anti-tampering method, characterized by, The controller applied to the controller anti-replacement system of any one of claims 1-8, the method comprising: Periodically obtaining the last controller hardware feature information and the last controller signature information of the last controller in the preset arrangement order corresponding to the controller; Decoding the last controller signature information to obtain decoded controller hardware feature information corresponding to the last controller; Verifying the decoded controller hardware feature information and the last controller hardware feature information.

10. The method of claim 9, wherein, The controller includes a master controller and a slave controller, and the method is applied to the master controller, and before the periodically obtaining the last controller hardware feature information and the last controller signature information of the last controller in the preset arrangement order corresponding to the controller, the method further comprises: Initializing the master controller to generate master controller signature information corresponding to the master controller; Initializing the slave controller to generate slave controller signature information corresponding to the slave controller.

11. A target vehicle, characterized by The target vehicle comprises a vehicle body and the controller anti-replacement system of any one of claims 1-8.

Images